Imported from 1074739572/ProofTask (skills/test-driven-development/SKILL.md). Install upstream with npx skills add 1074739572/ProofTask --skill test-driven-development. Copyright stays with the author.

Test-Driven Development

This is a compact adaptation of obra/superpowers' test-driven-development skill (MIT; see LICENSE.txt).

1. State the one behavior that must change.
2. Write or bind one focused test that demonstrates that behavior.
3. Observe a meaningful red result before implementation. A syntax/import error is not a useful red result.
4. Make the smallest production change that turns the red result green.
5. Re-run the same proof, then the required broader verification.
6. Refactor only after green, without adding unrequested behavior.

Test Quality

• Give the test a behavior-specific name.
• Assert on real externally observable behavior, not merely that a mock was called, unless the boundary itself is the behavior under test.
• Keep one test focused on one outcome; separate independent edge cases.
• A passing test written after implementation is evidence of coverage, but not evidence that it could have caught the original defect.

Test Architecture

Choose the smallest executable boundary before writing a test.

• For key bindings, cursor/text editing, queues, reducers, parsing, formatting, and state transitions, test a pure logic module. Do not import a complete UI application entry such as App.tsx, index.tsx, or a native renderer merely to reach a helper.
• For rendered component behavior, use the repository's component/browser test harness only when that harness is available. Native terminal or renderer initialization belongs in a small integration test, not a normal unit test.
• Use the test runner declared by the project. Do not invent a Node loader when the project vendors or declares another runner such as Bun.
• When a needed helper does not yet exist, target an existing narrow module in the approved production scope and make the missing API fail as a behavior assertion. Do not make the baseline fail because the test imports an absent module or cannot initialize infrastructure.

Goal Boundaries

• The Goal runner owns the bound command and records its evidence. Do not replace it, skip it, or edit a bound test merely to make it pass.
• If the runner already generated and recorded a failing baseline, use that baseline as the red phase instead of generating competing tests.
• For a repair, first reproduce the reported failure; then change one cause at a time and keep the regression test as the proof.