I'm going to push back before making any change, because the Iron Law applies here and so does a form-classification step that this request skips.

## What I will NOT do

I won't write the edit first. Editing a skill without a failing test is the same violation as writing one without a test. So my "exact change" can't be produced responsibly until after baseline testing. But I can tell you the change I'd *draft as a hypothesis* and how I'd validate it — with the explicit caveat that the wording may change after I watch it fail.

## Step 0: Classify the failure (Match the Form to the Failure)

"Placeholder text like TBD" is almost certainly **not a discipline failure**. A discipline failure is "the agent knows the rule and skips it under pressure." Placeholders are more likely a **wrong-shaped-output** problem: the agent writes a plan and leaves a slot vague because it doesn't have the detail yet, or because the plan template invites a stub.

This distinction decides the form:

- If it's wrong-shaped output → **prohibitions backfire.** "Never write TBD" measurably produces more evasion ("details to be determined during implementation") than no guidance. The fix is a **positive contract**: state what a plan step IS — concrete enough to execute without further decisions.
- If it's genuine discipline (agent knowingly punts) → prohibition + rationalization table is right.

I don't yet know which. That's exactly what RED phase is for.

## Step 1: RED — baseline before writing anything

1. **Micro-test first (cheap).** 5+ reps per variant, one API call each.
   - System prompt: the *current* writing-plans skill, unmodified.
   - User message: realistic plan-writing tasks that *tempt* placeholders — e.g. "write a plan to add OAuth login" where some details (provider choice, token storage) aren't specified.
   - Score: read every output manually. How many leave TBD/"decide later"/vague stubs? What form do they take? Capture verbatim.
2. **No-guidance control is mandatory.** If the unmodified skill already produces clean plans, **there is nothing to fix — stop.** Don't author guidance for a problem that doesn't reproduce.
3. **Characterize the failures.** Are stubs left because (a) the agent lacks the info, or (b) the agent is lazy/punting? (a) is a shaping/conditional problem; (b) is discipline.

## Step 2: GREEN — the change I'd draft (hypothesis, pending RED)

Assuming RED shows wrong-shaped output (the likely case), I would add a **positive contract** to writing-plans, not a prohibition list:

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

A plan step is a complete instruction an implementer can carry out
without making a design decision. Each step states:
- the exact file(s) or component to change,
- the concrete change (signatures, values, behavior), and
- how to know it's done.

If you don't yet have a detail needed to make a step executable,
the plan isn't ready for that step. Resolve it now — make the
decision, or split out a research/decision step that produces the
missing detail. Do not leave the decision for the implementer.
```

Note what this deliberately avoids:
- **No "never write TBD" prohibition** — that invites synonym evasion.
- **No nuance/exemption clause** — "unless the detail is genuinely unknowable" reopens negotiation.
- The unknown-detail case is handled by a **conditional on an observable predicate** ("if you don't have the detail → resolve it now or make it its own decision step"), not by an exception to a rule.

If RED instead shows genuine discipline (agent knowingly punts despite having info), I'd *add* a rationalization table and red-flags list keyed to the verbatim excuses from baseline.

## Step 3: Verification before deploying

1. **Micro-test the wording head-to-head**, same harness as RED, 5+ reps each:
   - control (no guidance),
   - my recipe wording,
   - a prohibition phrasing ("never use TBD…") as a comparison.
   Expect the recipe to beat both; if prohibition wins, my failure-classification was wrong — go back to Step 0.
2. **Read every flagged match manually.** Template echoes and quoted examples masquerade as hits. Automated counts overstate both directions.
3. **Variance is a metric.** If the 5 reps under my wording converge on similarly-concrete steps, the form is binding. Five different interpretations = tighten the form, don't add words.
4. **Full pressure scenarios** only after wording passes micro-tests: real plan tasks under time pressure / missing-info pressure to confirm it holds when the agent is tempted to punt.
5. **Re-test for backfire:** confirm the guidance didn't suppress legitimate content (e.g. plans that correctly defer a decision into an explicit decision step).

Only after micro-tests + pressure scenarios pass do I finalize exact wording, commit, and push.

**Bottom line:** the honest deliverable right now is the test plan, not the diff. I'll produce the exact, finalized change after I've watched the current skill fail and confirmed the recipe form actually outperforms the control and the prohibition. If you want, I'll run the RED micro-tests now.