tdd

Featured

Write code through a disciplined, BDD-framed Test-Driven Development loop: build a behavior test list, then drive each behavior through red-green-refactor with an enforced observed-failure gate. Use when the user wants to implement, build, or write code test-first, "do TDD", follow "red-green-refactor", drive code from tests, choose the next test by the Transformation Priority Premise (TPP) or ZOMBIES ordering, or grow a feature behavior-by-behavior with tests leading. This skill writes and changes code; it does not produce a test plan document (use automated-test-planning, or manual-test-planning for a plan a person runs by hand), review or audit existing code (use code-review), restructure existing code outside a TDD loop (use refactor, or plan-a-change to plan a multi-module restructure), specify what a feature should do (use plan-a-feature), or find the root cause of a bug (use investigate). Runs its loop to completion without pausing for review; to review each behavior as it lands, use pairing.

Code & Development 273 stars 23 forks Updated 2 days ago MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
81
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

## Project Context - git installed: !`which git 2>/dev/null || echo "not installed"` - current branch: !`git branch --show-current 2>/dev/null || echo unknown` - CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f` - project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f` - personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"` - project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""` As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md` probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used. ## Constraints (read before anything else) This skill writes production and test code in your working tree. It is an execution skill, not a document generator. These constraints shape every step and override any instinct to move faster. - **The observed-failure gate is load-bearing.** No production-code change until a test has been run and observed to fail for the intended reason in this loop. A test that passes on first run is a stop-and-diagnose signal, not progress. This single rule is what separates real TDD from TDD-flavored co...

Details

Author
testdouble
Repository
testdouble/han
Created
4 months ago
Last Updated
2 days ago
Language
Shell
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Featured

refactor

Restructure existing code without changing its behavior, through a test-gated refactoring loop: a named target, a green suite over that target before any edit, a planned sequence of small named refactorings, and the full suite re-run after every step. Use when the user wants to refactor, restructure, clean up, simplify, or improve the design of existing code, or to apply refactoring recommendations from a code-review or architectural-analysis report. This skill changes code; it does not review code (use code-review), assess architecture (use architectural-analysis), plan a multi-module restructure before executing it (use plan-a-change), map domain boundaries before restructuring along them (use ddd-analysis), or build new behavior test-first (use tdd). Do not use it on code inside an active tdd loop; the refactor step of tdd owns that cleanup. Runs its planned sequence to completion without pausing for review; to review each named refactoring as it lands, use pairing.

273 Updated 2 days ago
testdouble
AI & Automation Listed

tdd

Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.

1 Updated today
ypxing
Testing & QA Listed

tdd

Enforces Red-Green-Refactor when implementing new behavior. Claude writes a failing test first, confirms it fails for the right reason, implements the minimum to pass, then refactors. Use when adding new functionality — especially in domain or application layers of a DCA project.

0 Updated today
domain-centric-development