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
Decision gist · record as of 2026-07-23
openspec-plus-tdd enforces strict RED-GREEN-REFACTOR discipline per test when implementing OpenSpec changes, requiring failing tests before any production code. 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.
Use it when
- openspec-plus-tdd enforces a strict per-test RED-GREEN-REFACTOR cycle.
- Yes.
Verify before relying
Read SKILL.md below before installing (1 file). Open directory: indexed for reading, not audited.
Similar skills
Install
sudokar/openspec-plus/openspec-plus-tdd
Open directory. Skills are indexed for reading, not audited. Review a skill's body before installing it.
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.
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
(truncated - see the full file via the links below)
File tree — 1 file
skills/openspec-plus-tdd/SKILL.md
Let your AI agent find skills like this
Example. Real query, live index.
You found this page by searching. An agent finds it by wishing: SkillFed indexes 56,283 agent skills by what they can do, searchable in plain language.
wish › “Enforce strict RED-GREEN-REFACTOR cycle per test for OpenSpec changes”
Give your agent the search over MCP, or paste the wish link into any chat. No install? Search from any chat →
Related skills
This skill guides you through test-driven development using separate subagents for test writing and implementation, ensuring each phase stays focused on its role. It supports Jest, Vitest, pytest, Go test, cargo test, PHPUnit, and RSpec, with modes for interactive approval, autonomous execution, and dry-run validation. Vertical slicing and context isolation keep your TDD workflow disciplined and your tests honest.
tdd guides you through strict test-driven development using the red-green-refactor cycle: write a failing test, implement minimal code to pass it, then refactor. The skill enforces the discipline of writing tests before production code and provides framework-specific commands for multiple languages.
Test Driven Development teaches the red-green-refactor discipline for writing code validated by tests before implementation. Learn when to apply TDD across feature work, bug fixes, and refactoring, plus how to design testable interfaces, mock at system boundaries, and avoid common pitfalls.
This skill walks you through the test-first workflow: write a failing test, verify it fails correctly, implement just enough code to pass, then refactor while keeping tests green. You'll learn why test order matters, how to recognize when you're rationalizing shortcuts, and how to apply TDD to features, bug fixes, and refactoring across any language.
tdd guides you through writing tests before implementation using the red-green-refactor workflow. Each cycle commits a failing test marked red, then minimal passing code marked green, with refactoring only after all tests pass. The skill enforces behavioral testing over implementation details and includes commit hygiene checks to keep your tree lint-clean at every step.
rtk-tdd enforces the red-green-refactor cycle for Rust development, automatically guiding you through failing tests, minimal implementations, and refactoring phases. It provides Rust-idiomatic testing patterns using anyhow/thiserror, cfg(test) modules, and Arrange-Act-Assert workflows, with pre-commit gates ensuring code quality.