Agent skill
claude-rules
This skill should be used when creating rule files, organizing conventions, or when ".claude/rules/", "FORMATTING.md", "create rule", or "project conventions" are mentioned.
Install this agent skill to your Project
npx add-skill https://github.com/outfitter-dev/agents/tree/main/plugins/outfitter/skills/claude-rules
Metadata
Additional technical details for this skill
- version
- 1.0.0
- related skills
-
[ "claude-config", "claude-plugins" ]
SKILL.md
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/
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
stack-feedback
Creates GitHub issues for problems discovered while using @outfitter/* packages. Use when finding bugs, missing features, unclear documentation, or improvement opportunities.
stack-architecture
Design stack-based systems using @outfitter/* packages. Use when planning new projects, choosing packages, designing handler architecture, or when "architecture", "design", "structure", "plan handlers", or "error taxonomy" are mentioned.
stack-templates
Templates for creating handlers, CLI commands, MCP tools, and daemon services following Outfitter Stack conventions. Use when scaffolding new components, creating handlers, adding commands, or when "create handler", "new command", "add tool", "scaffold", "template", or "daemon service" are mentioned.
stack-audit
Scan codebase for Outfitter Stack adoption candidates. Identifies throw statements, console usage, hardcoded paths, and custom errors. Use when assessing adoption scope or checking readiness.
stack-review
Audits code for Outfitter Stack compliance including Result types, error handling, logging patterns, and path safety. Use for pre-commit reviews, code quality checks, migration validation, or when "audit", "check compliance", "review stack", or "stack patterns" are mentioned.
stack-patterns
Reference for Outfitter Stack patterns including Result types, Handler contract, Error taxonomy, and @outfitter/* package conventions. Use when learning the stack, looking up patterns, understanding packages, or when "Result", "Handler", "error taxonomy", "OutfitterError", "CLI output", "pagination", "MCP server", "MCP tool", "structured logging", "redaction", "test handler", "daemon", "IPC", or "@outfitter/*" are mentioned.
Didn't find tool you were looking for?