I need to stop and flag a problem before doing anything else: the request asks me to strengthen a skill, but the Iron Law applies to **edits** too.

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

This applies to NEW skills AND EDITS to existing skills — explicitly, including "just adding a section" and "documentation updates." So I cannot honestly hand you "(1) the exact change" as a first step. Writing the change before running the baseline test is the violation the skill forbids.

Here's how I'd actually proceed, in the correct order.

## Why I won't write the change first

The whole point of the RED phase is that I don't yet know:

- **Whether the problem is real.** Do agents writing plans actually emit "TBD"/"fill in later"? Under what pressure? I'm working from your *worry*, not observed baseline behavior.
- **What the actual failure looks like.** If placeholders appear, what's the rationalization? "I'll flesh this out during implementation"? "This part depends on the previous task"? "I don't have enough info yet"? The skill text must counter the *specific* rationalizations, and I can only get those verbatim from baseline runs.
- **Whether documentation is even the right fix.** The skill says: "Mechanical constraints (if it's enforceable with regex/validation, automate it)." Detecting literal strings like `TBD`, `fill in later`, `XXX`, `<placeholder>` may be better handled by a validation check than by more prose nobody reads. The baseline tells me whether placeholders are mechanical (catchable by regex) or judgment calls (vague-but-not-literal under-specification).

So "(1) the exact change" is premature. What I can commit to is the test that has to fail first.

## RED phase — what I'll run before writing anything

**Scenario design** (3+ combined pressures, since "don't leave placeholders" is discipline-enforcing):

1. **Time pressure:** "We need this plan in the next few minutes, ship what you have."
2. **Missing information:** Give a feature where one task genuinely depends on a decision not yet made (tempts "TBD until we decide").
3. **Sunk cost / length:** A large multi-task plan where the last tasks are tedious (tempts "details later").

Run each scenario with a subagent using the **current, unmodified** writing-plans skill. Capture verbatim:

- Whether placeholders appear, and their exact form (literal `TBD` vs. vague under-specification).
- The exact rationalization language.
- Which pressure triggered it.

**If the baseline doesn't fail** (agents already write complete plans), then there is no change to make — adding text would be untested production code for a bug that doesn't exist. I'd report that back rather than invent a fix.

## GREEN phase — minimal change addressing observed failures

Only after seeing real failures would I write the change, and only enough to counter the *observed* rationalizations. Likely shapes (decided by what RED reveals):

- If placeholders are **literal strings**: lean toward a mechanical validation step (regex for `TBD|FIXME|XXX|fill in|later|placeholder|<...>`) rather than prose, per the skill's "automate mechanical constraints" guidance — possibly a small check script, with only a brief pointer in SKILL.md.
- If placeholders are **judgment-level under-specification**: add a Red Flags list + a rationalization table with the exact verbatim excuses ("I'll flesh this out during implementation," etc.) and an explicit rule like "Every task must be implementable by an agent who can see only that task."

I'd also check token budget — if writing-plans is frequently loaded, the addition must stay tight (`wc -w`).

## Verification plan before deploying

1. **Re-run the identical baseline scenarios WITH the change.** Confirm placeholders no longer appear under the same pressures (GREEN).
2. **REFACTOR:** Note any *new* rationalization the agent invents to evade the new text; add an explicit counter; re-test until bulletproof.
3. **Description check:** Ensure I did *not* add a workflow summary to the description (SDO trap) — only triggering conditions.
4. **If I added a validation script:** test it on plans with and without placeholders (true positives + no false positives on legit text like "we'll iterate later on perf" outside task bodies).
5. **Commit only after tests pass**, then push to fork / consider PR.

## Summary

- **(1) Exact change:** I can't responsibly produce it yet — that's writing production code before the failing test. I'll produce it during GREEN, shaped by baseline output, and it may turn out to be a validation script rather than prose.
- **(2) Verification:** baseline RED → minimal change → re-run same scenarios for GREEN → refactor new loopholes → false-positive check → commit/push.

Want me to go ahead and run the RED baseline scenarios against the current writing-plans skill now?