Creor/Docs
Dashboard

Rules

Rules are natural-language instructions that shape how the Creor agent works in your project. Check them into your repo as CREOR.md files, and every team member gets the same guardrails.

CREOR.md Files

The simplest way to add rules is to create a CREOR.md file in your project root. Creor reads this file and injects its contents into the system prompt for every conversation in that project.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# CREOR.md
 
## Code Style
- Use TypeScript strict mode. No `any` types.
- Prefer named exports over default exports.
- Use single quotes for imports, double quotes for user-facing strings.
 
## Architecture
- All API routes go in `src/routes/`.
- Business logic belongs in `src/services/`, not in route handlers.
- Database queries live in `src/db/` — never write raw SQL in services.
 
## Testing
- Every new function needs a unit test in the adjacent `__tests__/` directory.
- Use `vitest` for tests. Do not use Jest.
 
## Restrictions
- Never modify files in `src/generated/`.
- Do not install new dependencies without asking first.

Because CREOR.md is a regular file, it gets version controlled alongside your code. Pull requests that change project conventions can update the rules in the same commit.

The .creor Directory

For more granular control, create a .creor/ directory in your project root. Creor scans this directory for config, rules, agents, skills, and plugins.

Directory Structure

1
2
3
4
5
6
7
8
9
10
11
12
13
.creor/
creor.json # project config (same format as root creor.json)
rules/
typescript.md # rules about TypeScript conventions
testing.md # rules about testing patterns
security.md # rules about security practices
agents/
review.md # a custom agent definition
skills/
deploy/
SKILL.md # a custom skill
plugins/
my-tool.ts # a local plugin

You can also place a CREOR.md file inside the .creor/ directory itself. This is equivalent to placing it at the project root.

Instruction Discovery

Creor discovers instructions from multiple sources and injects them into the system prompt. The discovery process works as follows:

  • CREOR.md at the project root and any parent directories up to the workspace root
  • .creor/CREOR.md in every .creor directory found walking up from the project root
  • Markdown files in .creor/rules/ directories
  • Files referenced in the "instructions" array in creor.json
  • Global instructions from ~/.creor/ (your home directory)

Instructions from all sources are concatenated. Project-level rules appear after global rules, so they take practical precedence when the agent resolves conflicting guidance.

Custom Instruction Paths

You can explicitly list additional instruction files or glob patterns in your config:

1
2
3
4
5
6
{
"instructions": [
"docs/ai-guidelines.md",
"team-standards/*.md"
]
}

Global vs Project Rules

Rules can exist at two levels:

LevelLocationApplies To
Global~/.creor/CREOR.md or ~/.creor/rules/*.mdEvery project on your machine
ProjectCREOR.md or .creor/rules/*.md in the repoOnly this project

Global rules are useful for personal preferences — your preferred commit message format, coding style, or communication tone. Project rules are for team-shared conventions that everyone should follow.

Tip

Keep global rules short and focused on style. Put architecture and domain-specific guidance in project rules so they stay with the code.

Instruction Metadata

You can attach metadata to instruction files using the instructionMeta field in your config. This controls how each instruction is presented and whether it should always be included.

1
2
3
4
5
6
7
8
9
10
11
12
{
"instructionMeta": {
"docs/ai-guidelines.md": {
"description": "Team AI coding guidelines",
"alwaysApply": true
},
"docs/security-rules.md": {
"description": "Security review checklist",
"alwaysApply": false
}
}
}

When alwaysApply is true, the instruction is always injected into the system prompt. When false, the agent may choose to load it on demand using the fetch_rules tool when it seems relevant.

Writing Effective Rules

Good rules are specific, actionable, and scoped. Here are patterns that work well:

Be Specific, Not Vague

Instead of...Write...
"Write good code""Use TypeScript strict mode. All functions must have explicit return types."
"Follow best practices""Use React Server Components for data fetching. Client components only for interactivity."
"Be careful with security""Never log or store API keys. Use environment variables via process.env."

Include File Paths

Referencing specific paths makes rules unambiguous:

1
2
3
4
5
## File Organization
- API route handlers: src/app/api/
- Shared types: src/types/
- Database models: prisma/schema.prisma — do NOT edit manually
- Generated code: src/__generated__/ — never modify these files

State Consequences

Explaining why a rule exists helps the agent make better judgment calls in edge cases:

1
2
3
4
5
## Dependency Policy
- Do not add new npm dependencies without confirming with the user first.
Our bundle size is already at the limit for our Lighthouse target.
- Always prefer built-in Node.js APIs over third-party packages.
We had incidents caused by abandoned packages in the past.

Examples

Full-Stack Next.js Project

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# CREOR.md
 
## Stack
- Next.js 15 App Router with TypeScript strict mode
- Tailwind CSS for styling — no CSS modules
- Prisma ORM with PostgreSQL
- Vitest for testing
 
## Conventions
- All server actions go in src/app/actions/.
- Use `"use server"` directive, never `"use client"` in action files.
- Form validation: use Zod schemas in src/lib/validators/.
- Error handling: throw typed errors from src/lib/errors.ts, catch in error.tsx boundaries.
 
## Restrictions
- Never modify prisma/migrations/ files directly. Use `prisma migrate dev`.
- The src/components/ui/ directory is auto-generated from shadcn. Don't edit.
- Always check `pnpm lint` passes before considering a task complete.

Monorepo with Multiple Packages

1
2
3
4
5
6
7
8
9
10
11
12
13
# CREOR.md
 
## Monorepo Structure
- packages/core — shared business logic, zero dependencies on other packages
- packages/web — Next.js frontend, depends on core
- packages/api — Hono backend, depends on core
- packages/shared — TypeScript types shared across all packages
 
## Rules
- Changes to packages/shared/ require updating all consumers.
- Each package has its own tsconfig.json — do not modify the root tsconfig.
- Use workspace protocol for internal deps: "workspace:*"
- Run `turbo build` to verify no circular dependencies after structural changes.
PreviousConfigurationCustomizingNextSkillsCustomizing