undefined

- Press `#` during a session to add memory items quickly
- Use `/memory` to open CLAUDE.md in your editor
</quick_start>

<file_hierarchy>

| Priority | Location | Scope |
|----------|----------|-------|
| 1 (Highest) | Enterprise policy (managed by IT) | All org users |
| 2 | `./CLAUDE.md` or `./.claude/CLAUDE.md` | Team via git |
| 2 | `./.claude/rules/*.md` | Team via git |
| 3 | `~/.claude/CLAUDE.md` | All your projects |
| 3 | `~/.claude/rules/*.md` | All your projects |
| 4 (Lowest) | `./CLAUDE.local.md` (auto-gitignored) | Just you |

Claude recurses UP from current directory, loading all CLAUDE.md files found. Also discovers CLAUDE.md in subtrees when reading files in those directories.

**Monorepo strategy:** Root file defines WHEN; subtree files define HOW.

</file_hierarchy>

<rules_directory>
The `.claude/rules/` directory splits instructions into focused markdown files.

**Use `.claude/rules/` when:** many concerns, different rules for different file types, team maintains different areas.
**Use CLAUDE.md when:** small project, universal rules, single source of truth.

Path-scoped rules use YAML frontmatter:
```yaml
---
paths:
  - "src/api/**/*.ts"
---

Supported patterns: `**/*.ts`, `src/**/*`, `src/**/*.{ts,tsx}`, `{src,lib}/**/*.ts`

Rules without `paths` frontmatter load unconditionally.

See [references/rules-directory-guide.md](references/rules-directory-guide.md) for complete guide including symlinks, user-level rules, and migration.
</rules_directory>

<content_structure>
Structure CLAUDE.md with only these sections:

1. **Project purpose** (1-3 lines) — What the project is
2. **Tech stack** (compact) — Only non-obvious technologies
3. **Commands** — Non-obvious dev, build, and test commands
4. **Important files** — Architecture-critical, non-obvious files only
5. **Rules** — Prohibitions and constraints that prevent mistakes (highest-value lines)
6. **Workflow** (optional) — Only if non-standard

**Do NOT include:**
- Repository overviews (agent discovers structure itself)
- Code style rules (linters enforce these)
- Generic best practices ("write clean code", "DRY", "SOLID")
- Redundant specs (copies of config files, env vars, schema descriptions)
- Marketing/goals (vision statements, KPIs, roadmaps)
- Verbose explanations (paragraphs where one line suffices)

See [references/section-templates.md](references/section-templates.md) for ready-to-use templates.
See [references/project-patterns.md](references/project-patterns.md) for framework-specific patterns.
</content_structure>

<writing_rules>
**Golden rule:** If someone with zero project context reads your CLAUDE.md and gets confused, Claude will too.

**Be specific, never vague:**

**Prohibitions > positive guidance:**

**Show, don't tell:** When format matters, show a concrete example (3-5 lines max).

**Emphasis hierarchy:** CRITICAL > NEVER > ALWAYS > IMPORTANT > YOU MUST
- Put critical rules **first** in each section
- Use **bold + keyword** for non-negotiable rules: `**CRITICAL**: Never commit secrets`

See [references/prompting-techniques.md](references/prompting-techniques.md) for advanced techniques.
</writing_rules>

<size_limits>
- **Ideal:** < 100 lines
- **Maximum:** 150 lines before performance degrades
- **Over 200 lines:** directives start getting lost

When exceeding limits, split into `.claude/rules/` files or link to separate docs:
```markdown
- **API patterns**: See [docs/api-patterns.md](docs/api-patterns.md)
- **Testing guide**: See [docs/testing-guide.md](docs/testing-guide.md)

undefined

undefined