I'm going to push back before making any change, because the request as framed violates the Iron Law I'm bound by.

## The problem: no failing test yet

The Iron Law applies to **edits** as much as new skills:

```
NO SKILL WITHOUT A FAILING TEST FIRST
```

> Edit skill without testing? Same violation.

I haven't watched an agent fail. I don't actually know:
- Whether agents *naturally* write placeholder-laden plans (maybe they rarely do)
- *Why* they do it when they do (laziness? genuine unknowns? scope too large?)
- What rationalizations they use ("I'll fill this in during implementation," "this is a reasonable stub")

Without baseline data, any text I write is a guess. I'd be writing production code before the test. So I won't hand you a polished diff and call it done. Here's what I'll actually do.

## Possible mechanical-vs-judgment check first

One thing to flag from my training:

> Mechanical constraints (if it's enforceable with regex/validation, automate it—save documentation for judgment calls)

"TBD" / "fill in details later" / "XXX" / "..." are *partly* detectable by regex. If the real goal is to stop wasted dispatches, a lint check on plans before dispatch may catch the blatant cases more reliably than prose ever will. The skill text should only handle the *judgment* part: knowing when a section is genuinely under-specified even without a banned keyword. I'd raise this with you before assuming the answer is "more documentation."

## (1) The exact change I would make

**I can't give you the exact final text yet** — that's determined by what the baseline reveals. What I *can* commit to is the GREEN-phase shape: a minimal addition to writing-plans that targets only the specific failures observed in RED. Likely a "Plans Must Be Complete" section plus a rationalization table, e.g.:

```markdown
## No Placeholders

A plan with placeholders is not a plan — it's a request for the implementer
to do design work mid-dispatch, which is exactly what planning prevents.

**Forbidden:** "TBD", "fill in later", "details to follow", "...", empty
steps, "figure out during implementation".

**If you don't know something yet, you are not done planning.** Resolve it
now, or explicitly scope it out — don't defer it into the plan body.
```

Plus a rationalization table built **from the actual excuses observed in baseline**, not invented ones. The wording above is provisional and will change based on RED.

## (2) Verification plan before deploying

This is discipline-enforcing, so I follow RED → GREEN → REFACTOR with pressure scenarios.

**RED — establish baseline (mandatory, before writing anything):**
1. Write 3+ pressure scenarios for a subagent: large/ambiguous feature, time pressure ("we need this plan fast"), and genuine unknowns (an API detail not yet decided).
2. Dispatch subagents to write plans **without** the edit.
3. Record verbatim: do they use placeholders? Which phrasings? What rationalizations? Note whether failures are blatant (regex-catchable) or subtle (under-specified without banned words).

**Decision gate:** If agents rarely produce placeholders, or failures are purely mechanical → reconsider whether a doc edit is even the right fix (maybe a lint check instead). Report this back to you rather than forcing the change.

**GREEN — write minimal edit:**
4. Add only enough text to counter the *observed* rationalizations.
5. Re-run the same scenarios **with** the edit. Confirm compliance.

**REFACTOR — close loopholes:**
6. Capture any new rationalizations ("this isn't a placeholder, it's a note") and add explicit counters / red-flags list.
7. Re-test until bulletproof under combined pressure.

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

Want me to start the RED phase by drafting the three pressure scenarios so we can watch it fail?