This skill should be used when implementing features using Acceptance Test Driven Development. It guides through the RED/GREEN/REFACTOR cycle with explicit permission gates between phases.
16 stars
0 votes
1 copy
8 views
Added May 27, 2026
data-aigoshellbashrefactoringgit
Works with
claude code
cli
Security analysis
B75/100
criticalSends environment variables or credentials to an external URL
Installs into .claude/skills of the current project.
Are you the author of Atdd Developer?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/jikig-ai-atdd-developer)
---
name: atdd-developer
description: "This skill should be used when implementing features using Acceptance Test Driven Development. It guides through the RED/GREEN/REFACTOR cycle with explicit permission gates between phases."
---
<!-- soleur-cloud-mode:start -->
**Cloud Mode (Devin):** before pipeline work run `bash "${CLAUDE_PLUGIN_ROOT}/scripts/cloud-detect.sh"`. If `CLAUDE_PLUGIN_ROOT` is unset (cloud exec shells do not export it), resolve the root by IDENTITY, never by script basename: for `d` in `"$HOME/.local/share/devin/cli/plugins/cache"` and `/opt/.devin/plugins`, skip unless `[ -d "$d" ]`, then `MANIFEST="$(find "$d" -path '*/.claude-plugin/plugin.json' -exec grep -l '"name"[[:space:]]*:[[:space:]]*"soleur"' {} + 2>/dev/null | head -1)"`, `ROOT="${MANIFEST%/.claude-plugin/plugin.json}"` — one resolution, two consumers: `$ROOT/scripts/cloud-detect.sh` and `$ROOT/scripts/precommit-guard.sh`. (Shape check, not authentication: a planted `{"name":"soleur"}` dir passes — ADR-179 A11.) `local` or `not-local:no-devin-env` proceeds normally; any other `not-local:<reason>` applies `<plugin-root>/devin/INSTRUCTIONS.md` §Cloud Mode: emit the `--banner`, fan out sequentially with `Reviewed-Coverage: sequential-fallback` disclosure (never claim an independent review ran), `message_user` ack before any secrets read or production mutation, and run `precommit-guard.sh` before any `git commit` — hooks do not fire in cloud.
<!-- soleur-cloud-mode:end -->
<!-- grok-harness-invoke:start -->
**Grok Build (`plugins/soleur/lib/harness.ts` `invokeSkill()`):** Read this SKILL.md in this process and run it to completion. A one-segment `soleur:<name>` in this document names a SKILL — on Grok Build, Read `plugins/soleur/skills/<name>/SKILL.md` in this process; it is not a nested tool_use. A multi-segment id such as `soleur:<domain>:<name>` names an AGENT: spawn it, never Read it, and on Grok Build spawn_subagent takes the id with its colons replaced by hyphens (`agentIdToGrokSubagentType`). **Claude Code:** Skill tool for a skill (`soleur:<name>`), Task tool with `subagent_type` for an agent. Forbidden is executing a subset, not the Read.
<!-- grok-harness-invoke:end -->
# ATDD 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
1. Read the user story or feature requirements
2. Write acceptance tests in Given/When/Then format
3. Run the tests -- confirm they fail
4. **STOP and ask permission to proceed to GREEN**
Do not write any implementation code during this phase.
### GREEN Phase: Minimal Implementation
1. Write the minimum code to make the acceptance tests pass
2. Run the tests -- confirm they pass
3. Do not refactor, optimize, or add extra code
4. **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
1. Apply refactoring techniques while keeping all tests green
2. Use soleur:engineering:review:code-simplicity-reviewer or soleur:engineering:review:code-quality-analyst via Task tool for guidance if needed
3. Run the full test suite after each refactoring step
4. **STOP and ask permission to proceed to COMMIT**
If any test fails during refactoring, undo the last change immediately.
### COMMIT Phase: Record the Change
1. Create a commit with a meaningful message referencing the user story
2. Use conventional commit format (e.g., `feat(scope): implement user story`)
3. **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