/compile

description: Extract rules from CLAUDE.md and its referenced documents and compile them into trigger-bound rule files
argument-hint: "[document path (omit for CLAUDE.md and all its @references)]"

/nunchi:compile

Compile rules with the following procedure.

1. Collect input

• Argument: $ARGUMENTS
• If an argument is given, read only that document; otherwise read the project CLAUDE.md and every `@path` document it references.

2. Extract rules

From each document, extract only rules that "are effective when recalled right before a specific action." Criteria:

• Can it be tied to a specific tool call? (creating a PR, committing, editing a specific file, running a specific command)
• Content that can't be tied to an action is **not a compilation target** — skip it, but classify what you skip into two lists for the final report (§6):
• **Procedure** — an ordered, multi-step how-to or workflow (release steps, migration order, environment setup). The right home is a Claude Code *skill*: a skill loads only its description at session start and its body on invocation — the same context economics as a nunchi rule, for content that is a *how* rather than a *before*. Report it as a **skill candidate**, quoting the passage that makes it procedural. Boundary: a checklist to run **before one specific action** ("before pushing, review the diff and run the checks") is a rule bound to that action, not a skill candidate — being multi-step doesn't disqualify it (measured misroute: `pilot/RESULTS-compile-bench-skillroute.md`); skill candidates are only for how-tos with no single triggering tool call.
• **Always-on guidance** — tone, general coding style, facts that must color every turn: stays in CLAUDE.md. **When unsure, classify here** — never propose moving content out of CLAUDE.md on a guess, and never route anything action-bindable into a skill candidate (an action rule compiles; a skill candidate is only for what step 1 of this section already rejected).
• **Tables, fenced code blocks, and list items are rule candidates on equal footing with prose.** A constraint doesn't stop being a rule because it sits in a table row or next to a code sample. But distinguish usage catalogs from constraints: a commands table that only lists what you *can* run is documentation, not a rule — it becomes a rule only when the document attaches an obligation, prohibition, or ordering to the action (must / never / before / after / only).
• **One rule per trigger**: when one sentence bundles requirements aimed at *different* triggers ("run X after editing A; run Y before pushing"), split them so each rule carries its own trigger and strength. Do NOT split an enumeration that shares one trigger, one strength, and one source ("run `make format`, `make lint`, `make test` before creating a PR" stays a single rule) — same-trigger copies would deliver the same source document multiple times for nothing.

3. Infer triggers

For each rule, set a `tool` (Bash|Edit|Write) and a `pattern` (Python regex). Examples:

• PR rules → tool: Bash, pattern: `gh\s+pr\s+create`
• Commit conventions → tool: Bash, pattern: `git(\s+-\S+(\s+\S+)?)*\s+commit`
• Migration file rules → tool: Edit, pattern: `migrations/`
• Content rules ("no console.log") → tool: Edit, pattern: `console\.log`, field: `new_string`, path: `\.(ts|tsx)$`

A Bash rule's pattern matches against the command string; an Edit/Write rule's pattern matches against the file path. Add `field: <tool_input key>` under `trigger` to match against a specific input field instead (e.g. `new_string` for edit content, `content` for Write). Two hard-won cautions:

• **Content rules must carry a `path:` regex** (ANDed with `pattern` against the file path) scoping them to code files — otherwise the rule fires on example code inside markdown, comments, and even its own source document.
• **Git command patterns must allow global options** — `git\s+commit` misses `git -C <dir> commit`; use the `git(\s+-\S+(\s+\S+)?)*\s+<subcommand>` shape.
• **File content/structure rules bind to BOTH Edit and Write**: a rule constraining what a file may contain ("no console.log", "every ViewModel follows this structure", "storyboards are banned") applies when modifying an existing file AND when creating a new one. Emit a pair — one rule with `tool: Edit`, one with `tool: Write` — sharing pattern, path, strength, and source (a content rule's Edit twin matches `field: new_string`, its Write twin `field: content`). This is "one rule per trigger" applied across tools: a different tool is a different trigger, and a single-tool binding silently leaks the other path (measured: `pilot/RESULTS-compile-wild-ko.md`). Rules about the act itself stay single-tool ("never edit committed migrations" → Edit only; "don't create new top-level modules" → Write only).

4. Decide strength

• The default is `require-read` (block once per session with the rule as the reason, let the retry through — guarantees a read at the cost of one retry).
• Actions the document explicitly prohibits get `block`. **Judge by the speech act — advice, obligation, or prohibition — not by surface wording, in whatever language the document is written.** An imperative form can still be advice: "avoid barrel files" recommends, it does not ban. Calibration examples:
• Prohibition (`block`): "Never …", "Do NOT …" (en) · "절대 …하지 마세요", "…금지" (ko) · "絶対に〜しないでください" (ja) · "NUNCA …", "No uses …" (es)
• Recommendation (stays `require-read` or `inject`): "avoid …", "prefer …" (en) · "…은 피하세요", "…지양" (ko) · "〜は避けてください" (ja) · "Evita …", "prefiere …" (es)
• Use `inject` for advisory rules where even one blocked attempt is overkill (style reminders, soft conventions): the rule is delivered alongside the tool call with zero friction, but compliance is left to the model's judgment rather than forced by a retry.

4.5 Confirm low-confidence judgments (interactive only)

Some §2–§4 judgments are measured to be wrong often enough that silently finalizin