By swingerman
Enforces Acceptance Test Driven Development: write Given/When/Then specs first, then generate a project-specific test pipeline with parallel acceptance and unit test streams, plus optional mutation testing to validate test quality.
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".
Modifies files
Hook triggers on file write and edit operations
Uses power tools
Uses Bash, Write, or Edit tools
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Spec-driven, test-driven, charter-bound AI coding for Claude Code. ATDD + mutation testing + deterministic guardrails. Three plugins: engineer, atdd, crap-analyzer.
ℹ️ Repo renamed: this marketplace was previously
swingerman/atdd. Existingswingerman/atddURLs continue to work via GitHub's automatic redirect — no action needed unless you want to update local remotes (git remote set-url origin https://github.com/swingerman/disciplined-agentic-engineering.git).
A Claude Code marketplace hosting the Disciplined Agentic Engineering (DAE) methodology kit — skills, agents, hooks, slash commands, and deterministic guardrail tools that keep software engineers in charge of architecture, behavior decisions, and verification while AI agents do the typing. Built around Acceptance Test Driven Development (ATDD), mutation testing, and the iterative, layered specification pattern of GitHub's Speckit.
DAE is a methodology for engineering-led AI development. AI agents do the coding; software engineers stay in charge of architecture, performance, and feature validation. Discipline lives in the contracts at every layer (charter → ACs → specs → plans → verification) and in deterministic guardrail tools that gate every checkpoint — not in prompt rules that erode over long agent runs.
It's positioned in direct opposition to vibe coding — the loose-prompt, weak-check style of agentic development where AI produces code with no charter, no behavior contract, and no verification gates. DAE makes the boundaries explicit and the checks continuous.
The headline outcome: semantic stability. ATDD + mutation testing together form a semantic firewall — code can be refactored, extended, or modified by agents without the system's intended behavior drifting. This is the moat between DAE-built systems and "AI plops code around."
DAE is for software engineers — people who already know what acceptance tests are, why mutation testing matters, why architectural layering matters, why naming matters, why the difference between a behavior contract and an implementation detail matters. The methodology assumes you can read a plan.md and tell whether the proposed architecture is sound; that you can read a Gherkin spec and tell whether the behavior contract captures intent; that you know when a charter rule should be enforced vs. amended.
It is not for non-programmers. "Build an app without code" tools target a different audience and a different problem. DAE keeps the engineer in charge precisely because the decisions DAE puts in front of you — architecture, behavior contracts, charter rules, verification thresholds, autonomy levels — are engineering decisions, and they need engineering judgment.
If you are a software engineer who wants AI's speed without losing the system's coherence, DAE is built for you.
Vibe coding is the rising practice of prompting an AI agent loosely — "build me a thing that does X" — accepting whatever comes back, running it, patching when something feels off. No charter to obey, no behavior contract to satisfy, no verification gates to pass. Fast at first; brittle over time. The codebase drifts; tests pass without proving anything; regressions surface as users find them.
DAE is the deliberate opposite. Every feature has a charter to obey, a Ready contract for what's being built, ACs in domain language, a Gherkin spec the human can read and defend, an architecture plan the human approves before code is written, two test streams that must both go green, mutation testing that proves the tests catch bugs, and deterministic guardrail tools that gate every transition. The human stays the engineer; the agent stays the typist.
Analyze recently-changed code for Change Risk Anti-Patterns. Computes CRAP per changed function across TypeScript, JavaScript, Python, Java, Kotlin, Go, Ruby, C#, Rust, and PHP. Auto-discovers how the repo generates coverage and proposes refactors + test stubs.
npx claudepluginhub swingerman/disciplined-agentic-engineering --plugin crap-analyzerAAID (Augmented AI Development) - BDD/ATDD workflow using the Three-Layer Model for acceptance testing with developer-maintained architectural control
Agent Driven Development (ADD) — Coordinated AI agent teams that ship verified software. Spec-driven TDD, trust-but-verify orchestration, human-AI collaboration protocols, environment-aware deployment, and cross-project learning.
SPEC-First development workflow with TDD, Ralph Loop, and autonomous agent coordination for Claude Code
Spec-driven development pipeline for Claude Code: interview-to-spec, spec-approach, tdd, verify, diagnose, and a feature orchestrator.
Comprehensive Behavior-Driven Development principles, practices, and collaboration patterns.
Verified Coherence Spec-Driven Development — adversarial quality gates for AI-assisted development