I'm going to push back on the framing before proposing a change, because the Iron Law applies here: **no skill edit without a failing test first.** I haven't watched anything fail yet, so I can't responsibly hand you "the exact change."

Here's how I'd actually proceed.

## First: classify the failure (don't skip this)

"Plans contain placeholder text" is a *worry*, not an observed baseline. Two very different failure types hide under it, and they need opposite forms:

1. **Discipline failure** — the planner knows placeholders are bad but writes "TBD" anyway under pressure (it doesn't yet know the detail). → prohibition + rationalization table.
2. **Wrong-shape output** — the planner produces an under-specified task and a placeholder is just the symptom. → a positive contract for what a task must contain.

My bet, before testing, is that this is mostly #2: a placeholder is what an agent emits when it doesn't have a structural slot forcing it to resolve the detail. If that's right, a "never write TBD" prohibition will backfire — agents under "I don't know this yet" pressure negotiate with prohibitions and produce *more* hand-waving ("to be determined during implementation", "the exact approach will depend on..."), just without the searchable string "TBD."

So I won't write a prohibition until a no-guidance control proves the discipline failure exists.

## (1) The change I would make — *conditional on testing*

I'll commit to the **form**, not the final wording, since wording gets micro-tested.

**If micro-tests confirm wrong-shape (expected):** add a positive structural contract to writing-plans — every task names the file(s) it touches and states the concrete change, with no unresolved decisions left for the implementer. The plan author resolves the decision or the task isn't ready. This gives the agent a slot it must fill rather than a string it must avoid.

**If micro-tests confirm a genuine discipline failure too:** add a narrow conditional keyed to an *observable predicate*, not a blanket ban:

> If you can't yet specify a task concretely, the decision belongs in the plan's design/research phase, not deferred into the task. A task you can't write concretely is not ready to dispatch.

Plus a rationalization-table row capturing the *verbatim* excuse from baseline (e.g. "the implementer can figure out the exact approach").

No nuance clauses, no "avoid placeholders unless necessary" — that reopens the negotiation.

I am **not** outputting frozen markdown now, because writing the skill before watching it fail is the violation this whole skill exists to prevent.

## (2) Verification plan before deploying

**RED — baseline, no guidance**
- 5+ planning tasks that *tempt* the failure: ask for a plan where one task depends on a detail the planner can't know yet (an unchosen library, an unmeasured threshold, an unread file).
- Run writing-plans **without** the new guidance. Record verbatim how tasks get under-specified.
- **If the control doesn't produce placeholders/hand-waving, stop and ship nothing** — the worry isn't real, and a prohibition would only add tokens and backfire risk.

**Micro-test the wording (cheap, before full scenarios)**
- One API call per sample; system prompt = full writing-plans skill including the candidate change; user message = a temptation task.
- Always include the no-guidance control head-to-head.
- 5+ reps per variant. Read every flagged match by hand — "TBD" is easy to grep, but "approach TBD during implementation" rephrased as prose won't grep, and template echoes will false-positive.
- Variance is the metric: if 5 reps resolve the task 5 different ways, the form isn't binding — tighten before adding words. Compare prohibition wording vs. positive-contract wording directly; I expect the contract to win.

**GREEN**
- Re-run the baseline scenarios with the chosen form. Tasks should come out concretely specified, or the planner should explicitly route the unknown into the design phase.

**REFACTOR**
- Any new dodge ("I'll note it as a follow-up", "implementer has discretion here") → add a rationalization row (only if it's a discipline skill) or tighten the contract slot, re-test until reps converge.

**Deploy** only after GREEN holds: commit, push, consider a PR.

If you can share a couple of real plans that actually wasted dispatches, I'll use those as the seed scenarios — real failures make better tests than ones I invent.