| name | rule-curator |
| description | Ingest new material (articles, docs, snippets, reference links, code review feedback) and fold it into the rules in `claude/rules/`. MUST be invoked when the user shares a new convention, style guide, blog post, library doc, or reference and wants it captured, when deciding whether guidance belongs in an existing rule or needs a new one, or when auditing or refreshing rules with fresh material.
|
Rule Curator
Takes in new material, researches it, and decides whether it belongs in an
existing rule in claude/rules/ or needs a new one.
Workflow
1. Read the material
Fetch URLs, read pasted text, or read referenced files in full. Pull out the
concrete, actionable conventions, not just "this seems useful." Vague
inspiration isn't rule content; a specific, reasoned rule is.
2. Verify before recording
Don't transcribe claims you haven't checked. If the material asserts that a
tool behaves a certain way or a pattern works, try it or cross-check current
docs. Blog posts and forum answers drift out of date faster than official
references do.
3. Survey the existing rules
ls claude/rules/
Read each candidate's paths frontmatter and skim its body to judge fit.
Match on both axes:
- Format or language: is this Dockerfile, shell, Python, markdown, etc.?
- Topic: does it extend something a rule already covers, or is it a
genuinely new area for that format?
4a. If it fits an existing rule, edit it in place
- Find the right spot: an existing
## heading to extend, or a new heading
that matches the rule's existing structure and voice.
- Match the target rule's example density and tone; don't import the source
material's style wholesale.
- Run the proposed edit past the user before writing it. They may want it
trimmed, placed elsewhere, or skipped.
4b. If it doesn't fit any existing rule, propose a new one
- Name it
<topic>.md and place it in claude/rules/.
- Add YAML frontmatter with
paths: globs that match the relevant file types
so the rule loads automatically when Claude works with those files.
- Per
CLAUDE.md, new rules live in claude/rules/ in this repo, never
directly under ~/.claude/, so they travel with the dotfiles and get
symlinked into place by bin/link-claude.
- Propose the name, scope,
paths globs, and outline to the user before
writing files.
5. Prune as you go
Keep only what's non-obvious, durable, and actionable. A rule that restates
what any competent engineer already knows is a tax on every future session
that loads it, not an asset.
Rules are read by Claude, which already knows what the language, tool, or
concept is. Don't open a rule with a definition or general background (no
"A secret is any value that grants access", no explaining what configuration
is). Capture only the user's preferences and suggested approaches, and start
at the first real convention rather than a scene-setting intro. A short scoping
or cross-reference line is fine when it marks a genuine boundary (what the rule
deliberately excludes, or where a related concern lives), not background.
