ad-tdg

<background_information> Implements WORKFLOW.md §9 (Outcome-Based Prompting / Test Dependency Map) end-to-end. The skill is for the implementation phase when the canonical technique is known and multiple implementation strategies are plausible. WORKFLOW §14 (ad-spike) covers the technique-unknown regime; §9 (this skill) covers the implementation-strategy-uncertain regime.

No file is written. The output of the skill is the verified implementation that lands in the repo through normal commits. The ground-truth pair, candidate set, selection criterion, and TDM list go into the commit message body — or the task's Notes log when one exists — not into a separate doc/ artifact.

Codex auto-trigger on description keywords is less mature than Claude Code's. If auto-invocation does not fire when the user mentions outcome-based prompting, ground truth, three approaches, or a Test Dependency Map, invoke this skill manually. </background_information>

Route elsewhere when:

• The technique itself is uncertain across multiple plausible approaches → ad-spike (WORKFLOW §14). Spike validates technique with golden fixture + per-stage debug; TDG validates implementation with ground-truth pair + TDM.
• The path is fully obvious (one-line fix, mechanical refactor, byte-for-byte port) → TDG is overkill; proceed directly without the skill.
• No tests cover the surface and the project does not yet have a test runner wired → consider ad-hooks for project gates first; TDG depends on a verifiable green baseline.

Step 1 — ground truth pair. State raw input + exact expected output before any code is written. Concrete, not aspirational. The pair is the contract the implementation must satisfy.

Format depends on the surface:

• For pure functions: input arguments + expected return value, as code-block or JSON.
• For data transformations: source data + transformed data, side-by-side.
• For CLI / API surfaces: request payload + response payload, as paste-ready examples.
• For UI changes: pre-state DOM / screenshot + post-state DOM / screenshot.

Example (pure function):

Input: parse('--agent claude-code --yes')
Expected output: { agent: 'claude-code', yes: true, dryRun: false, force: false }

The pair is small, explicit, and verifiable. Aspirational language ("loads fast", "handles all edge cases") is not ground truth — concrete examples are.

Step 2 — Test Dependency Map (TDM). List the tests covering the file(s) the change will touch. Run them to establish the green baseline. If no tests cover the surface, write one first that exercises the current behavior before any modification.

Process:

1. Grep for tests referencing the file by import path: grep -r 'from.*<file>' test/ tests/.
2. Grep for tests referencing the function or symbol: grep -r '<symbol>' test/ tests/.
3. Run the matched tests in isolation to confirm green: npx node --test test/<matched>.test.js or equivalent for the language.
4. If empty: write a test that asserts the current behavior. Run. Confirm green. Then proceed to Step 3.

The TDM is the verification surface — Step 5's "implement + verify" loop runs these tests, not the full suite, so the feedback loop stays under a few seconds. Full-suite runs happen at commit-time via the project's pre-push hook (ad-hooks).

Step 3 — three approaches. Generate three implementation candidates that produce the ground-truth pair. Each candidate names trade-offs along the §9 axes:

Approach A: <name / one-line description>
  - readability: <high / medium / low + reason>
  - performance: <O(...), bytes allocated, etc.>
  - testability: <surface area, mockability, isolation>

Approach B: <name / one-line description>
  - readability: ...
  - performance: ...
  - testability: ...

Approach C: <name / one-line description>
  - readability: ...
  - performance: ...
  - testability: ...