From forge
Write failing test before any production code. Red-green-refactor for all features and fixes. No exceptions except config, types, and static assets.
npx claudepluginhub caseyrtalbot/forge --plugin forgeThis skill uses the workspace's default tool permissions.
Write the test before writing the code. Watch the test fail. Write the minimal code to make it pass. Verify. Commit. This is not a suggestion. This is the discipline that separates working code from code that happens to work right now.
Verifies tests pass on completed feature branch, presents options to merge locally, create GitHub PR, keep as-is or discard; executes choice and cleans up worktree.
Guides root cause investigation for bugs, test failures, unexpected behavior, performance issues, and build failures before proposing fixes.
Writes implementation plans from specs for multi-step tasks, mapping files and breaking into TDD bite-sized steps before coding.
Write the test before writing the code. Watch the test fail. Write the minimal code to make it pass. Verify. Commit. This is not a suggestion. This is the discipline that separates working code from code that happens to work right now.
NO implementation code without a failing test first.This is the Iron Law of prove-first. There are no exceptions worth discussing.
Wrote code before the test? Delete it. Do not keep it as "reference." Do not "adapt" it. Do not look at it while writing the test. Delete means delete. Start with the test.
The only exceptions are:
If any of these are true, you have gone off track. Stop and course-correct:
digraph prove_first {
"Understand task requirements" [shape=box];
"Write failing test" [shape=box];
"Run test, confirm RED" [shape=diamond];
"Test fails for right reason?" [shape=diamond];
"Write minimal implementation" [shape=box];
"Run test, confirm GREEN" [shape=diamond];
"Refactor if needed" [shape=box];
"Still GREEN?" [shape=diamond];
"Run full verification" [shape=box];
"Commit" [shape=doublecircle];
"Understand task requirements" -> "Write failing test";
"Write failing test" -> "Run test, confirm RED";
"Run test, confirm RED" -> "Test fails for right reason?" [label="fails"];
"Run test, confirm RED" -> "Write failing test" [label="passes (test is wrong)"];
"Test fails for right reason?" -> "Write minimal implementation" [label="yes"];
"Test fails for right reason?" -> "Write failing test" [label="no, fix test"];
"Write minimal implementation" -> "Run test, confirm GREEN";
"Run test, confirm GREEN" -> "Refactor if needed" [label="passes"];
"Run test, confirm GREEN" -> "Write minimal implementation" [label="fails"];
"Refactor if needed" -> "Still GREEN?";
"Still GREEN?" -> "Run full verification" [label="yes"];
"Still GREEN?" -> "Refactor if needed" [label="no, fix"];
"Run full verification" -> "Commit";
}
"Too simple to test" Simple code breaks. Simple tests take 30 seconds to write. The discipline is the point, not the complexity.
"I'll write tests after" Tests written after implementation verify what the code does, not what it should do. They encode bugs as expected behavior. Tests written first encode requirements.
"The test is too hard to write without seeing the implementation" If you cannot describe the expected behavior without seeing the code, you do not understand the requirement. Go back to the task description.
"I'll keep the code I already wrote" Sunk cost. Code written without a test has no proof of correctness. It may be right. It may be subtly wrong in ways you will discover in production. Delete it.
For the full rationalization table (15 common excuses and their rebuttals), see rationalization-table.md. For extended Iron Law guidance including the verification checklist and delete-and-start-over protocol, see iron-law.md.
When implementation is complete and tests pass, the task returns to drive-execution for quality review via inspect-work.