The Iron Law applies here, and I'm going to be upfront: I can't responsibly give you "exact guidance text to add" as step 1, because that would be writing the skill before watching the test fail.

Let me explain why, then give you the order I'd actually do this in.

## Why I'm reordering your request

Your request is "add guidance, then verify." That's writing code before the test. The writing-skills discipline requires:

```
NO SKILL WITHOUT A FAILING TEST FIRST
```

This applies to edits, not just new skills. "Just adding a section" is explicitly listed as a non-exception.

There's also a substantive problem hiding in the request. We have a *complaint* ("plans are bloated"), not a *diagnosis*. I don't yet know:

- Are plans long because they're **verbose** (fixable with guidance), or because they cover **genuinely complex work** (where shortening = removing necessary detail)?
- Are teammates complaining because plans are hard to *scan*, hard to *execute*, or just intimidating to *look at*?
- Would shorter plans actually serve the people who *execute* them, or just please the people who *read* them?

If I write "be concise" guidance and it causes future plans to drop necessary detail, I've made plans worse while feeling responsive. I need to see the failure mode before prescribing the cure.

## What I'd actually do

### RED — Establish baseline before writing anything

1. **Gather the actual artifacts.** Pull 3–5 of the "bloated" plans. Categorize where the 20k characters go: restated context, redundant explanations, necessary task detail, code blocks, hedging/preamble. This tells me whether the problem is bloat or complexity.

2. **Run baseline scenarios with subagents.** Dispatch subagents to write plans for 2–3 representative tasks (one simple, one complex) using the *current* skill. Measure length and inspect content. Document verbatim:
   - What makes plans long?
   - Is the length justified by the task?
   - Where is the genuine fat?

3. **Talk to / simulate the executors, not just the complainers.** Test whether a shortened plan still lets a fresh agent execute the task correctly. This is the real test: a plan that's short but unexecutable is a failure.

This is the part I cannot skip and cannot front-load with prescribed text — I have to *see* the failure before I know what to write.

### GREEN — Write minimal guidance targeting observed failures

Only after baseline do I write guidance, and it addresses the *specific* bloat patterns I observed — not generic "be concise." For example, if baseline shows plans restate context that's already in the repo, the guidance targets that specifically. I'd also be wary of putting a hard character limit in the description (that risks agents optimizing for length over executability — the same trap where a description summary overrides skill content).

### REFACTOR — Re-test for the regression I'm most worried about

Re-run the scenarios with the edited skill and check **both** directions:
- Did plans get shorter? (the requested outcome)
- Can a fresh subagent still execute them correctly? (the guardrail)

If shortening broke executability, I close that loophole and re-test.

## Verification plan (your item 2), stated concretely

| Phase | Check | Pass criteria |
|-------|-------|---------------|
| RED | Baseline 3–5 real plans + 2–3 fresh subagent-written plans | Documented where length comes from; identified real vs. necessary bloat |
| GREEN | Re-run same scenarios with edited skill | Plans measurably shorter on the *verbose* dimensions identified |
| REFACTOR | Fresh subagent executes a shortened plan with no extra context | Task completed correctly — shortening didn't remove needed info |

## What I need from you to proceed

Rather than deliver guidance text now, I'd like to start RED. Can you share a couple of the actual plans teammates are calling bloated? Or, if you'd prefer, I can generate baseline plans from sample tasks. Either way, I want to diagnose the bloat before prescribing the fix — otherwise I'm guessing, and guessed-at skill edits are how skills get worse.