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 4 weeks ago · Aug 1, 2026
Website GitHub · Priivacy-ai/spec-kitty Compare with other frameworks →
- Stars
- 1.6K
- Contributors
- 78
- Open issues
- 680
- Age
- 11 months
- Last push
- today
- Latest release
- v3.2.5 Jul 8, 2026
View weekly commit data
| Week starting | Commits |
|---|---|
| Aug 23, 2026 | 150 |
| Aug 16, 2026 | 499 |
| Aug 9, 2026 | 435 |
| Aug 2, 2026 | 393 |
| Jul 26, 2026 | 314 |
| Jul 19, 2026 | 291 |
| Jul 12, 2026 | 270 |
| Jul 5, 2026 | 187 |
| Jun 28, 2026 | 171 |
| Jun 21, 2026 | 191 |
| Jun 14, 2026 | 176 |
| Jun 7, 2026 | 248 |
| May 31, 2026 | 883 |
| May 24, 2026 | 136 |
| May 17, 2026 | 188 |
| May 10, 2026 | 41 |
| May 3, 2026 | 127 |
| Apr 26, 2026 | 211 |
| Apr 19, 2026 | 233 |
| Apr 12, 2026 | 102 |
| Apr 5, 2026 | 175 |
| Mar 29, 2026 | 66 |
| Mar 22, 2026 | 7 |
| Mar 15, 2026 | 29 |
| Mar 8, 2026 | 107 |
| Mar 1, 2026 | 7 |
| Feb 22, 2026 | 213 |
| Feb 15, 2026 | 329 |
| Feb 8, 2026 | 307 |
| Feb 1, 2026 | 212 |
| Jan 25, 2026 | 224 |
| Jan 18, 2026 | 553 |
| Jan 11, 2026 | 505 |
| Jan 4, 2026 | 17 |
| Dec 28, 2025 | 15 |
| Dec 21, 2025 | 0 |
| Dec 14, 2025 | 105 |
| Dec 7, 2025 | 6 |
| Nov 30, 2025 | 0 |
| Nov 23, 2025 | 2 |
| Nov 16, 2025 | 70 |
| Nov 9, 2025 | 116 |
| Nov 2, 2025 | 34 |
| Oct 26, 2025 | 57 |
| Oct 19, 2025 | 3 |
| Oct 12, 2025 | 0 |
| Oct 5, 2025 | 38 |
| Sep 28, 2025 | 13 |
| Sep 21, 2025 | 52 |
| Sep 14, 2025 | 70 |
| Sep 7, 2025 | 40 |
| Aug 31, 2025 | 9 |
Metrics updated Aug 27, 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.