I'm going to push back before making any change, because the Iron Law applies here.

## The problem with your request

You've asked me to strengthen `writing-plans` to prevent placeholders. But I haven't watched the skill fail yet. Per my training:

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

Writing the edit first and testing later is exactly the violation the skill warns against. I also don't yet know:

- Whether `writing-plans` already addresses this (maybe it does and the real problem is elsewhere)
- What placeholders actually look like when an agent produces them under pressure
- What *rationalizations* lead an agent to write "TBD" — which is what any counter-text must target

If I write counters to rationalizations I'm guessing at, I'll produce plausible-sounding text that doesn't actually change behavior. So I won't hand you a finished edit. Here's the disciplined version of both deliverables.

## (1) The change I would make — RED phase first, not the edit

I cannot give you "the exact change" yet, because the exact change is *determined by* what baseline testing reveals. What I can commit to is the process and the shape of the eventual edit.

**RED — establish the baseline (before writing anything):**

Run 3+ pressure scenarios with subagents asked to produce a plan, *without* any new skill text. Pressures to combine:
- Time pressure ("we need this plan in 5 minutes")
- Incomplete information ("you don't have the API details yet")
- Sunk cost ("you've already drafted most of it")

Capture verbatim:
- Do they actually emit placeholders? In what form? ("TBD", "fill in later", "details to follow", empty sections, vague "handle errors appropriately")
- What reasoning precedes the placeholder? ("I'll note this and the implementer can figure it out")

If baseline plans *don't* contain placeholders, there is no test to make pass, and the right answer is **make no change** — the worry isn't real for this skill.

**GREEN — minimal edit targeting observed failures:**

Only after seeing real placeholders do I write text. The edit will likely be a focused addition (a "no placeholders" rule plus a rationalization table built from the actual excuses observed, plus a red-flags list), not a guess. I draft it, then re-run the *same* scenarios.

**REFACTOR:** plug whatever new rationalization the subagents invent, re-test until bulletproof.

Note: if placeholders turn out to be *mechanically detectable* (regex for "TBD", "fill in", "later"), the right fix may be a validation check rather than skill prose. My training says don't document what you can automate.

## (2) Verification plan before deploying

1. **Baseline (RED):** 3+ combined-pressure scenarios, no edit. Document behavior verbatim. If no placeholders appear → stop, deploy nothing.
2. **Identify patterns:** group the rationalizations that produced placeholders.
3. **Write minimal edit (GREEN):** address those specific rationalizations only.
4. **Re-test same scenarios with edit:** confirm placeholders disappear under the pressures that previously caused them.
5. **REFACTOR:** capture any new loophole, add explicit counter, re-test until agents comply under maximum pressure.
6. **Description check:** ensure I did NOT add a workflow summary to the `description` (triggers only).
7. **Deploy:** commit and push only after GREEN holds.

Want me to start the RED phase by drafting the baseline scenarios?