I'm going to push back before doing what you asked, because the request skips the Iron Law.

## The problem with this request

**NO SKILL WITHOUT A FAILING TEST FIRST** — this applies to edits too. You've asked me to (1) write the guidance text and (2) plan verification afterward. That's writing the skill first and testing later, which is exactly the violation the skill forbids:

> Edit skill without testing? Same violation.
> Not for "just adding a section"

If I hand you guidance text now, you'll likely deploy it. So I won't lead with it.

There's also a substantive problem: **"make plans shorter" may be the wrong fix.** Teammate complaints about "bloat" are a symptom. The actual problem could be:
- Plans repeat information available elsewhere (fixable via cross-references)
- Plans include narrative/justification that belongs in commits
- Plans are appropriately long because the work is complex (and shortening would lose necessary detail)
- Only *some* plans are bloated (a few bad examples coloring perception)

Adding "keep plans short" guidance could cause agents to drop genuinely necessary detail, producing plans that are shorter but worse. I don't know which failure mode is real because **I haven't watched it fail yet.**

## What I'll do instead: RED first

### RED Phase — establish baseline before writing anything

1. **Gather the actual artifacts.** Collect 5–10 real plans that drew complaints. Measure them (`wc -c`) and read them. Categorize each long section as: necessary detail / redundant with other docs / narrative-that-belongs-elsewhere / over-specified.

2. **Run baseline scenarios with subagents** using the *current* writing-plans skill. Give them realistic planning tasks of varying complexity. Document verbatim:
   - Where do they add length? (Restating context? Justifying decisions? Copying code that could be referenced?)
   - Do simple tasks produce proportionally long plans?
   - What specifically makes a plan feel "bloated" vs "thorough"?

3. **Identify the pattern.** The baseline tells me the real cause. Only then do I know what guidance to write — e.g., "cross-reference existing docs instead of restating," or "no justification narrative," or "scale detail to task complexity." This is the equivalent of watching the test fail.

### GREEN Phase — write minimal guidance

Write guidance targeting *only* the patterns observed in baseline. I can't write the exact text now — it depends on what RED reveals. Writing it now would be guessing, and guesses go in untested.

### REFACTOR Phase

Re-run the same scenarios with the new guidance. Verify plans got shorter **without losing necessary detail** (this is the critical check — a one-sided "shorter is better" test would pass while making plans worse). Catch new failure modes (agents dropping required steps to hit a length target) and add counters.

## My actual answer to your two asks

**(1) Exact guidance text:** I'm not providing it yet, because I haven't run the baseline. Providing it now would violate the Iron Law and risk shipping guidance for a misdiagnosed problem.

**(2) Verification plan:** It's above — but note it goes *first*, not after. The verification (RED baseline) is what determines the guidance, not a check on guidance I already wrote.

If you want, give me a few of the complained-about plans and a couple of realistic planning tasks, and I'll run the baseline. The guidance will fall out of what we observe.