I'll help, but I need to flag a process problem first and then do this correctly.

## The Iron Law applies here

**NO SKILL EDIT WITHOUT A FAILING TEST FIRST.** This is an edit to an existing skill, which the writing-skills training treats identically to a new skill. So before I write any guidance text, I need to watch the failure happen. But there's a deeper issue with the request itself.

## Classify the failure first

"Plans are bloated" is almost certainly a **wrong-shape** failure, not a **discipline** failure. The agent isn't knowingly violating a length rule under pressure — it's producing output with the wrong shape because nothing tells it what a plan IS.

This matters enormously, because the writing-skills training has a specific warning: **prohibition-based guidance backfires on shaping problems.** If I add "keep plans short / don't over-explain / avoid bloat," head-to-head testing predicts that wording scores *worse than no guidance at all* under a competing incentive (here: "make the plan complete and unambiguous").

So I can't just write the guidance you asked for. Let me do the RED phase before committing to any text.

## (1) Guidance text — provisional, pending verification

I would NOT write a prohibition. I'd write a **positive contract** that states what a plan section IS, in order. Provisional draft:

```markdown
## Plan Shape (Contract)

Each task in a plan has exactly these parts, in this order:

1. **Goal** — one sentence: what's true when this task is done.
2. **Files** — the specific files/functions touched.
3. **Approach** — the steps, as a numbered list. Reference existing
   code by name; do not reproduce it.
4. **Verification** — the command or check that proves the task works.

Reference, don't restate. If information already lives in the codebase,
the brief, or an earlier task, link or name it — the plan points to it
rather than copying it.
```

This is a contract (the output matches the shape or it doesn't), with no nuance clauses, no "unless it matters," no length number to negotiate against. The "reference, don't restate" line is phrased as a positive recipe ("point to it"), not a prohibition ("don't copy").

**But this is a guess until tested.** The verification plan below is the actual deliverable.

## (2) Verification plan (before deploying)

**RED — baseline, mandatory:**
1. Collect 3–5 real bloated plans, identify *where* the characters go. Is it restated code? Repeated context? Over-explained rationale? Verbose prose vs. many small tasks? **The fix depends entirely on this** — I won't write final guidance until I've seen the actual bloat pattern.
2. Run the existing writing-plans skill (no edit) on a few representative tasks with a realistic competing pressure ("the implementer has no context, make it self-contained"). Confirm the bloat reproduces. **If it doesn't reproduce, stop — there's nothing to fix.**

**Micro-test the wording (fast, before full scenarios):**
3. One API call per sample, system prompt = full writing-plans skill, user message = a planning task that tempts bloat.
4. **Three variants, 5+ reps each:** (a) no-guidance control, (b) the prohibition version you literally asked for ("keep plans short, don't over-explain"), (c) the contract version above. The control is non-negotiable — it tells me whether either version actually helps.
5. Measure character count AND read every output manually (template echoes and quoted examples masquerade as compliance). Track **variance**: if the contract version converges on the same shape across reps, the form is binding; five different interpretations means tighten it.
6. Expected and worth confirming: prohibition (b) ties or loses to control (c); contract beats both. If prohibition wins, my model is wrong and I re-investigate.

**GREEN/REFACTOR:**
7. Run full pressure scenarios with the winning wording. Add any new rationalizations/loopholes surfaced.
8. Confirm shorter plans don't lose *necessary* information (length isn't the real goal — correct shape is).

**Only then** commit and push.

**One honest pushback:** if testing shows the "bloat" is actually plans correctly capturing necessary detail, the right fix may be teammate expectations, not the skill. I'll know after RED, not before.