The Iron Law applies here: **no skill edit without a failing test first.** I'm not going to hand you guidance text as if it's ready to deploy, because I haven't watched anything fail yet. But I can show you the right shape of the work and where I'd land.

## First: classify the failure before writing a word

"Plans are bloated" is a **wrong-shape output** failure, not a discipline failure. The agent isn't skipping a rule under pressure — it's producing the wrong shape (too much content). That classification matters enormously, because per Match the Form to the Failure:

> **Why prohibitions backfire on shaping problems:** under a competing incentive, agents negotiate with "don't X" and produce MORE of the unwanted content than with no guidance at all.

So the obvious-seeming fix — "Keep plans short. Don't over-explain. Avoid restating context." — is exactly the wrong form. It would likely make plans *longer*. The right form is a **positive recipe/contract**: state what a plan IS, its parts, in order.

This is also why I can't just write the text confidently. I don't yet know *which* content is bloating the plans. "Shorter" isn't actionable until I see the baseline.

## (2) Verification plan (this comes first, and gates everything)

**RED — establish the baseline (mandatory before writing anything):**
1. Run writing-plans WITHOUT any new guidance on 5+ realistic planning tasks.
2. For each bloated plan, **categorize the bloat by source**, e.g.:
   - Restated spec/context already available elsewhere
   - Narrative prose explaining reasoning
   - Repeated boilerplate per task
   - Over-detailed step-by-step that duplicates the codebase
   - Verbose rationale sections
3. Measure character counts and the proportion from each category. This tells me whether the problem is one dominant source or diffuse — and whether a recipe, a structural slot, or a conditional is the right tool.

**Micro-test the wording (before slow full scenarios):**
4. One API call per sample, system prompt = full writing-plans skill *with my candidate guidance*, user message = a planning task that tempts bloat.
5. **Include a no-guidance control.** If the control doesn't bloat on a given task, that task proves nothing — discard it.
6. 5+ reps per variant. **Read every plan manually** — char count alone lies (a tight plan with one long code block isn't bloat).
7. **Head-to-head: recipe wording vs. prohibition wording vs. control.** I expect prohibition to score worse than control. If it doesn't, my classification was wrong and I re-examine.
8. **Variance is a metric.** If 5 reps produce 5 different lengths/shapes, the form isn't binding yet — tighten the contract, don't add words.

**GREEN/REFACTOR:**
9. Run full scenarios with the winning wording. Verify plans shrink AND stay usable (no dropped essential detail).
10. Check the failure mode: does the recipe ever cause agents to *omit* something necessary? If so, that omission becomes a REQUIRED slot in the template.

## (1) Candidate guidance text — provisional, NOT deployable yet

I'll commit to a *direction* (positive recipe, since this is a shaping failure), but the specific length targets and slot list are placeholders until the baseline tells me what's actually bloating. Illustrative form:

```markdown
## What a Plan Is

A plan is a sequence of task contracts, not a narrative. Each task is:

- **Goal** — one sentence: what's true when done.
- **Files** — paths to touch.
- **Verification** — the command/check that proves the task is complete.

Reference the spec by pointing to it; the plan names what changes, not why the
feature exists. The reader already has the codebase — describe the delta, not
the current state.
```

Note this contains **no nuance clauses and no exemption clauses** ("keep it short unless it's complex" would reopen the negotiation; "this doesn't apply to code blocks" would still suppress code blocks). If code blocks need to survive, the recipe must structure them into a slot the rule can't reach.

## What I need from you

The exact field list and any length target are guesses until I see the baseline plans. If you can share 3–5 real bloated plans (or let me generate them via the RED step), I'll categorize the bloat, run the micro-tests against a control, and *then* give you wording I've actually watched succeed. Deploying the text above as-is would violate the Iron Law — I'd be shipping untested documentation.