Menu
a workflow for practicing Test-Driven Development (TDD)
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Guidelines for watching CI builds and diagnosing failures. Claude should use this skill when watching a CI build or investigating why a CI build failed.
Structural CRUD and reordering operations on plan files via the `i2code plan` CLI — insert/replace/delete/reorder threads and tasks, mark tasks/steps complete or incomplete, fix numbering, and query plan structure (get-next-task, get-thread, get-summary, list-threads). Claude MUST use this skill (not raw file edits) for any change to a plan file's threads, tasks, or steps, and for reading plan structure programmatically.
Consult the design pattern catalog before implementing or refactoring code.
When running test scripts or long-running commands that produce verbose output, redirect output to a log file under logs/ to avoid truncation in the Bash tool. Claude should use this skill when running test scripts, end-to-end tests, or any command likely to produce large output. NOTE: This skill does not apply to Gradle because test output is written to TEST*.xml files.
a definition of tests and testing in a Java project using Gradle and JUnit 5. Advice on using Gradle to run tests.
When stuck on a problem, formulate a well-structured question and copy it to the clipboard for pasting into ChatGPT. Claude should use this skill when debugging efforts stall or when an outside perspective would help.
| name | tdd |
| description | a workflow for practicing Test-Driven Development (TDD) |
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: