I'm going to push back before writing anything, because this request asks me to violate the Iron Law.

## The problem with this request

> **NO SKILL WITHOUT A FAILING TEST FIRST.** This applies to NEW skills AND EDITS to existing skills.

The request is "Add guidance text" and "your verification plan **before** deploying." That ordering is backwards. I cannot write the guidance text first and verify it after — that's tests-after, which the skill explicitly forbids. If I produce polished guidance text now, you'll likely deploy it, and the verification becomes theater.

So I won't hand you finished guidance text as item (1). Here's what I'll do instead.

## What we actually know — and don't

The complaint is "plans are bloated / 20k+ characters." That's a symptom, not a diagnosis. Before writing any guidance, I need to know *why* plans are long:

- **Are they long because they're verbose?** (fixable with concision guidance)
- **Are they long because the work is genuinely complex?** (then shortening loses necessary detail — a regression)
- **Are they long because of repetition/restating context?** (fixable, but different fix)
- **Are teammates conflating "long" with "hard to scan"?** (then the fix is structure, not length)

A guidance line like "keep plans under 5k characters" could easily make plans *worse* — agents will drop edge cases, acceptance criteria, or rollback steps to hit a number. We'd be optimizing a proxy metric.

## RED phase — what I'd do first (the real work)

1. **Gather baseline artifacts.** Collect several of the actual "bloated" plans teammates complained about. Find the genuinely wasteful parts vs. the load-bearing parts.

2. **Run baseline scenarios.** Have subagents (without any new guidance) write plans for 3–4 representative tasks of varying complexity. Measure length AND quality (does the plan still contain everything needed to execute?).

3. **Diagnose.** Categorize the bloat: redundant restating? over-explained rationale? unnecessary code dumps? Document verbatim what makes them long.

Only after I see *how* and *why* plans get long do I know what guidance to write. The guidance must address the specific failure mode, not a guessed one.

## GREEN phase — write minimal guidance

Write guidance targeting the diagnosed cause. Then re-run the same scenarios *with* the guidance and check both:
- Did length drop?
- **Did quality hold?** (the regression test — plans must still be executable)

## REFACTOR phase

If shortened plans now omit critical detail, add counter-guidance ("shorten prose, never drop acceptance criteria / rollback / edge cases"). Re-test until plans are both shorter and complete.

## Deliverables I can give you now

**(1) Guidance text:** I can't give you final text yet — I haven't watched the baseline fail, so I don't know what to write. Writing it now and verifying later violates the Iron Law and risks shipping a length-cap that degrades plans.

**(2) Verification plan:** The RED/GREEN/REFACTOR process above *is* the plan — and critically, the central success criterion is **shorter AND still complete**, not just shorter.

If you want, point me at the actual bloated plans and I'll start the RED phase. Want me to do that?