This task tempts me to skip straight to writing guidance. Let me apply the skill faithfully — starting with the Iron Law and classifying the failure type.

## Stop: I cannot write final guidance text yet

**The Iron Law:** No skill (or edit) without a failing test first. I haven't watched a baseline fail, so I don't yet know what guidance to write. But I can tell you what I *will* do, and flag the trap this request walks into.

## First: classify the failure (Match the Form to the Failure)

"Plans are bloated / too long" is almost certainly a **wrong-shaped output** problem, not a discipline problem. The agent isn't knowingly violating a rule under pressure — it's producing the wrong shape (restating context, narrating reasoning, padding).

This matters enormously, because the obvious guidance is the wrong form:

- ❌ **Prohibition** ("Don't pad. Never restate the spec. Keep it short. Target <8k chars.") — the skill explicitly warns this *backfires* on shaping problems. Under a competing incentive ("make the plan complete and self-contained"), agents negotiate with "don't X" and produce *more* of the unwanted content. A raw length cap also has the exemption-clause failure mode: "this limit doesn't apply to code blocks" still suppresses code blocks.
- ✅ **Positive recipe / contract** — state what a plan section *IS*: its parts, in order. A recipe leaves nothing to negotiate.

So my real deliverable is a **structural contract for plan sections**, not a length rule. But I won't finalize wording until I've micro-tested it.

## (1) The guidance text — DRAFT, not deployable

I can show a candidate, but I am explicitly **not** treating this as final. It must survive baseline + micro-tests first.

> ## What a plan task contains
>
> Each task is exactly these parts, in this order. Nothing else.
>
> 1. **Goal** — one sentence: what is true when this task is done.
> 2. **Changes** — the specific files/functions to touch, as a bullet list. Name them; don't explain them.
> 3. **Verification** — the command or check that proves the task works.
>
> Reference shared context by pointer, not by copy: link the spec/design doc; do not restate it. If a reader needs the "why," the linked doc carries it.

Whether this exact text ships depends on what testing shows. The wording above is a hypothesis.

## (2) Verification plan (this is the actual answer)

**RED — establish baseline (mandatory, no skipping):**
1. Run writing-plans WITHOUT any new guidance on 2–3 realistic planning tasks. Capture the actual ~20k-char output.
2. Identify *where* the bloat lives — measure it. Is it restated spec? Narrated reasoning? Redundant per-task preamble? Verbose prose where a list belongs? The fix must target the actual source. "It's long" isn't a diagnosis.

**Micro-test the wording before full scenarios** (fast, cheap, do this first):
3. One API call per sample. System prompt = the full writing-plans skill *with* the candidate recipe; user message = a planning task that tempts bloat (e.g. "plan this against the attached 3-page spec").
4. **Include a no-guidance control.** If the control isn't bloated on these tasks, there's nothing to fix — stop and don't ship guidance.
5. 5+ reps per variant. Read every output manually — char-count alone lies (a plan can be short and useless, or template echoes can masquerade as compliance).
6. Compare candidate **recipe** head-to-head against a candidate **prohibition** ("keep plans short, don't restate spec, target <8k") and the control. The skill predicts the prohibition will score *worse* than control; verify that here rather than trusting me.
7. **Variance is a metric.** If 5 reps of the recipe converge on the same 3-part shape, the form is binding. If they sprawl differently, tighten the structure before adding words.

**GREEN:** Re-run the original baseline planning tasks WITH the winning wording. Check: are plans shorter *and still actionable*? A plan an implementer can't execute is a regression, not a win.

**REFACTOR:** If shortening dropped something load-bearing (verification steps, file targets), that's a new failure — fold the missing element back in as a REQUIRED slot in the recipe, re-test.

**Quality gate before deploy:** confirm I didn't introduce nuance/exemption clauses, the description still describes *when to use* (not workflow), and changes are committed.

## Bottom line

I'm declining to hand you finished, deploy-ready guidance, because doing so would violate the Iron Law and risk shipping the backfiring form. The draft recipe is a starting hypothesis; the verification plan above is the deliverable that turns it into something safe to ship.