atdd-developer
npx machina-cli add skill jikig-ai/soleur/atdd-developer --openclawATDD Developer
Guide feature implementation through the Acceptance Test Driven Development cycle. Each phase requires explicit user approval before proceeding.
When to Use
- Implementing a new feature with acceptance criteria
- Practicing test-driven development on user stories
- Teaching or reinforcing TDD discipline
The Cycle
RED Phase: Write Failing Acceptance Tests
- Read the user story or feature requirements
- Write acceptance tests in Given/When/Then format
- Run the tests -- confirm they fail
- STOP and ask permission to proceed to GREEN
Do not write any implementation code during this phase.
GREEN Phase: Minimal Implementation
- Write the minimum code to make the acceptance tests pass
- Run the tests -- confirm they pass
- Do not refactor, optimize, or add extra code
- STOP and ask permission to proceed to REFACTOR
The goal is passing tests, not beautiful code. Resist the urge to clean up.
REFACTOR Phase: Improve the Code
- Apply refactoring techniques while keeping all tests green
- Use code-simplicity-reviewer or code-quality-analyst via Task tool for guidance if needed
- Run the full test suite after each refactoring step
- STOP and ask permission to proceed to COMMIT
If any test fails during refactoring, undo the last change immediately.
COMMIT Phase: Record the Change
- Create a commit with a meaningful message referencing the user story
- Use conventional commit format (e.g.,
feat(scope): implement user story) - Ask if there are more stories to implement
Key Principles
- Never skip phases or combine them
- Always ask permission before transitioning between phases
- The RED phase defines the contract; the GREEN phase fulfills it
- Refactoring is only safe when tests are green
- Small cycles are better than large ones
Source
git clone https://github.com/jikig-ai/soleur/blob/main/plugins/soleur/skills/atdd-developer/SKILL.mdView on GitHub Overview
Guides feature work using Acceptance Test Driven Development. It enforces explicit permission gates between RED, GREEN, and REFACTOR phases, ensuring tests drive implementation and quality.
How This Skill Works
Start with the RED phase by writing failing acceptance tests in Given/When/Then and stopping for permission. In GREEN, implement the minimal code needed to satisfy the tests, then stop and proceed to REFACTOR. During REFACTOR, improve the code while keeping all tests green, then move to COMMIT.
When to Use It
- Implementing a new feature with acceptance criteria
- Practicing test-driven development on user stories
- Teaching or reinforcing TDD discipline
- Facilitating acceptance-test-first approaches within a team
- Where explicit phase-by-phase discipline is needed to maintain quality
Quick Start
- Step 1: Read the user story, write failing acceptance tests in Given/When/Then, and run tests to confirm they fail.
- Step 2: GREEN Phase — implement the minimal code to make tests pass and run tests again to confirm.
- Step 3: REFACTOR Phase — clean up and improve the code while keeping tests green, then prepare for COMMIT.
Best Practices
- Never skip phases or combine them
- Always ask permission before transitioning between phases
- The RED phase defines the contract; the GREEN phase fulfills it
- Refactoring is only safe when tests are green
- Keep cycles small and focused
Example Use Cases
- Implement a new user registration feature with acceptance tests written in Given/When/Then, followed by a RED/GREEN/REFACTOR cycle.
- Add a multi-step checkout flow and gate progress with explicit phase permissions.
- Refactor a validator or business rule after all acceptance tests remain green.
- Expose a new API endpoint guarded by acceptance tests and drive development through ATDD.
- Run a short ATDD cycle in a team demo to reinforce disciplined TDD practices on a user story.
