What it does
distill-coding-standards turns a repository’s historical PR review comments into written coding standards: it mines every comment a reviewer left, classifies them, confirms the categories with you, and writes the rules into the two-level routing structure that apply-coding-standards reads. Every rule it writes must trace back to review feedback that actually recurred — it distills what your reviewers already said, never what a style guide thinks they should have.
Each rule is routed by the transplant test: a rule that reads correctly in a stranger’s repo with the same stack is generic and lands in the global standards home; anything naming domain nouns, project helpers, or bespoke workflows is project-specific and lands in the repo’s CODING_STANDARDS/ directory.
When to reach for it
- Invocation mode. You invoke this by typing
/distill-coding-standards— the agent won’t reach for it on its own. - Trigger boundary. Reach for it when a repo has real review history and no written standards — or stale ones. To scaffold the structure without distilling yet, use setup-coding-standards; to check code against existing standards, use apply-coding-standards.
Prerequisites
An authenticated gh CLI with access to the repo’s PR history, and a reviewer whose comments are worth mining (default: you). The run writes its working state to a dossier at .claude/coding-standards-dossier/ in the target repo — kept out of version control — so the work survives context compaction and later feeds validation.
The dossier also stores a watermark, making re-runs incremental: a later distillation mines only PRs with activity since the last run and reports the delta per category — shrinking counts are the standards working.
Mine, classify, checkpoint, write
The run is a pipeline with a hard gate in the middle: mine every PR-level, inline, and review-body comment; classify each with a feedback type and subject; then checkpoint — you approve the proposed categories, their generic/project routing, and placement before a single standard is written. The checkpoint is what keeps the output yours: the skill proposes, the reviewer who wrote the comments disposes.
It’s working if
- Every written rule traces to comments that recurred, not to general best practice.
- Generic and project rules landed on opposite sides of the transplant test.
- The dossier is on disk and gitignored, ready for a validation run.
Where it fits
The fill step of the coding-standards chain: setup-coding-standards scaffolds the structure, /distill-coding-standards fills it, validate-distilled-coding-standards tests it against the very code the comments reviewed, and apply-coding-standards uses it while coding. For the map of the whole set, see ask-eddy.