tdd-cat

/tdd-cat — TDD × Subagent Dispatch

/tdd

/cat

The two skills above are the composition: /tdd supplies the one-at-a-time RED→GREEN→refactor micro-cycle; /cat supplies review-gated / fan-out subagent dispatch behind ONE combined pre-dispatch AskUserQuestion. /tdd-cat adds the one thing neither defines: how TDD phases map onto dispatched subagents. That mapping is a user choice, not an inference.

TDD Execution Mode — the Third Axis

Ask this as a third question in the SAME single combined AskUserQuestion that /cat already raises (execution mode × edit approval × TDD execution mode) — not as a separate sequential prompt. Wait for all three answers before any dispatch.

Mode	Each dispatched subagent does…	Use when…
A — Split-phase	exactly one TDD phase (RED or GREEN or REFACTOR); the main agent sequences the phases	you want per-phase review gates, max isolation, phase-level auditability
B — Micro-cycle	the full /tdd loop (RED→GREEN→refactor, repeat) for its slice; returns with slice green	dispatch overhead matters; slices are cohesive; discipline lives in the agent

Under Mode A, the RED subagent writes ONE failing test and reports the failure; the GREEN subagent writes the minimal code for that one test; the REFACTOR subagent cleans while green. The main agent runs the loop N times — one behavior per cycle — dispatching fresh subagents each phase.

Under Mode B, each subagent invokes /tdd internally and owns every RED/GREEN/REFACTOR step for its assigned slice, returning only when the slice's suite is green. /cat's two-stage spec-then-quality review still gates between tasks.

Orthogonality

The A/B axis is orthogonal to both of /cat's axes: it sets the phase granularity of dispatch within a task, not how tasks sequence (execution mode) or who clears edits (edit approval). One hard constraint holds in every combination: within a behavior, RED must precede GREEN — phases of the same behavior never parallelize. When /cat's execution mode allows parallelism, it is across independent behaviors/tasks only.

No Shortcut — Never Default the TDD Mode Silently

The skills' silence on phase↔subagent mapping is exactly what agents fill with a unilateral pick (observed baseline: "I decided it myself", justified by "minimal dispatch overhead"). The mapping is the user's call. Surface the third axis every time; never infer it from the task shape, the deadline, or the user's other answers.

Rationalization counter:

Excuse	Reality
"The task is too small for the question to matter"	Small tasks are where silent defaults calcify. The question costs one option-click in the SAME call you're already making. Ask.
"There's a deadline — asking wastes a turn"	The axis rides the combined question; it adds zero extra turns. Time pressure is the classic trigger for the silent pick — hence this guard.
"The modes converge on this task anyway"	If they truly converge, the user picks in one second. Convergence is YOUR prediction; the choice is theirs.
"The user's execution-mode pick implies a TDD mode"	The axes are orthogonal. Strict sequential composes with A and B; so does parallel. No answer on axes 1–2 answers axis 3.
"B is fewer dispatches, so B"	Fewer dispatches is a reason to offer B, not to impose it. A's per-phase review gates are the point for high-stakes work — the user knows which work this is.

Red flag — STOP: if you catch yourself writing "I'll run the micro-cycle inside one implementer subagent since that's obviously right here" (or the split-phase equivalent) without having asked, you are defaulting the third axis. Ask the combined question.