compile

/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.