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 pipeline for a project, or when the user asks to "build the pipeline", "generate the parser", "generate the test generator", "update the pipeline", "create acceptance test infrastructure", or when the ATDD skill reaches step 3 (pipeline generation). Examples: <example> Context: User has written GWT specs and needs the pipeline to run them user: "I've written my acceptance test specs, now I need the pipeline to run them" assistant: "I'll use the pipeline-builder agent to analyze your project and generate a parser, IR format, and test generator tailored to your codebase." <commentary> Specs exist but no pipeline yet — pipeline-builder generates the full 3-stage pipeline. </commentary> </example> <example> Context: User added new GWT directives that the existing pipeline doesn't support user: "I added new GIVEN directives for user roles but the parser doesn't understand them" assistant: "I'll use the pipeline-builder agent to update the parser and generator to support the new directives." <commentary> Existing pipeline needs updating to support new spec vocabulary — pipeline-builder extends it. </commentary> </example> <example> Context: ATDD workflow step 3 — specs are written and approved user: "Specs are approved, let's generate the pipeline" assistant: "I'll invoke the pipeline-builder to create the test pipeline for your project." <commentary> Part of the ATDD workflow — automatically invoked after spec approval. </commentary> </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>

This skill should be used when the user asks to "run mutation testing", "mutate my code", "kill mutants", "check test quality", "find surviving mutants", "verify test effectiveness with mutations", "run stryker", "run mutmut", "run pitest", "set up mutation testing", "how good are my tests", "are my tests catching bugs", or mentions mutation testing, mutation score, or mutant survival in the context of testing. It adds a third validation layer to the ATDD workflow: after acceptance tests verify WHAT and unit tests verify HOW, mutation testing verifies that tests actually catch bugs.

This skill should be used when the user asks to "build a feature with a team", "use ATDD with agents", "create an ATDD team", "set up a team for ATDD", "orchestrate agents for ATDD", "use team-based development", "coordinate agents for feature development", "run the ATDD workflow with teammates", "add ATDD to my team", "extend my team with ATDD", "join the team with ATDD agents", "add spec-writer and reviewer to the team", or "add ATDD roles to the existing team". It orchestrates a three-agent team (spec-writer, implementer, reviewer) through a five-phase ATDD workflow: spec writing, spec review, pipeline generation, implementation, and post-implementation review. Supports extending an existing team with ATDD roles without replacing current teammates.

This skill should be used when the user asks to "build a feature", "implement a feature", "add functionality", "start development", "write acceptance tests", "write specs", "use ATDD", "use TDD with acceptance tests", or begins any feature implementation work. Also triggered by the /atdd command. Enforces the Acceptance Test Driven Development workflow: write Given/When/Then specs before code, generate a project-specific test pipeline, and maintain two test streams.

2 hooks across 2 events