Spec Kitty emerging
Spec Kit descendant that extends spec, plan, and task generation into a governed, repository-native execution loop with work packages, isolated worktrees, review state, acceptance, and merge decisions.
Reviewed 3 months ago · Aug 1, 2026
Website GitHub · Priivacy-ai/spec-kitty Compare with other frameworks →
- Stars
- 1.7K
- Contributors
- 127
- Open issues
- 982
- Age
- 1 years
- Last push
- today
- Latest release
- v3.2.7 Sep 9, 2026
View weekly commit data
| Week starting | Commits |
|---|---|
| Oct 11, 2026 | 572 |
| Oct 4, 2026 | 2.1K |
| Sep 27, 2026 | 1.4K |
| Sep 20, 2026 | 937 |
| Sep 13, 2026 | 605 |
| Sep 6, 2026 | 900 |
| Aug 30, 2026 | 1K |
| Aug 23, 2026 | 527 |
| Aug 16, 2026 | 912 |
| Aug 9, 2026 | 718 |
| Aug 2, 2026 | 618 |
| Jul 26, 2026 | 559 |
| Jul 19, 2026 | 534 |
| Jul 12, 2026 | 488 |
| Jul 5, 2026 | 317 |
| Jun 28, 2026 | 325 |
| Jun 21, 2026 | 309 |
| Jun 14, 2026 | 270 |
| Jun 7, 2026 | 347 |
| May 31, 2026 | 1.1K |
| May 24, 2026 | 169 |
| May 17, 2026 | 196 |
| May 10, 2026 | 42 |
| May 3, 2026 | 128 |
| Apr 26, 2026 | 246 |
| Apr 19, 2026 | 275 |
| Apr 12, 2026 | 132 |
| Apr 5, 2026 | 230 |
| Mar 29, 2026 | 93 |
| Mar 22, 2026 | 11 |
| Mar 15, 2026 | 44 |
| Mar 8, 2026 | 152 |
| Mar 1, 2026 | 11 |
| Feb 22, 2026 | 305 |
| Feb 15, 2026 | 430 |
| Feb 8, 2026 | 514 |
| Feb 1, 2026 | 290 |
| Jan 25, 2026 | 340 |
| Jan 18, 2026 | 796 |
| Jan 11, 2026 | 633 |
| Jan 4, 2026 | 21 |
| Dec 28, 2025 | 17 |
| Dec 21, 2025 | 0 |
| Dec 14, 2025 | 160 |
| Dec 7, 2025 | 10 |
| Nov 30, 2025 | 0 |
| Nov 23, 2025 | 4 |
| Nov 16, 2025 | 99 |
| Nov 9, 2025 | 203 |
| Nov 2, 2025 | 44 |
| Oct 26, 2025 | 70 |
| Oct 19, 2025 | 3 |
Metrics updated Oct 15, 2026 · collected automatically from the GitHub API
Core approach
Builds on GitHub Spec Kit's specification → plan → tasks lineage, then adds canonical mission state and a runtime for executing it. Mission artifacts live under kitty-specs/; tasks become work packages that advance through lifecycle lanes in isolated .worktrees/. A next → review → accept → merge loop keeps implementation, acceptance criteria, review evidence, and merge decisions in Git, with a local dashboard and retrospective closing the loop.
Workflow
spec-kitty init— install the selected agent integrations and initialize repository-local configuration/spec-kitty.charter— establish the project's governing principles/spec-kitty.specify— turn product intent into a mission specification underkitty-specs//spec-kitty.plan— research the codebase and produce the implementation plan/spec-kitty.tasks— decompose the plan into acceptance-bound work packages and lifecycle lanesspec-kitty next --agent <agent> --mission <slug>— choose the next eligible action and dispatch implementation in an isolated worktree/spec-kitty.reviewand/spec-kitty.accept— review completed packages, record decisions, and validate the approved mission/spec-kitty.merge— merge accepted work to the target branch; a mission review andretrospective.yamlcapture follow-up learning
Supported tools
- Claude Code
- Codex
- Cursor
- Gemini CLI
- GitHub Copilot
- Windsurf
- OpenCode
- Qwen Code
- Kiro
- Antigravity
- Kilo
- Augment
- Pi
- Mistral Vibe
- Letta Code
Strengths
- Repository-native governance preserves specs, plans, work packages, agent actions, review evidence, acceptance, and merge state as an auditable trail
- Work-package boundaries, explicit lifecycle lanes, and isolated Git worktrees give parallel agents a concrete coordination model
- Completes the post-planning loop that its Spec Kit ancestor historically left to the agent:
next, review, acceptance, merge, and retrospective are first-class stages - Local-first operation does not require its optional hosted tracker or sync service, and the dashboard makes mission progress inspectable
- Broad, explicitly documented integrations expose the same workflow across slash-command hosts and project-local skill hosts
Limitations
- The project itself says the workflow is overkill for one-off edits, tiny scripts, and teams that do not use Git
- Conventions are still moving quickly: the current documentation treats both the 1.x and 2.x lines as historical and requires migrations into 3.x
- Its mission state, work-package lanes, worktrees, governance commands, dashboard, and retrospectives create substantially more ceremony than the Spec Kit workflow it extends
- The Python CLI and its wide compatibility matrix add installation, upgrade, and host-parity maintenance that prompt-only frameworks avoid
Notes
Spec Kitty is a descendant, not an unrelated reinvention, of GitHub Spec Kit: its maintainer described it as
“my fork” in a Spec Kit design discussion, and its current
FAQ
identifies the layer it adds — mission state, work-package lanes, worktree isolation, a dashboard, governance
commands, and the explicit next → review → accept → merge runtime. That governed execution layer is the reason to
track it separately. The supported-agents reference
documents 16 host surfaces; the legacy Amazon Q surface is deliberately omitted above.
This assessment observes the 3.x repository at
f9fde44.