Spec Kitty Guide: Governed Spec-Driven Development with a Kanban Dashboard

Most spec-driven tools assume the agent produces artifacts and a human reviews them occasionally. Spec Kitty takes the stronger position: development is a governed factory line, and every change moves through visible lifecycle lanes — planned, in progress, for review, approved, done — tracked on a local kanban dashboard, with agents working in isolated git worktrees so nothing collides.

Spec Kitty describes itself as "spec-driven development for serious software developers." It supports Claude, Cursor, Gemini, Codex, Copilot, Windsurf, and more, with a workflow of spec → plan → tasks → next → review → accept → merge. It's the most process-heavy of the new wave — closer in spirit to BMad's governance than to OpenSpec's fluidity — but it wraps that process in a visual dashboard that makes the pipeline legible at a glance.

How it works

Repo-native mission artifacts

Spec Kitty stores everything in a kitty-specs/ directory inside your repository: the mission spec, per-feature specs, plans, task files, and the lifecycle state. Because the state lives in the repo, the governance travels with the code — clone the repo, get the whole factory.

The lifecycle lanes

Every spec moves through a visible state machine:

planned → in_progress → for_review → approved → done

• Spec — the feature is written as a spec with requirements.
• Plan — the implementation approach is designed.
• Tasks — the plan decomposes into ordered work items.
• Next — the agent picks the next task in the queue.
• Review — a review lane where the diff is checked against the spec (with a reviewer agent in the loop).
• Accept / Merge — human approval gates before the change lands.

Nothing skips lanes: a change cannot reach done without passing the review lane and the accept gate. That's the governance promise — and the reason it's a fit for teams whose failure mode is agents landing unreviewed changes.

Git worktree isolation

Each in-flight spec gets its own git worktree — a separate checkout on disk. Agents work in parallel without stepping on each other: no branch-switching thrash, no "who touched this file" races. This is the same pattern as parallel agent workflows, built into the framework instead of left to the terminal setup.

The kanban dashboard

Spec Kitty ships a local kanban view of the lifecycle — you can see, at a glance, which specs are stuck in review, which agents are working what, and what's ready to accept. It turns "spec-driven development" from an invisible process into something you can look at.

Where Spec Kitty fits

Choose Spec Kitty when:

• You want hard governance: nothing merges without a review lane and an accept gate.
• You're running several agents on one repo and want collision-free parallelism out of the box.
• A visual lifecycle (kanban) would help your team actually see the pipeline working.
• You like the idea of a "software factory" where the spec is the work item that travels the line.

Skip it when:

• You want the lightest possible process — specdd or OpenSpec will feel less like a factory.
• Your team reviews in GitHub PRs and wants the tool to stay out of the way — the Spec Kit branch-per-spec model maps more directly onto PRs.
• You need the spec store itself to be the source of truth — Spec Kitty's spec is a work item in a pipeline, not a living requirements document.

Quick comparison with the ecosystem

| | Spec Kitty | GitHub Spec Kit | BMad Method | |---|---|---|---| | Governance | Lifecycle lanes + accept gates | Constitution compliance gates | Formal phase gates | | Parallelism | Built-in git worktrees | Branch-per-feature | Branch-per-story | | Visibility | Local kanban dashboard | Artifacts in .specify/ | Phase artifacts + orchestrator | | Best for | Teams that want to see governance | Teams standardizing on the standard | Full lifecycle with adversarial review |

For the broader landscape, see the complete spec-driven coding guide and the Spec Kit vs OpenSpec vs BMad comparison.

Getting started

Clone or install Spec Kitty into your repo, run the init command to scaffold kitty-specs/, and propose your first spec. The kanban will show it land in planned — then watch it travel the lanes. The visible lifecycle is the feature: you'll know exactly where every change is, and so will the agents.