# Test Plan: Dispatch-Contents Addition to SDD Skill

## Step 0: Classify the failure type (do this first)

The Iron Law applies to edits too — no skill change without a failing test first. But before designing tests, I classify what failure this guidance addresses, because the form determines how I test it.

This addition is a **positive recipe** ("your dispatch should contain: (1)...(5)..."). Recipes target **wrong-shaped-output** failures, not discipline failures. So:

- I am NOT testing "does the agent comply under pressure" (that's discipline).
- I AM testing "does the dispatch the agent produces have the right shape" — all five parts, in order, correctly framed.

This matters because if the real baseline failure is a *discipline* failure (agent knows to include the brief but skips it under time pressure), a recipe is the wrong form and the test would pass for the wrong reasons. So my first test must confirm the failure is a shaping failure.

## Step 1: RED — establish a no-guidance baseline

**Iron Law:** I cannot validate this addition unless I first watch agents fail without it. If the no-guidance control already produces well-shaped dispatches, there is nothing to fix — stop and don't deploy.

**Method:** micro-tests (one API call per sample), because I am verifying output *shape*, which is fast to elicit and cheap to iterate on. Pressure scenarios are not needed — this isn't a discipline rule.

**Control setup:**
- **System prompt:** the full SDD skill *as it exists today*, minus the proposed addition. (Realistic context — the guidance must be tested inside the skill it lives in, not in isolation.)
- **User message:** a task that requires dispatching a subagent to implement a sub-task that has a brief, depends on an earlier task's interface, and contains a genuine ambiguity. Make the task tempt the failure: e.g., a tight-sounding deliverable that invites the agent to write a long self-contained prompt that restates requirements instead of pointing at the brief.
- **Reps:** 5+.

**What I record (verbatim):** for each of the five required parts, present/absent. Plus the dominant failure shape — most likely candidates:
- Restates requirements inline instead of pointing at the brief ("self-contained prompt" instinct).
- Omits cross-task interfaces.
- Omits report-file path.
- Buries or omits the ambiguity resolution.

**Decision gate:** If ≥4/5 control reps already produce all five parts correctly framed → **no failure exists, do not deploy the addition.** If most reps drop parts or restate the brief → failure confirmed, proceed.

## Step 2: GREEN — test the proposed wording

**Variants (same system prompt structure, swap the dispatch guidance):**

| Variant | Guidance |
|---|---|
| A | No guidance (control, from Step 1) |
| B | The teammate's draft, verbatim |

**Reps:** 5+ per variant, same task as control.

**Scoring (read every output manually — do not trust automated string-matching):**

Per dispatch, score each part 0/1:
1. One line on where the task fits
2. Brief path, framed as "read this first — it is your requirements" (or equivalent binding framing)
3. Interfaces the brief cannot know
4. Resolution of any ambiguity (only scorable if the task contained one — it does)
5. Report-file path

Manual reading catches the traps automated counts miss: a dispatch that *names* the brief but then restates all its contents anyway (part 2 technically present but the failure unfixed); template echoes; an agent quoting the instruction rather than acting on it.

**Also record two shape metrics:**
- **Brief-restatement:** does the dispatch reproduce requirement content that lives in the brief? (The recipe should *reduce* this — pointing replaces restating. If part 2 is present but restatement persists, the recipe isn't binding.)
- **Variance across reps:** when a recipe lands, reps converge on the same five-part shape. Five different interpretations = wording not binding → tighten before deploying.

## Step 3: REFACTOR — if B underperforms

Likely failure mode of the draft: it lists five parts but doesn't forbid the competing instinct (self-contained prompt). An agent under "make it self-contained" pressure may include the brief path *and* restate it. Note: I would NOT fix this with a prohibition ("don't restate the brief") — for a shaping failure, prohibitions backfire. Instead I'd strengthen the recipe's framing so restating has no slot (e.g., make part 2's framing explicit that the brief *is* the requirements, so inline requirements are redundant by construction), and consider making the five parts a REQUIRED structural template the agent fills in rather than prose.

Re-test the revised wording against control + draft, 5+ reps, until convergence.

## Acceptance Criteria

Deploy only if ALL hold:
1. **Failure confirmed (RED):** control drops ≥1 required part or restates the brief in ≥3/5 reps.
2. **Recipe fixes it (GREEN):** chosen variant produces all five correctly-framed parts in ≥5/5 reps (shaping recipes should converge fully, not partially — this isn't a probabilistic discipline rule).
3. **Restatement reduced:** brief-restatement strictly lower in the chosen variant than control.
4. **Low variance:** the five reps converge on the same dispatch shape.
5. **Beats the control head-to-head:** if any variant scores no better than no-guidance, do not ship it — extra words that don't change behavior are pure cost.

If criterion 1 fails, abandon the addition (no problem to solve). If 2–4 fail, refactor wording and re-run. No deployment of untested wording, and no keeping the draft "as reference."