Help us improve
Share bugs, ideas, or general feedback.
From feature-lifecycle
Implements features using TDD red-green-refactor cycle. Use when the user wants to use TDD, write tests first, do test-driven development, red-green-refactor, or build a feature with tests.
npx claudepluginhub gravity9-tech/claude_code_marketplace_demo --plugin feature-lifecycleHow this skill is triggered — by the user, by Claude, or both
Slash command
/feature-lifecycle:tdd-workflowThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Guide feature implementation through strict red-green-refactor cycles, writing a failing test first, making it pass with minimal code, then refactoring.
Enforces strict TDD workflow for feature implementation: write one failing test, minimal code to pass, refactor, repeat. Prevents writing full test suites upfront.
Enforces a red-green-refactor TDD cycle with automated test runs. Use when implementing, fixing, or refactoring behavior in codebases that already have tests.
Red-Green-Refactor cycle for test-first development. Write failing test, implement minimal code, refactor safely. Use when developing new features or fixing bugs in test-driven projects.
Share bugs, ideas, or general feedback.
Guide feature implementation through strict red-green-refactor cycles, writing a failing test first, making it pass with minimal code, then refactoring.
When the user describes a feature or behavior to implement, follow the TDD cycle below. Repeat the cycle for each discrete behavior until the feature is complete.
Before starting, identify the project's test setup:
**/*.test.*, **/*.spec.*, **/test_*.pyjest.config.*, vitest.config.*, pytest.ini, playwright.config.*package.json, CLAUDE.md, or MakefileAnnounce to the user: the framework detected, the test command you'll use, and which file you'll add tests to (or create).
Write one test that describes the next behavior to implement.
Test writing rules:
test_returns_empty_list_when_no_products_match not test_filter)Run the test using Bash to confirm it fails. Verify the failure is for the right reason:
If the test fails for the wrong reason, fix the test and re-run before proceeding.
Tell the user: RED: Test fails — [reason]
Write the minimum production code needed to make the failing test pass.
Green phase rules:
Run the test to confirm it passes.
If it fails, fix the production code (not the test) and re-run. The test from the RED phase defines the contract — the code must meet it.
Tell the user: GREEN: Test passes
Now improve the code you just wrote (and any related code) without changing behavior.
Refactor targets:
Refactor rules:
Tell the user: REFACTOR: [what you improved] or REFACTOR: No changes needed — code is clean
After completing one cycle, assess progress:
When the user describes a feature with multiple aspects, decompose it into a sequence of behaviors to implement one at a time. List them before starting:
Feature: [name]
Behaviors to implement:
1. [First behavior — simplest/foundational]
2. [Second behavior — builds on first]
3. [Third behavior — edge case or variation]
Start with the simplest or most foundational behavior. Each cycle builds on the last.
For each cycle, clearly label the phase:
── Cycle 1: [behavior being implemented] ──
RED: Writing test...
[show test code]
Running: [test command]
Result: FAIL — [failure reason] (expected)
GREEN: Writing implementation...
[show production code]
Running: [test command]
Result: PASS
REFACTOR: [what was improved, or "no changes needed"]
Running: [test command]
Result: PASS
After all cycles:
── Summary ──
Feature: [name]
Cycles: [N]
Tests written: [N]
Files modified: [list]
All tests passing: yes/no