Write rules that bind

A rule that reads well but never fires is wasted tokens — and worse, it pushes your other rules deeper into the weak-attention zone. This guide is the checklist for rules that fire.

1. Use trigger → action, not aspiration

A rule needs a moment the model can detect and an action to take at that moment.

• ✅ When the first sentence of a draft restates the question — delete it and lead with the answer.
• ❌ Be concise and direct.

The model evaluates the when during generation. Aspirations have no activation point, so they lose to task pressure.

2. Explain the why

Rules that carry their reason adapt to cases they didn’t anticipate.

• ✅ Never edit config.json by hand — the service validates its schema on startup and a malformed file crashes the process.
• ❌ Don't edit config.json.

3. Classify the constraint type

Decide where the rule should be enforced before you write it, and annotate it:

• <!-- constraint: soft --> — tone/persona/reasoning → stays in CONTEXT.md
• <!-- constraint: routing --> — skill triggers, action classification → ENFORCEMENT.md
• <!-- constraint: verifiable --> — checkable output criteria → ENFORCEMENT.md

Routing/verifiable rules left in context are the #1 cause of “I added a rule and it still fails.” Background: Soft / routing / verifiable.

4. Write for the weakest model in the rotation

Your files may be read by any model. Stick to the universal baseline:

• markdown structure (headings, bullets, tables) over prose or XML tags
• direct, specific language; one idea per line
• avoid “think step by step” scaffolding and few-shot examples in always-loaded files (they help some models, hurt others, and cost tokens every session)
• skip “you are an expert in X” — it can degrade accuracy; use the domain’s vocabulary instead

5. Spend from a budget

Every line costs tokens every session and dilutes the others. Before adding, ask: has anything earned removal? When the compile report shows you over budget, remove before adding — Why context rots.

6. Recompile and verify it fired

./scripts/compile-context.sh
grep -n "lead with the answer" CONTEXT.md

Presence in CONTEXT.md is the floor. The ceiling is proving the behavior changed and reverts when you remove the rule — Know it’s working.

Quick checklist

1. One idea per line?
2. Would a different model read it the same way?
3. Can any words come out without losing meaning?
4. Does it have a trigger, or is it aspirational?
5. Soft, routing, or verifiable — and is it in the right layer?
6. Does adding it bust the budget? If so, remove first.