Before I make any change, let me flag the Iron Law: **no skill edit without a failing test first.** I haven't watched a baseline fail yet, so anything I write now is a guess. Here's how I'd approach it honestly.

## First: classify the failure (don't write yet)

The request assumes placeholders happen and that prohibition is the fix. But I don't know the actual failure shape until I run a baseline. Two very different failures could produce "TBD"-style text:

1. **Discipline failure** — the agent knows the plan should be complete but writes "fill in later" under time/laziness pressure. → prohibition + rationalization table is the right form.
2. **Shaping failure** — the agent doesn't know what a complete task spec looks like, so it leaves gaps that happen to read as placeholders. → a *positive recipe/contract* for what each task must contain. Prohibitions would backfire here (per "Match the Form to the Failure").

I can't pick the form until the baseline tells me which one I'm seeing. So the change below is a **draft conditional on baseline results**, not a finished edit.

## (1) The exact change I would make — *only after baseline confirms the failure type*

Assuming the baseline shows a **shaping failure** (my prior — agents usually leave gaps because they don't know the required shape, not out of defiance), I'd add a positive contract to the task template in writing-plans, expressed as REQUIRED structural slots rather than a "don't write TBD" prohibition:

```markdown
## Every task must be executable as written

A task is complete when an implementer could execute it without asking
you anything. Each task REQUIRES, filled with concrete values:

- **Files**: exact paths to create/edit (not "the relevant file")
- **Change**: the actual code, signature, or precise description — not
  a reference to "details below" that don't exist
- **Verification**: the exact command and expected result

If you cannot fill a slot with a concrete value, the task is not ready
to dispatch. Resolve the unknown now (read the code, ask the human) or
split it into a research task that produces the missing value.
```

If the baseline instead shows a **discipline failure** (agent knowingly defers), I'd additionally add a rationalization table + red-flags list with the specific verbatim excuses from the baseline ("I'll note it as TBD and the implementer can figure it out", etc.).

I would **not** ship a bare "Never use TBD / placeholder text" prohibition — string-matching "TBD" is a mechanical constraint better handled by a validation/regex check than by skill prose, and a prohibition on shaping failures measurably backfires.

## (2) Verification plan before deploying

**Micro-test the wording first (cheap, fast):**
- System prompt = the realistic context (full writing-plans skill with the draft change). User message = a planning task that tempts gaps (under-specified feature, time pressure).
- **Include a no-guidance control** (writing-plans without the change). If the control doesn't produce placeholders, there's nothing to fix — stop and don't ship.
- 5+ reps per variant. Read every flagged "TBD/placeholder" match manually — quoted counter-examples and template echoes masquerade as hits.
- Check variance: with the recipe landing, reps should converge on concrete, filled-in tasks. Five different shapes = wording isn't binding yet.

**Then RED-GREEN-REFACTOR with pressure scenarios:**
- **RED**: run 3+ combined-pressure scenarios (time + sunk cost + "just get the plan out") WITHOUT the change. Record verbatim rationalizations and *whether the failure is shaping or discipline*. This decides which form from (1) I actually ship.
- **GREEN**: add the minimal matching form, re-run same scenarios, confirm tasks come out executable.
- **REFACTOR**: capture any new loopholes ("I'll write a stub task"), counter them, re-test until stable.

**Deploy only after** GREEN holds under pressure. Also flag to you: if the real goal is catching the literal string "TBD" before dispatch, a pre-dispatch validation check is more reliable than documentation — I'd recommend that alongside (or instead of) the skill edit.

Want me to run the baseline now so we can confirm the failure type before I commit to either form?