tdd-proof

Purpose

Implements a change test-first with recorded proof.

Source Skill purpose

When to use it

Use tdd-proof whenever a feature or bug fix must be implemented with recorded test-first evidence. Every non-exempt path receives an assertion failure about the intended behavior, followed by the smallest implementation and a successful run of the same test. A separate worktree checks that removing the behavior makes the test fail again, guarding against a hollow check. The wider suite must remain green. The plan names exemptions; the implementer cannot invent them or weaken a test to reach a pass.

A valid RED reaches the behavior assertion; import, syntax and setup errors are repaired before evidence is recorded. GREEN reruns the exact same focused command and then the wider suite. The hollow check breaks the new behavior only in a separate worktree. Each cycle records its path and criterion before another begins. Refactoring happens only while tests are green and inside scope, with no behavior change. A test is never skipped, deleted or loosened to reach GREEN.

Source Skill purpose

How it works

Steps of the skill, in source order

Source Flow

Define scope Map paths, criteria, exemptions and exact test commands before editing.
Source Flow
Run a baseline Run the untouched suite and record pre-existing failures.
Source Flow
Complete each cycle For each mapped path and criterion, write a test, prove the expected assertion fails, make that test pass, then check it still fails without the production change.
Source Flow
Write the ledger Record each path and criterion cycle before starting the next.
Source Flow
Validate cycles Run the TDD ledger validator against the planned scope mapping.
Source Flow
Clean isolation Remove recorded worktrees and verify only planned paths changed.
Source Flow
Report evidence Return each test, failure reason, successful command and hollow-check result.
Source Flow

Key rules

Edit only paths in the frozen plan's scope.
Source Hard rules
Count only a behavior assertion failure as RED, never a compile or setup error.
Source Hard rules
Give each behavior and criterion its own recorded cycle.
Source Hard rules
Use the same test command for RED and GREEN, then run the wider suite.
Source Hard rules
Prove the check is not hollow by breaking the behavior in a separate worktree.
Source Hard rules

Output and gate

Output

The skill definition states no output.

Source Skill definition

Gate

Handoff requires valid RED and GREEN records for every non-exempt scope path.
Source Gate rule

Source