Facilitates the ATDD cycle from requirements analysis through to spec implementation and verification.
Install
mkdir -p .claude/skills/atdd && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/10768" && unzip -o skill.zip -d .claude/skills/atdd && rm skill.zipInstalls to .claude/skills/atdd
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Spec-Driven ATDD workflow skill. Use for running the full ATDD cycle, writing Gherkin feature files, creating technical specs, generating acceptance tests, or reviewing spec compliance. Trigger phrases: ATDD, BDD, Gherkin, spec-first, acceptance test, feature file, Given When Then, red-green-refactor, spec coverage, write scenarios.Key capabilities
- →Write Gherkin feature files
- →Generate test stubs
- →Run quality gates
- →Verify spec compliance
How it works
It manages the full ATDD cycle by enforcing a spec-first approach, generating test stubs, and running quality gates to ensure implementation matches the spec.
Inputs & outputs
When to use atdd
- →Convert requirements to Gherkin
- →Write acceptance tests
- →Verify spec compliance
About this skill
ATDD — Acceptance Test-Driven Development
When to Use
- Starting a new feature (write specs before any code)
- Converting requirements to Gherkin scenarios
- Generating acceptance test stubs from a spec
- Implementing code to pass failing tests
- Verifying spec compliance after implementation
- Running the full automated ATDD cycle end-to-end
Workflow
Analyze → Spec → Tests (Red) → Implementation (Green) → Quality Gates → Refactor → Spec & Doc Sync → PR
Quick Commands
| Command | Purpose |
|---|---|
/analyze-project | Detect language, frameworks, tools, AND code conventions; write project profile |
/write-spec | Generate Gherkin + technical spec from requirements |
/write-acceptance-tests | Generate failing test stubs from a spec file |
/implement-from-spec | Implement code to make failing tests pass (re-reads project profile first) |
/run-quality-gates | Run lint, format, typecheck, build, test — iterate until green |
/refactor-passing-tests | Safe refactor after all tests are green |
/verify-spec-coverage | Hard spec & doc sync gate — repairs spec/README/profile drift in-place |
/create-pull-request | Create branch, commit, push, open PR |
/address-review-comments | Handle PR review feedback, update spec if needed |
@atdd-cycle | Full automated cycle (analyze → spec → tests → implement → gates → sync → PR) |
@spec-writer | Dedicated spec writing agent |
@spec-reviewer | Dedicated spec & doc compliance review agent |
Templates & References
- Gherkin feature template
- Technical spec template
- ATDD cycle checklist
- Gherkin guide
- ATDD patterns
- Quality gates
- Project detection
- Legacy integration
Core Principles
- Spec is the source of truth — change spec first, then tests, then code
- Red before green — never implement without a confirmed-failing test
- Minimum viable implementation — only write code that a failing test demands
- Behavior, not implementation — specs describe observable outcomes, not internal mechanics
- Mirror the codebase — Phase 3 re-reads
docs/project-profile.mdand follows the conventions already in use - Sync or stop — Phase 6 (Spec & Doc Sync) is a hard gate; the cycle is not done while the spec, README, or project profile drift from what the code does
Profile Bootstrap (First Action)
If docs/project-profile.md does not exist, your first action is /analyze-project — even
for ad-hoc requests. Tell the user: "No project profile found — running Phase 0 first so I
have an accurate picture of this codebase's tooling and conventions."
Cycle — Pointer
Analyze → Spec → Tests (Red) → Implement (Green) → Quality Gates → Refactor → Spec & Doc Sync → PR
Full procedure: docs/atdd/workflow.md (authoritative).
Per-phase prompt mapping:
| Phase | Trigger | Key output / gate |
|---|---|---|
| 0 | /analyze-project | docs/project-profile.md with Tooling, Conventions, Sources consulted |
| 1 | /write-spec / @spec-writer | specs/features/*.feature + specs/technical/*-spec.md — USER GATE |
| 2 | /write-acceptance-tests | All scenarios have failing stubs; "all red ✓" reported |
| 3 | /implement-from-spec | Minimum code, mirror profile, @smoke first |
| 4 | /run-quality-gates | lint / format / typecheck / build / test all pass |
| 5 | /refactor-passing-tests | Structure only, tests stay green |
| 6 | /verify-spec-coverage / @spec-reviewer | No spec/README/profile drift (hard gate) |
| 7 | /create-pull-request | Branch, commit, push, PR |
Spec Directory Layout
specs/
├── features/ # Gherkin .feature files
│ └── *.feature
└── technical/ # Markdown technical specs
└── *-spec.md
When not to use it
- →When the project does not follow ATDD
- →When the task is not spec-driven
Prerequisites
Limitations
- →Requires project profile bootstrap
- →Spec-doc drift prevents cycle completion
How it compares
It enforces a strict red-green-refactor cycle and requires spec-doc synchronization as a hard gate.
Compared to similar skills
atdd side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| atdd (this skill) | 0 | 1mo | No flags | Advanced |
| code-review-checklist | 3 | 24d | No flags | Beginner |
| openspec-verify-change | 3 | 6mo | Review | Advanced |
| superpowers-finish | 1 | 6mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
code-review-checklist
vudovn
Code review guidelines covering code quality, security, and best practices.
openspec-verify-change
studyzy
验证实现是否与变更产出物匹配。当用户想要在归档前验证实现是否完整、正确且一致时使用。
superpowers-finish
anthonylee991
Finalizes work: runs verification, summarizes changes, notes follow-ups, and ensures repo hygiene. Use at the end of an implementation or debugging session.
positron-qa-verify
posit-dev
Generates clear, actionable verification guides for QA testing of Positron bug fixes and features
categorize-revdep-issues
r-lib
Write revdep/issue.md to group packages by common error categories
pr-review
microsoft
Multi-dimensional review of a PR or feature branch in the microsoft/winappcli repo. Activate when a contributor asks to "review my PR", "review my changes", "vet my branch before pushing", "do a full review", "PR review", "review this feature", or similar. Fans out parallel sub-agents covering secur