I'm going to push back on starting with the change. The Iron Law applies here: **no skill edit without a failing test first.** I haven't watched a baseline fail, so I don't yet know what to write — or whether this needs writing at all.

Let me be honest about what I can and can't give you.

## What I will NOT do

Hand you a confident edit. I don't know yet:
- Whether plan-writing agents actually emit placeholders unprompted (maybe this is rare, and a mechanical check is the right tool, not skill prose)
- *What form* the failure takes — and the form of the failure determines the form of the fix

That second point is the crux. "Placeholder text" is plausibly an **omission/wrong-shape failure**, not a discipline failure. If so, a prohibition ("Never write TBD") is the wrong instrument and may *backfire* — agents under a competing pressure ("I don't have this detail yet") negotiate with "don't" and produce more hedging, not less. The right fix for an omission is usually **structural**: a contract for what a plan step IS, so "TBD" has no slot to live in.

So I can't write the change until I've classified the failure.

## (1) The change — described as a hypothesis, not a deliverable

Here's my *candidate*, explicitly contingent on testing:

**If baseline shows agents emit placeholders when they lack a detail**, the likely-correct edit is a positive contract, not a prohibition. Something like:

> **Every plan step must be executable as written.** A step states the concrete file, the concrete change, and the concrete acceptance check. If you don't yet know one of these, the step isn't ready — resolve it now (read the code, decide the design) or split it into a discovery step that produces the missing fact. A plan step is never a promise to figure something out later.

Note what this does NOT say: it doesn't say "never write TBD." It defines the shape (file + change + check) so a placeholder fails the shape on its own. I'd resist adding "don't use TBD/FIXME/fill-in-later" lists — exemption-style prohibitions tend to suppress legitimate content and invite loophole-hunting.

But this wording is a guess until micro-tested.

## (2) Verification plan (this is the real work, and it comes first)

**RED — baseline, before writing anything:**
1. Find 3–4 realistic plan-writing tasks where a detail is genuinely unresolved (unknown config key, undecided error-handling, ambiguous API). These are the conditions that *tempt* placeholders.
2. Run them through plan-writing **with no new guidance**. Record verbatim what agents emit.
3. **Decision gate:** if the control doesn't produce placeholders, stop — there's nothing to fix, and this is a non-problem or a job for a lint/regex check, not skill prose.

**Micro-test the wording (cheap, before full scenarios):**
4. System prompt = the real `writing-plans` skill with the candidate edit; user message = a temptation task. 5+ reps per variant.
5. Run **three variants** head-to-head: (a) no-guidance control, (b) prohibition wording ("never write TBD/placeholders"), (c) the contract wording above.
6. Read every output by hand — quoted counter-examples and template echoes masquerade as hits. Score: did the placeholder appear? Did the step come out executable?
7. **Variance is a metric:** if the contract wording produces 5 differently-shaped plans, it isn't binding yet — tighten the form before adding words. I expect (b) may underperform the control; if (c) doesn't clearly beat both, I rewrite, not ship.

**GREEN/REFACTOR:**
8. Take the winning wording into full plan-writing scenarios. Watch for new escapes ("I marked it as a follow-up," "the step is high-level on purpose").
9. Plug only the rationalizations that actually appear.

**Deploy only after the winning variant beats control across reps.**

Want me to start by drafting the 3–4 baseline temptation tasks so we can run RED?