This is exactly the kind of request where the writing-skills discipline saves me from shipping something that backfires. Let me work the problem properly rather than just drafting text.

## First: classify the failure (and refuse to skip the baseline)

The Iron Law applies to edits, not just new skills: **no skill change without a failing test first.** I haven't watched a single plan get generated, so I don't actually know *why* plans are 20k characters. "Make plans shorter" is a symptom report, not a diagnosis. Before writing any guidance I need to know which failure type this is, because **the form that fixes one type backfires on another.**

Candidate causes — and they need different forms:

| Likely cause | Failure type | Right form |
|---|---|---|
| Plan restates the whole spec / narrates reasoning | Wrong-shaped output | Positive recipe: state what a plan section IS |
| Plan includes full code listings instead of pointers | Wrong-shaped output | Contract for the "implementation" slot |
| Plan covers hypothetical edge cases nobody asked for | Wrong-shaped output | Conditional keyed to a predicate |
| Agent knows to be terse but pads under "be thorough" pressure | Discipline failure | Prohibition + rationalization table |

**A prohibition ("don't pad", "never restate the spec", "keep it under 8k chars") is the wrong tool if this is a shaping problem** — head-to-head, prohibition wording produced *more* of the unwanted content than no guidance at all when a competing incentive ("make it self-contained") was present. So I will not write "don't" guidance until baseline proves agents know better and pad anyway under pressure.

So I cannot honestly give you the "exact guidance text" yet. What I *can* give you is the guidance I'd draft **conditional on the most likely baseline finding**, plus the verification that gates it. If you want, I'll run the baseline and revise.

## Provisional guidance text (contingent on baseline)

My prior, before testing: bloat is wrong-shaped output (restated spec + inlined code), not indiscipline. So I'd draft a **positive recipe**, not a length limit. Draft to be tested:

```markdown
## What a Task Looks Like

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

1. **Goal** — one sentence: what is true after this task that wasn't before.
2. **Files** — the paths you will touch (not their contents).
3. **Change** — the specific edit as a pointer, not a transcript:
   reference functions/symbols by name and describe the delta.
   If a snippet is genuinely load-bearing (a non-obvious signature,
   a tricky regex), include only that fragment.
4. **Verification** — the command or test that proves the task done.

Reference the spec by section; do not restate it. The plan is a set of
pointers an implementer expands, not a document they read instead of the code.
```

Note what this deliberately is NOT:
- **No character/line limit.** A hard cap is a prohibition; it backfires under "be thorough" and gives no guidance on *what* to cut.
- **No "don't restate the spec" exemption clause.** "Don't restate unless it matters" reopens the negotiation. The recipe simply has no "restate" slot, so there's nothing to restate into.
- The **"if genuinely load-bearing" clause for snippets is keyed to a predicate** (non-obvious signature / tricky regex), not "unless it matters" — that's a real conditional, not a nuance escape hatch.

## Verification plan (the actual deliverable)

I will not deploy until this passes. Order matters — cheap checks first.

**1. RED — baseline, no edit (mandatory gate).**
Run the *current* writing-plans skill on 3–4 real planning tasks of varying size. Measure: char count, and *where* the characters go (restated spec? inlined code? hypotheticals? per-task overhead?). 
- If plans are NOT actually bloated on these tasks → stop, there's no failure to fix.
- The category breakdown picks the form. If bloat is restated-spec/inlined-code → recipe (above). If it's "agent pads under thoroughness pressure despite knowing better" → switch to prohibition + rationalization table instead.

**2. Micro-test the wording before any full run.** Per the cheap-iteration rule:
- System prompt = the *full* writing-plans skill with the draft section inserted (realistic context, not the snippet alone).
- User message = a planning task that tempts bloat (a feature with a long spec + obvious code).
- **Include a no-guidance control** (current skill unchanged) every time.
- 5+ reps per variant. Read every output by hand — restated-spec echoes and "load-bearing snippet" judgment calls won't survive automated counting.
- Metrics: median char count vs control; how much spec is restated; and **variance** — if 5 reps produce 5 different shapes, the recipe isn't binding yet, tighten it before adding words.

**3. Guard against the opposite failure.** Shorter is not the goal; *useful and shorter* is. So one micro-test reps a task where a snippet genuinely IS load-bearing, and I check the recipe didn't suppress it (the exemption-clauses-don't-scope trap). A plan that's terse but unimplementable is a regression, not a win.

**4. GREEN/REFACTOR.** Only after micro-tests converge, run full plan-generation on the baseline tasks. Compare against RED. Capture any new rationalizations; if the failure turns out to be discipline-flavored, add the rationalization table then — earned by evidence, not assumed.

**Bottom line:** I'm giving you a *candidate* recipe and a verification plan, not a finished edit, because I haven't watched it fail yet. Tell me to proceed and I'll run the baseline — that's what decides whether this recipe ships, gets reshaped into a prohibition, or turns out to be unneeded.