Stats
Actions
Tags
From idea-to-code
Enforces strict TDD workflow for coding agents: requires test evidence before state changes (RED/GREEN/REFACTOR), minimal code, dependency promotion, outside-in development.
How this skill is triggered — by the user, by Claude, or both
Slash command
/idea-to-code:tddThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill defines a strict but lightweight TDD workflow designed for coding agents.
This skill defines a strict but lightweight TDD workflow designed for coding agents. It enforces honesty, prevents cheating, and minimizes token usage by focusing solely on tests.
(Always enforced in every state)
Never claim tests passed or failed unless you have just run them and shown the exact output.
If you cannot run tests, enter BLOCKED immediately. Do not guess or infer results.
Never modify test assertions just to make a failing test pass.
Only transition between TDD states when the required test evidence has been shown.
In RED, implement only the minimum code necessary to make the currently failing test pass.
Every message must begin with a TDD state prefix, and the prefix must match the actual test evidence.
Promote the Dependency Rule If making a failing test for the current SUT pass requires changing a dependency, you must stop and promote that dependency to be the SUT. Write a failing test for the dependency, make it pass, then return to the original SUT.
Clarification:
When testing layer A that mocks layer B:
Example:
throw new UnsupportedOperationException("implement me")Use outside-in development: start from the external interface and work inward.
Why: Every piece of code should be immediately callable and tested from an external perspective. Avoid creating "infrastructure only" code to be connected later.
Correct order for implementing a feature:
Anti-pattern: Creating event publishing code or domain methods without a caller (no REST endpoint or command handler to invoke them). Every method should have an entry point that exercises it.
Whenever tests are mentioned:
Evidence:
Rules:
pass or fail may only be used if tests were just executed.not-run must be used if tests cannot be executed.Goal:
Write a meaningful failing test that expresses the desired behavior.
Allowed actions:
Pre-conditions to enter RED:
Transition:
REDPLANNINGGoal:
Make the failing test pass using the minimum implementation.
Allowed actions:
Pre-conditions to enter GREEN:
Transition:
GREENREDBLOCKEDGoal: The behavior is now correct; evaluate and prepare safe refactoring.
Allowed actions:
Required Evaluation (before any transition):
git diff HEAD, not memory)Skipping directly from GREEN to VERIFY without this explicit evaluation is a TDD violation.
Pre-conditions to enter REFACTOR:
Transition:
REFACTORVERIFYGoal:
Improve internal code structure without changing behavior.
Allowed actions:
Pre-conditions to exit REFACTOR:
Transition:
VERIFYREDBLOCKEDGoal:
Confirm the entire TDD cycle is complete.
Allowed actions:
Pre-conditions to enter COMPLETE:
Transition:
COMPLETEREDBLOCKEDGoal:
The TDD cycle for this behavior is finished.
Allowed actions:
Goal:
Tests cannot be run; you cannot proceed honestly.
Actions:
Transition:
Goal:
The agent has broken the TDD rules.
Actions:
npx claudepluginhub humansintheloop-dev/humansintheloop-dev-workflow-and-tools --plugin idea-to-codeEnforces red-green-refactor TDD cycle with configurable strictness (strict/recommended/off). Use before writing implementation code for any feature or bugfix.