The Iron Law applies here: **NO SKILL EDIT WITHOUT A FAILING TEST FIRST.**

I won't write the change yet. Let me explain why, then give you what you actually need.

## Why I'm not just writing the edit

You've described a *worry* ("plans may sometimes contain placeholders"), not an *observed baseline failure*. I haven't watched an agent writing a plan actually produce "TBD" under realistic conditions. Without that, I'd be writing production code (the skill edit) against a hypothetical test. That's exactly the violation this skill forbids — even for "just adding a section."

So the honest answer to "(1) the exact change" is: **I don't know it yet, because I haven't run RED.** Here's the process I'd actually follow.

## RED Phase — write the failing test first

**Goal:** Reproduce the placeholder behavior in a baseline subagent WITHOUT touching writing-plans.

Pressure scenarios (writing-plans is discipline-adjacent, so I'd combine pressures):

1. **Incomplete information:** "Write an implementation plan for feature X. The auth strategy hasn't been decided yet." — Does the agent emit "TBD: decide auth later"?
2. **Time pressure:** "We need this plan in the next few minutes, just get the structure down." — Does it leave sections stubbed?
3. **Deference:** "The team will fill in the API details, just sketch it." — Does it punt with placeholders?

I'd run each 2-3 times and **record the verbatim output**:
- Exact placeholder phrasings ("TBD", "fill in later", "[details here]", empty sections)
- The *rationalizations* the agent gives for leaving them

**If the baseline doesn't produce placeholders**, there's nothing to fix and I'd report that back to you instead of inventing a problem. This is the most likely way the edit gets *cancelled* — and that's a good outcome.

## GREEN Phase — minimal edit addressing actual failures

Only after seeing real failures would I write the change, targeting the *specific* phrasings and rationalizations observed. The likely shape (to be confirmed by RED):

- A rule near the top: a plan with unresolved decisions is **not done** — resolve the decision or stop and ask, never placeholder it.
- A counter to the rationalization RED reveals (e.g., "info is missing → ask the human, don't stub").
- A red-flags list seeded with the *actual verbatim* placeholder strings agents produced.

I would NOT pre-write generic counters for excuses no agent actually made.

## REFACTOR Phase — close loopholes

Re-run the same scenarios WITH the edit. New evasions (e.g., vague-but-not-"TBD" hand-waving like "configure as appropriate") go into the rationalization table. Repeat until bulletproof.

## Verification plan before deploying

- [ ] RED: 3 pressure scenarios × 2-3 runs, baseline behavior captured verbatim
- [ ] Confirm a real, reproducible failure exists (else: cancel the edit, report findings)
- [ ] GREEN: write minimal edit targeting observed phrasings; re-run same scenarios → compliance
- [ ] REFACTOR: capture new evasions, add counters, re-test until clean
- [ ] Word-count check (writing-plans isn't always-loaded, but stay concise)
- [ ] Commit + push

## One automation check first

Before any of this: "TBD"/"fill in later" is partly **mechanically detectable**. Per the skill's "Don't create for... mechanical constraints" guidance, a regex/lint check on plans (`TBD`, `fill in`, `\[.*later.*\]`, empty `##` sections) catches the literal cases far more reliably than documentation. I'd recommend that as a complement — and reserve the skill edit for the *judgment* part (resolve vs. ask the human), which is what actually needs prose.

Want me to start the RED phase and bring you the baseline transcripts?