Skip to content
Back to skills

Atdd Developer

BSecurity

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

Pro shows the line behind each finding and how to fix it

Scanned September 24, 2026

npx -y skills add jikig-ai/soleur --skill atdd-developer --agent claude-code

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.

Security grade badge for Atdd Developer
[![Security: B — Skills Directory](https://www.skillsdirectory.com/api/skills/jikig-ai-atdd-developer/badge)](https://www.skillsdirectory.com/skills/jikig-ai-atdd-developer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.