mcpField
S
spec-driven-tdd

spec-driven-tdd

github.com/strelov1Agent workflows1343 installsUpdated 12w ago
Repository

About spec-driven-tdd

spec-driven-tdd is a development skill for teams using OpenSpec and Superpowers to plan and implement changes one task at a time. It combines test-driven development with review gates, isolated worktrees, and tracked completion.

Key features

  1. 01OpenSpec-based planning and task tracking
  2. 02Risk-gated feasibility spikes
  3. 03Isolated Git worktrees per change
  4. 04RED-to-GREEN task implementation loop
  5. 05Code review before marking tasks done
  6. 06Verification, archive, and spec sync

Use cases

  1. 01Planning implementation scope and tasks in OpenSpec
  2. 02Implementing changes with tests written first
  3. 03Keeping concurrent or ongoing work isolated
  4. 04Requiring review before closing each task

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/strelov1/spec-driven-tdd --skill spec-driven-tdd

After installing, type/spec-driven-tddin Claude Code to confirm it loaded.

Details

From the project README

spec-driven-tdd

Plan and track in OpenSpec. Implement with Superpowers discipline. One change at a time, one task at a time.

Core principle: OpenSpec owns what and progress; the execution skills own how. A task is done only after its review is clean — not at green tests.

Dependencies

Requires OpenSpec CLI + Superpowers installed. If a referenced skill or command is unavailable, say so and fall back per docs/dependencies.md — never silently skip a step. /code-review is a Claude-Code-only optional enhancement.

Lifecycle

1. Plan (OpenSpec)

Optional — feasibility spike (risk-gated). If the work carries unproven technical risk (an untested approach, an external API, an open "is this possible?"), invoke the spike skill before proposing. Skip it when feasibility is already clear. Act on its verdict: VALIDATED → proceed to propose; PARTIAL → narrow scope to the viable subset, then propose; INVALIDATED → stop, do not create the change (tell the user why). Spike code is throwaway and never enters the change's worktree.

If no change exists for the work, run /opsx:propose (it uses brainstorming to shape scope, then writes proposal/design/tasks). OpenSpec is the single source of truth for scope and the task list. Do not invent tasks outside it.

2. Isolate (worktree)

Before touching code, invoke using-git-worktrees to create an isolated worktree for the change so the main workspace stays clean. (Pairs with finishing-a-development-branch at the end.)

3. Implement — per-task loop

Get the task list and context via /opsx:apply (read every contextFiles path). Then, for EACH pending task, run this micro-cycle:

  1. RED — invoke test-driven-development: write a failing test first. No production code without a failing test.
  2. GREEN — minimal code to pass. If a test fails unexpectedly, invoke systematic-debugging before guessing.
  3. REFACTOR — unit-local cleanup under green tests.
  4. simplify — invoke this pack's simplify skill for a diff-wide quality pass; it applies edits.
  5. Re-run tests — they must stay green after simplify.
  6. Review — invoke requesting-code-review on the task's diff; use receiving-code-review to act on it. On Claude Code you may additionally run /code-review. Fix Critical + Important before continuing.
  7. Mark done — only now flip the task - [ ] → - [x] in the OpenSpec tasks file.

Optional mode — large changes: delegate to subagent-driven-development only when the task list is genuinely large and tasks are independent — not for a handful of tasks you can run inline. It dispatches each task to a fresh subagent with per-task review. Use dispatching-parallel-agents only for tasks with no shared state, and keep the number of concurrent subagents low.

Pause and ask if a task is ambiguous or implementation reveals a design issue (then suggest updating the OpenSpec artifacts).

4. Finish

When all tasks are [x]:

  1. verification-before-completion — confirm the change actually works.
  2. finishing-a-development-branch — integrate the worktree's branch.
  3. /opsx:archive then /opsx:sync — close tracking and update main specs.

Checklist

  • Change selected/created in OpenSpec
  • Worktree created
  • Every task ran RED→GREEN→REFACTOR→simplify→review before [x]
  • All tasks [x]
  • Verified, branch finished, change archived + synced

Comments

Markdown supported