openspec-plus-tdd

OpenSpec Plus TDD

Mission

Strict RED-GREEN-REFACTOR per test for OpenSpec change implementation. Every test — whether derived from a Gherkin scenario relevant to the slice in spec.md, written for a unit, edge case, helper, or error path — goes through its own atomic cycle before the next test begins. Production code exists only to make a previously-failing test pass. Surgical changes, simplicity first, no speculative abstractions, every changed line traces to a slice task.

Gherkin scenarios in spec.md are the canonical source for acceptance tests: every scenario relevant to the slice MUST become at least one test. The implementer is encouraged to add additional tests — unit tests for individual functions, edge-case tests, helper tests, error-path tests — when fast-feedback granularity is valuable. Every test follows the same cycle.

Loaded by openspec-plus-apply (subagent prompt + inline mode) before any code is written.

RIGID. NEVER write production code before a test fails for the right reason. NEVER write tests for multiple cases before the first one is GREEN. NEVER skip the REFACTOR assessment. NEVER mark a task [x] while a relevant test is failing or skipped. NEVER add comments for non-complex logic. NEVER refactor code outside the slice. NEVER write any code (test or production) before reading the project's referenced coding/testing standards. NEVER ship without covering every Gherkin scenario in spec.md with at least one test. Letter and spirit are the same.

Red flags — STOP, you are about to violate this skill:

• "I'll write the test after, it's faster"
• "Too simple to need a test"
• "Manually verified, that's enough"
• "Gherkin scenario is vague, generic test is fine"
• "Skip this failing test, circle back later"
• "Mark .skip to unblock the slice"
• "While I'm here, clean up the adjacent code"
• "Add an interface in case we swap implementations"
• "Short comment explains the obvious"
• "Error handling for cases that can't happen"
• "Test passed first run, must be right"
• "Let me write tests for all the cases first, then implement"
• "Test 1 done — I have a clear picture, let me write all the rest at once"
• "I have a clear picture of all 5 cases — let me write them all"
• "Writing one test at a time is slower"
• "These cases are related, I'll batch them"
• "The code I'm about to write covers test 2 anyway, no need to write its test separately first"
• "Acceptance tests cover the happy path — skip the unit/edge tests"
• "Scenarios covered, no need to add granular tests even though the helper has edge cases"
• "Nothing to refactor, skip the assessment"
• "I know the project conventions, no need to re-read AGENTS.md"
• "AGENTS.md has many rules — I'll apply the ones that feel relevant"