openspec-plus-tdd

This skill activates during OpenSpec change implementation to enforce atomic test-driven development: every test—acceptance, unit, edge case, or helper—must fail for the right reason before production code is written to make it pass. Gherkin scenarios in spec.md are the canonical acceptance contract; every relevant scenario must become at least one test. The per-test state machine forbids batching, skipping refactor assessment, or shipping with uncovered scenarios.

openspec-plus-tdd enforces strict RED-GREEN-REFACTOR discipline per test when implementing OpenSpec changes, requiring failing tests before any production code.

AI-generated summary based on this skill's SKILL.md

★ 133 ⁮ 6 MIT updated 2026-07-23 by sudokar

Install

sudokar/openspec-plus/openspec-plus-tdd

Manual (git clone) CLI (skillfed)coming soon

git clone https://github.com/sudokar/openspec-plus
cp -r openspec-plus/skills/openspec-plus-tdd ~/.claude/skills/openspec-plus-tdd

Frequently asked questions

AI-generated answers based on this skill's SKILL.md and metadata

What is openspec-plus-tdd and when should I use it?

openspec-plus-tdd is a skill that enforces test-driven development discipline during OpenSpec change implementation. Activate it whenever you're implementing a task that modifies spec.md or production code. The skill ensures every test—acceptance, unit, edge case, or helper—fails for the right reason before you write production code to make it pass, and that Gherkin scenarios become mandatory acceptance tests with full coverage.

How does openspec-plus-tdd handle red green refactor test driven development?

openspec-plus-tdd enforces a strict per-test RED-GREEN-REFACTOR cycle. In RED, you write a single test that must fail for the correct reason. In GREEN, you write minimal production code to make only that test pass. In REFACTOR, you improve code quality without changing test behavior. You must complete this cycle one test at a time—no batching—and never write production code before observing a test failure.

Must I write tests before code implementation with this skill?

Yes. openspec-plus-tdd mandates that production code only exists after you observe a failing test. Every line of production code must be justified by a test that failed first. This prevents speculative code and ensures all behavior is test-driven and intentional.

How do gherkin scenario acceptance testing and spec.md coverage work?

openspec-plus-tdd treats Gherkin scenarios in spec.md as the canonical acceptance contract. Every relevant scenario must translate into at least one acceptance test with mandatory coverage. Before you finish the task, verify that all scenarios have corresponding tests and that no test is skipped or batched with others.

What does 'test one at a time no batching' mean in openspec-plus-tdd?

openspec-plus-tdd forbids running or writing multiple tests in parallel or as a batch. You must execute the RED-GREEN-REFACTOR cycle for one atomic test, complete it fully, then move to the next. This discipline prevents incomplete refactoring, hidden failures, and ensures each test's state machine is pristine before proceeding.

What happens if I skip refactor assessment or ship without scenario coverage?

openspec-plus-tdd treats skipping refactor assessment and shipping with uncovered scenarios as violations. Every GREEN phase must be followed by honest refactor assessment. Every Gherkin scenario in your task's scope must have at least one passing test before you mark the task complete. Violations break the atomic per-test workflow and undermine the skill's core discipline.

SKILL.md

rendered from the published skill — quoted content, verbatim