claude-rules
Claude Rules Authoring
Create reusable instruction files in .claude/rules/ for project conventions.
Rules vs CLAUDE.md
| Aspect | CLAUDE.md | .claude/rules/ |
|---|---|---|
| Loading | Automatic at session start | On-demand via reference |
| Content | Project setup, key commands | Reusable conventions |
| Size | Concise (~200-500 lines) | Can be detailed |
| Scope | This specific project | Patterns across files |
Put in CLAUDE.md: One-off instructions, project-specific commands, key file locations.
Put in rules/: Formatting conventions, architecture patterns, workflow guidelines, commit standards.
File Conventions
Naming
- UPPERCASE.md - All caps with
.mdextension - Topic-focused - One concern per file
- Kebab-case for multi-word -
API-PATTERNS.md,CODE-REVIEW.md
Good: FORMATTING.md, TESTING.md, COMMITS.md
Bad: formatting.md, MyRules.md, everything.md
Structure
.claude/rules/
├── FORMATTING.md # Code style, output conventions
├── TESTING.md # Test patterns, coverage requirements
├── COMMITS.md # Commit message format, PR conventions
├── ARCHITECTURE.md # Component structure, file organization
└── SECURITY.md # Security guidelines, auth patterns
Content Structure
Rules files should be scannable and actionable:
# Topic Name
Brief description of what this covers.
## Section 1
| Pattern | Example | Notes |
|---------|---------|-------|
| ... | ... | ... |
## Section 2
**Do:**
- Specific guideline
**Don't:**
- Anti-pattern to avoid
## Examples
{ concrete examples }
Referencing Rules
From CLAUDE.md
Reference rules explicitly - they're not auto-loaded:
# CLAUDE.md
## Code Style
Follow `.claude/rules/FORMATTING.md` for all code conventions.
## Testing
See `.claude/rules/TESTING.md` for TDD patterns.
Cross-file References
Use @ syntax to include content from other files:
# .claude/rules/FORMATTING.md
@./project-specific/FORMATTING.md
This keeps rules DRY by pointing to authoritative sources.
Plugin Shared Rules
Plugins can organize shared rules internally:
my-plugin/
├── .claude-plugin/
│ └── plugin.json
├── skills/
│ └── my-skill/
│ └── SKILL.md # Can reference ../../rules/FORMATTING.md
└── rules/
├── FORMATTING.md
└── PATTERNS.md
Important limitation: Shared rules only work WITHIN a single plugin. When plugins are installed, Claude Code copies them to a cache directory. Paths that traverse outside the plugin root (like ../other-plugin/rules/) won't work after installation.
For cross-plugin patterns: Use skill invocation instead of file references. Reference related skills by name (e.g., "load the outfitter:formatting skill") rather than file paths.
Quick Start
Create a New Rule
- Identify the convention scope (formatting, testing, commits, etc.)
- Create
TOPIC.mdin.claude/rules/ - Write scannable content with tables, do/don't lists
- Reference from CLAUDE.md
Validate a Rule
- Filename is UPPERCASE.md
- Single focused topic
- Scannable structure (tables, lists)
- Referenced from CLAUDE.md
- No duplicate content with CLAUDE.md
Anti-Patterns
Don't:
- Create rules for one-off instructions (use CLAUDE.md)
- Duplicate content between CLAUDE.md and rules/
- Create catch-all files like
EVERYTHING.md - Expect rules to auto-load (they must be referenced)
Do:
- Keep each rule file focused on one topic
- Use tables and lists for scannability
- Reference shared rules via
@when available - Document why, not just what
Related Skills
- claude-code-configuration - CLAUDE.md and settings.json
- claude-plugin-development - Plugin structure including rules/
More from outfitter-dev/agents
codebase-recon
This skill should be used when analyzing codebases, understanding architecture, or when "analyze", "investigate", "explore code", or "understand architecture" are mentioned.
92graphite-stacks
This skill should be used when the user asks to "create a stack", "submit stacked PRs", "gt submit", "gt create", "reorganize branches", "fix stack corruption", or mentions Graphite, stacked PRs, gt commands, or trunk-based development workflows.
76code-review
This skill should be used when reviewing code before commit, conducting quality gates, or when "review", "fresh eyes", "pre-commit review", or "quality gate" are mentioned.
34hono-dev
This skill should be used when building APIs with Hono, using hc client, implementing OpenAPI, or when "Hono", "RPC", or "type-safe API" are mentioned.
28software-craft
This skill should be used when making design decisions, evaluating trade-offs, assessing code quality, or when "engineering judgment" or "code quality" are mentioned.
28subagents
This skill should be used when coordinating agents, delegating tasks to specialists, or when "dispatch agents", "which agent", or "multi-agent" are mentioned.
25