# Test Plan: Subagent Dispatch Content Addition (SDD Skill)

## The Iron Law Applies

This is an EDIT to an existing skill. **No skill change without a failing test first.** I will NOT deploy this change until I have (a) watched the baseline fail and (b) watched the change make it pass. If I can't show a baseline failure, the addition isn't justified and shouldn't ship.

## What This Skill Type Is

This is a **technique skill** (how-to: how to construct a dispatch message). So testing = "can a fresh agent apply this correctly to a new scenario, and does it close gaps that exist without it?" Not a discipline/pressure skill — but I'll watch for one discipline-adjacent failure mode (agents over-including or substituting the dispatch for the brief).

## What Claim Am I Actually Testing?

The addition implicitly claims: **without these 5 elements specified, dispatching agents produce dispatches that cause subagent failures.** I need to verify each element earns its place. Five separate sub-claims:

1. Agents omit "where this fits" context
2. Agents fail to point at the brief as authoritative requirements
3. Agents fail to pass forward interfaces from prior tasks
4. Agents leave ambiguity unresolved (push it to subagent)
5. Agents forget the report-file path

---

## RED Phase — Baseline (run BEFORE the edit exists)

**Method:** Dispatch fresh subagents (no skill memory) playing "lead agent executing an SDD plan." Give each a realistic multi-task plan with: a written brief file, 2 already-completed tasks that produced interfaces, one genuine ambiguity in the spec, and a required report location. Ask them to write the dispatch message they'd send to a subagent for Task 3.

**Sample size:** 8 baseline runs. Rationale: I'm scoring presence/absence of 5 discrete elements. With 8 runs I can see per-element omission rates (e.g., "6/8 forgot interfaces") rather than a single pass/fail. Fewer than ~6 and I can't distinguish "real gap" from noise.

**Controls / variation:**
- Vary the scenario across 3 domains (a backend API task, a refactor task, a docs task) so I'm not fixing a quirk of one example.
- Vary brief quality: half with a clearly-named brief file, half where the brief is just "the plan" — tests whether element (2)'s "read this first, it is your requirements" framing actually changes behavior.

**Scoring (per run, per element):** binary present/absent, plus a verbatim capture of what they DID do instead. The verbatim record is the point — it tells me which elements have real failure modes and surfaces rationalizations ("the subagent can find the brief itself").

**Decision gate:** For each of the 5 elements, compute baseline omission rate. **Any element omitted in ≤2/8 baselines is a candidate for cutting** — agents already do it naturally, so documenting it adds tokens without changing behavior. Only elements with meaningful baseline failure (≥3/8) justify inclusion.

---

## GREEN Phase — With the Change

**Method:** Same scenarios, fresh subagents, with the edited skill present. Same dispatch-authoring task.

**Sample size:** 8 runs, matched to the same 3 domains + brief-quality split.

**Scoring:** Same 5-element rubric, plus two new checks the addition could break:
- **Substitution failure:** Did the dispatch try to *restate* requirements instead of pointing to the brief? (The phrase "it is your requirements" should prevent inlining the brief — verify it doesn't instead cause agents to skip the brief content entirely OR duplicate it.)
- **Over-inclusion:** Did agents pad elements (1) and (4) into bloated dispatches when the scenario had no real ambiguity? Element (4) "your resolution of any ambiguity" must degrade gracefully to "none" when there's nothing to resolve.

**Acceptance criteria:**
| Check | Threshold |
|---|---|
| Each element with baseline failure ≥3/8 | now present in ≥7/8 runs |
| Brief pointed to as authoritative (not inlined/duplicated) | ≥7/8 |
| Ambiguity correctly handled (resolved when present, "none" when absent) | ≥7/8 across both ambiguity/no-ambiguity scenarios |
| No new over-inclusion bloat | no run substantially worse than baseline on conciseness |

If an element passes baseline AND green but I cut it (low baseline failure), I re-run green without it to confirm omission rate stays low — proving the line was dead weight.

---

## REFACTOR Phase

Capture any NEW failure introduced (e.g., agents now write 5 labeled headings mechanically even when an element is empty, or treat the 5-item list as exhaustive and drop something the brief needed). For each, add a counter or example to the skill, then re-run the relevant scenarios until clean. Specifically I expect to need: an explicit "omit empty elements, don't write 'Interfaces: N/A' boilerplate" note.

## Deployment Gate

Ship only when: every retained element has demonstrated baseline failure + green pass, the substitution and over-inclusion checks pass, and any cut elements are confirmed unnecessary. Then commit.

**One caveat I'd flag to the teammate:** if baseline testing shows agents already nail element (2) or (5) reliably, those lines should be cut — frequently-loaded skill text costs tokens in every dispatch, and we only document judgment calls agents actually get wrong.