rule-curator

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.