I'm going to push back before proposing any change, because what you've described is a textbook case for automation, not documentation.

## The core problem

Your skill-writing training is explicit on this point:

> **Don't create [skills] for:** ... Mechanical constraints (if it's enforceable with regex/validation, automate it—save documentation for judgment calls)

"Plan contains the literal strings 'TBD' or 'fill in details later'" is a mechanical constraint. A regex catches it. Adding prose to `writing-plans` telling agents "don't write TBD" is:

1. **The wrong tool.** A determined or distracted agent will still write placeholders; documentation doesn't enforce anything. A pre-dispatch validation check actually *prevents* the wasted dispatch.
2. **Token cost on a frequently-loaded skill.** `writing-plans` plausibly loads often. Every word competes with judgment-call content that genuinely needs prose.
3. **Untestable as a discipline rule in any meaningful way.** The real failure ("vague placeholder that *isn't* literally 'TBD'") is a judgment call regex can't catch — and prose can't reliably catch either.

So my honest recommendation: **build a placeholder linter that runs before implementer dispatch**, not a skill edit. That's the change that actually stops wasted dispatches.

## If you still want the skill edit

I won't write it yet — the Iron Law forbids it:

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

I have not watched an agent fail. I don't know whether agents writing plans actually emit placeholders, under what pressure, or with what wording. Writing the edit now would be guessing at the fix. So here is the process, in order:

### (1) The exact change — deferred until RED

I will not produce edit text before baseline testing. What I *can* commit to now is the shape constrained by what I learn:

- **If** baseline shows agents emit placeholders under pressure (e.g., "this section is complex, I'll note it as TBD and move on"), the GREEN edit addresses *those specific rationalizations* — likely a short "Plans must be dispatch-ready" rule plus a rationalization table built from observed verbatim excuses, plus a red-flags list ("about to write 'figure out later'").
- The edit stays minimal — no content for hypothetical placeholder phrasings I didn't observe.
- It will **not** touch the description's workflow (descriptions state triggers only).

### (2) Verification plan before deploying

**RED — watch it fail (mandatory, first):**
- Write 3+ pressure scenarios: complex/ambiguous spec + time pressure + partial information ("you don't have access to the schema yet"). These are the conditions that *cause* placeholders.
- Run each with a subagent against the **current** `writing-plans`, no edit.
- Record verbatim: do they emit placeholders? What words ("TBD", "to be determined", "stub", "TODO", "details later")? What rationalization precedes it?
- If baseline produces zero placeholders → there's no bug to fix. Stop. Don't edit.

**GREEN — write minimal edit, re-test:**
- Edit addressing only observed rationalizations.
- Re-run identical scenarios with the edit. Confirm placeholders disappear.

**REFACTOR — close loopholes:**
- Catch new evasions ("I'll just leave this section thin"), add explicit counters, re-test until bulletproof.

**Then decide tool vs. doc:**
- If baseline placeholders are mostly literal known strings → the linter wins; skip or minimize the skill edit.
- If they're genuine judgment-call vagueness regex can't see → keep the (now-tested) skill edit.

Want me to start RED by drafting the three pressure scenarios?