atdd

Start the ATDD workflow for a new feature. Optionally provide a feature description as an argument.

Analyze surviving mutants from a mutation testing run and write targeted unit tests to kill them. Re-runs mutations to confirm kills.

Run mutation testing to verify test quality. Builds a custom mutation tool or uses an existing framework, runs mutations, and reports the mutation score with surviving mutants.

Audit GWT acceptance test specs for implementation leakage. Optionally provide a specific file path.

Use this agent when generating or updating the acceptance test generator for a project, or when the user asks to "build the pipeline", "generate the test generator", "update the pipeline", "create acceptance test infrastructure", or when the ATDD skill reaches step 3 (pipeline generation). Examples: <example> Context: A spec.md exists and its IR has been produced user: "I've written my acceptance specs, now I need them runnable" assistant: "I'll use the pipeline-builder agent to generate a project-specific test generator that turns the spec IR into runnable acceptance tests." <commentary> spec.md + .build/spec.json exist; pipeline-builder generates the generator + step handlers + runner. </commentary> </example> <example> Context: New step vocabulary the generated tests don't handle user: "I added new Given steps about user roles but the generated tests don't know them" assistant: "I'll use the pipeline-builder agent to extend the step handlers." <commentary> Step handlers need new bindings — pipeline-builder updates them. </commentary> </example> <example> Context: ATDD workflow step 3 — specs approved and parsed user: "Specs are approved, let's generate the pipeline" assistant: "I'll invoke the pipeline-builder to generate the test generator." </example>

Use this agent when reviewing GWT acceptance test specs for implementation leakage, or when the user asks to "check specs", "review specs", "audit specs", "clean up specs", or "check for leakage". Also invoked by the /spec-check command and as part of the ATDD workflow. Examples: <example> Context: User has written acceptance test specs and wants to verify quality user: "Check my specs for implementation leakage" assistant: "I'll use the spec-guardian agent to review your GWT specs for any implementation details that shouldn't be there." <commentary> Direct request to review specs for leakage — core use case for spec-guardian. </commentary> </example> <example> Context: ATDD workflow step 6 — implementation is complete, reviewing specs user: "Implementation is done, all tests pass" assistant: "Great! Before we wrap up, let me run the spec-guardian to make sure no implementation details crept into the specs during development." <commentary> Proactive invocation as part of the ATDD workflow after implementation. </commentary> </example> <example> Context: User just wrote new spec files user: "I've added specs for the payment feature" assistant: "Let me have the spec-guardian review those specs to ensure they use domain language and describe only external observables." <commentary> New specs should be reviewed for quality before proceeding to pipeline generation. </commentary> </example>

Use to add a third validation layer to the ATDD workflow — after acceptance tests verify WHAT and unit tests verify HOW, mutation testing verifies the tests actually catch bugs. Triggers — "/mutate", "/kill-mutants", "run mutation testing", "mutate my code", "kill mutants", "check test quality", "find surviving mutants", "run stryker", "run mutmut", "run pitest", "are my tests catching bugs".

Use to orchestrate a team-based ATDD workflow — six phases (spec writing, spec review, pipeline generation, implementation, refine, verify & harden) each handled by a fresh agent so no role erodes across a long-running feature. Triggers — "build a feature with a team", "use ATDD with agents", "create an ATDD team", "orchestrate agents for ATDD", "coordinate agents for feature development", "add ATDD roles to my team", "add spec-writer and reviewer to the team".

Use to drive feature work through the Acceptance Test Driven Development workflow — Given/When/Then specs before code, a project-specific test pipeline, and two parallel test streams (acceptance + unit). Triggers — "/atdd", "build a feature", "implement a feature", "add functionality", "start development", "write acceptance tests", "write specs", "use ATDD", "use TDD with acceptance tests".

2 hooks across 2 events