craft-rules

assay:craft-rules

You write one rule per run. The wording and placement are the product: follow references/recipe.md exactly — it encodes the same factors /assay:opus5 grades. $ARGUMENTS, if present, describes what the rule should enforce.

You never write a policy file yourself. Every write goes through the engine's change transaction in step 5 — plan, apply, validate — so the rule is previewed before it lands and reversible after.

1. Read the project

Before the interview, from the project root:

node "${CLAUDE_PLUGIN_ROOT}/scripts/assay.js" scan

If node is not on PATH (fnm/nvm setups), register it the way the project's CLAUDE.md says to, then rerun.

Then read .assay-tmp/scan.json. It is the only place you learn where a rule can go; never assume a filename:

• profile.targets.rule.places[] — every file a new rule may be written into, each with its scope and a scoping sentence saying what it reaches. This is your placement menu in step 4.
• sources[] and files[] — what already exists, with selected. A source with selected: false is shadowed and never read; writing into it would be writing nowhere.
• rules[] — the ACTIVE corpus: every rule loaded here, with its exact text, file, and lineStart. Step 3 checks your draft against this list.

rules[] carries no scope — join a rule's file to files[] to learn whether it is project, user, or auto-memory.

2. Grill

Collect, from the conversation or at most two AskUserQuestion rounds. Don't ask for what the user already said; only fill real gaps.

Ask in this order, and say in one short clause WHY each answer matters — a question with no stated reason reads as a form to fill in. The order is by what a wrong answer costs: 1-3 decide where the rule lives and whether it should be a rule at all; 4 and 5 decide whether there is a rule to write at all — with neither, you refuse below; 6, 7 and 8 only sharpen it.

1. Scope — the whole project, or bound to file types, paths, or one subdirectory? This picks the file it goes in, and a rule in the wrong file never loads for the work it is about.
2. How much it matters — a preference, something you want followed, or something that must never happen? A preference held to a mandate's standard reads as broken; a mandate written as a preference gets skipped.
3. Could a command check it instead? If an exit code can settle it, a hook does it every time and a rule only asks.
4. The firing moment — which action, file, or phase should make Claude notice this applies? A rule with no moment is one Claude has to remember unprompted.
5. The behaviour — what must happen or stop happening, ideally with one example of it going wrong. The example is what turns a wish into something checkable.
6. For a prohibition, what replaces it — and if nothing does, what to do instead of stopping. A ban with no alternative can stall a run outright.
7. The specifics — exact paths, identifiers, thresholds. These are what make "done properly" mean one thing.
8. One line of what right looks like — the command, the call, the sentence they would want back. An example carries what a description of the example cannot; it is also the concrete specific question 7 is asking for. Optional: this lever is unmeasured, so never hold a rule back for it.