I'm going to push back before making any change, because the Iron Law applies here: **no skill edit without a failing test first.** Right now I don't actually know that placeholders are a real baseline failure, what they look like when they happen, or which form of guidance would fix them. Let me be honest about what I'd do.

## First: I haven't earned the right to write the change yet

The request assumes the fix is "add a prohibition against placeholders." But per **Match the Form to the Failure**, this is almost certainly a *wrong-shaped-output* problem, not a *discipline* problem. The agent writing a plan isn't knowingly violating a rule under pressure — it's producing a plan with a gap because it doesn't yet have the detail. A prohibition ("never write TBD") backfires on shaping problems: under the competing incentive ("keep moving, fill it in later"), prohibition wording measurably produces *more* of the unwanted content than no guidance at all.

So I won't write a "don't use placeholders" rule on spec. I'd run the test first.

## (1) The change I would make — *provisionally*, pending baseline

My current best guess is a **structural contract**, not a prohibition: make "a task is not done until it's executable" a property of the task template the planner fills in. Something like a per-task completeness contract:

```markdown
## Task Completeness Contract

Each task must be dispatchable as-written by an implementer who cannot ask
you questions. Before a task is part of the plan, it specifies:

- the exact files/functions to change
- the concrete behavior or values (not "appropriate value", "the right config")
- how the implementer verifies it's done

If you don't yet know one of these, the task isn't ready — resolve it now or
split it into a spike task that produces the missing detail. A plan ships only
tasks that meet this contract.
```

Note what this deliberately avoids:
- **No "don't write TBD" list.** Banning the literal strings just moves the gap to synonyms ("finalize later", "appropriate value"). The contract targets the actual defect: *non-executability*.
- **No nuance/exemption clauses.** It doesn't say "unless the detail is minor." That reopens negotiation. The unknown is handled by a positive path (resolve or spike), keyed to an observable predicate ("you don't yet know X").

But I'd treat this wording as a hypothesis, not a finished edit. Which leads to verification.

## (2) Verification plan before deploying

**RED — establish the baseline (do this before writing anything final).**
- Dispatch subagents to write plans for 5+ realistic tasks where some detail is genuinely under-determined (e.g. "add caching to the API" without specifying the backend). Use the *current* writing-plans skill as the system context.
- Document verbatim: do they actually emit placeholders? In what form (literal "TBD", vague-language, deferred-decision)? If the baseline doesn't produce the failure, **I stop — there's nothing to fix**, and I report that the concern isn't reproducible.

**Micro-test the wording (cheap iteration before full scenarios).**
- One API call per sample, 5+ reps each, three variants in identical contexts:
  1. no-guidance control
  2. the prohibition version ("never use TBD / placeholders")
  3. the completeness-contract version above
- Read every flagged plan manually — vague language and quoted examples won't be caught by grepping for "TBD". Score: does each task meet the executable-as-written bar?
- Check **variance**: if the contract version converges (all reps produce executable tasks or explicit spikes) while the prohibition version scatters or inflates vague language, that confirms the form choice. If the contract doesn't bind, I tighten the form before adding words — not pile on more prohibitions.

**GREEN — full scenario pass.**
- Re-run the original RED scenarios with the winning wording inserted into writing-plans. Confirm placeholders are gone *and* I didn't introduce a new failure (e.g. planners over-spiking everything, or padding tasks with fake detail to satisfy the contract).

**REFACTOR.**
- Collect any new dodges ("I'll mark it as a known assumption instead"), decide if each is legitimate or a loophole, and adjust.

**Only after GREEN do I commit.** If you want, I can start by running the RED baseline so we're deciding from data rather than from the assumption that placeholders are actually happening.