claude-memory

Files (7)

• SKILL.md
• comprehensive-example.md · references/
• optimize-guide.md · references/
• project-patterns.md · references/
• prompting-techniques.md · references/
• rules-directory-guide.md · references/
• section-templates.md · references/

SKILL.md (first lines)

<core_principle>
Memory files consume tokens from the context window. ~100-150 instruction slots available for your customizations. Keep files minimal — only include what the agent cannot discover on its own.

**Two approaches:**
- **CLAUDE.md** — Single file, best for small projects (< 100 lines)
- **.claude/rules/** — Modular files with optional path-scoping, best for large projects
</core_principle>

<quick_start>
Run `/init` to auto-generate a CLAUDE.md. Or create manually:

```markdown
# Project Name

## Tech Stack
- [Primary framework]
- [Key non-obvious libraries]

## Commands
- `npm run dev` - Dev server
- `npm test` - Run tests
- `npm run build` - Build

## Rules
- [2-3 critical project-specific rules]
```

- 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.
```
root/CLAUDE.md           # Universal: tech stack, git workflow
apps/web/CLAUDE.md       # Frontend-specific
apps/api/CLAUDE.md       # Backend-specific
```
</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"
---
# API Rules
- All endpoints must include input validation
```

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:**
```
❌ "Format code properly" / "Write good tests" / "Follow best practices"
✅ "Run `pnpm lint` before committing" / "Tests in `__tests__/` using Vitest"
```

**Prohibitions > positive guidance:**
```
❌ "Try to use TanStack Form for forms"
✅ "NEVER use native form/useState for forms — ALWAYS use TanStack Form"
```

**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.

From zuzu59/z-skills, MIT.

More from zuzu59/z-skills