Spec Kitty

Spec-Driven Development for AI coding agents

Spec Kitty is an open-source CLI workflow for spec-driven development with AI coding agents. It helps teams turn product intent into implementation with a repeatable path: spec -> plan -> tasks -> spec-kitty next (agent loop) -> review -> merge.

AI coding workflows often break down on larger features:

• Requirements and design decisions drift over long agent sessions
• Parallel work is hard to coordinate across branches
• Review and acceptance criteria become inconsistent from one feature to the next

Spec Kitty addresses this with repository-native artifacts, work package workflows, and lane-aware git worktree isolation.

• Project Owners who need explicit approval boundaries and outcome accountability
• External Tech Lead Evaluators assessing delivery predictability and adoption fit
• External Architect Evaluators evaluating governance durability and boundary clarity
• External Product Manager Evaluators validating intent-to-delivery traceability
• Lead Developers coordinating implementation quality and handoffs
• Maintainers preserving operational consistency across features and agents

Try it now: pip install spec-kitty-cli && spec-kitty init my-project --ai claude

Quick Start • Claude Code Guide • Live Dashboard • 13 AI Agents • Full Docs

graph LR
    A[📝 Specify<br/>WHAT to build] --> B[🎯 Plan<br/>HOW to build]
    B --> C[📋 Tasks<br/>Work packages]
    C --> D[⚡ spec-kitty next<br/>Agent loop]
    D --> E[🔍 Review<br/>Quality gates]
    E --> F[🚀 Merge<br/>Ship it]

    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#fff3e0
    style D fill:#f3e5f5
    style E fill:#e8f5e9
    style F fill:#fce4ec

Current stable release line: v3.1.x (current release: 3.1.5 on main, GitHub Releases, and PyPI)

3.1.x highlights:

• Runtime loop is the primary workflow — spec-kitty next drives implementation and review, and omitting --result is a safe query-only mode
• Review and merge resilience — focused fix prompts, persisted review-cycle-N.md artifacts, merge --resume, implement --recover, and stronger recovery diagnostics in doctor
• Hosted auth and sync are first-class — browser-based spec-kitty auth login, explicit SaaS rollout gating, and clearer tracker/discovery readiness checks
• Charter bundle is now a validated contract — bundle health can be checked with spec-kitty charter bundle validate, and worktrees read canonical charter outputs from the main checkout
• Sparse-checkout failures are defended in depth — merge/implement preflights fail closed, safe_commit rejects out-of-scope staging, and spec-kitty doctor sparse-checkout --fix repairs legacy repos
• Upgrade auto-commit is safer — rename-heavy migrations and directory-backed changes now commit cleanly during spec-kitty upgrade instead of tripping the staging backstop
• Charter guidance is language-neutral by default — packaged defaults no longer bias planning toward pytest/junit, and scoped doctrine assets still load when no active language filter is available
• 13 slash-command agents are supported — including first-class Kiro support while retaining legacy q compatibility during the rebrand

Jump to: Getting Started • Examples • 13 AI Agents • CLI Reference • Worktrees • Troubleshooting

Spec Kitty now uses main as the stable 3.x release line. The former 1.x line is deprecated and moves to 1.x-maintenance for maintenance-only fixes.

For users: install the stable line from PyPI with pip install spec-kitty-cli. For existing 3.0.x users: upgrade to 3.1.x and run spec-kitty upgrade in each project — the charter rename, mission identity, and prompt-neutrality migrations remain automatic. For existing 1.x or 2.x users: migrate to 3.1.x; 1.x-maintenance is maintenance-only and will no longer publish new PyPI releases.

Run multi-agent delivery with an external orchestrator while keeping workflow state and guardrails in spec-kitty. Core CLI orchestration is exposed as spec-kitty orchestrator-api; there is no in-core spec-kitty orchestrate shim.

Terminology note:

• Mission Type = reusable blueprint
• Mission = concrete tracked item
• Mission Run = runtime/session instance
• --mission is the canonical flag in 3.1.x; --feature is retained only as a hidden deprecated alias

# Verify host contract
spec-kitty orchestrator-api contract-version --json

# Use the reference external orchestrator
spec-kitty-orchestrator orchestrate --mission 034-my-mission --dry-run
spec-kitty-orchestrator orchestrate --mission 034-my-mission

Docs:

• External provider runbook: docs/how-to/run-external-orchestrator.md
• Custom provider guide: docs/how-to/build-custom-orchestrator.md

sequenceDiagram
    participant Lead as 👨‍💼 Lead Architect
    participant Claude as 🤖 Claude (Spec)
    participant Cursor as 🤖 Cursor (Impl)
    participant Gemini as 🤖 Gemini (Review)
    participant Dashboard as 📊 Live Kanban

    Lead->>Claude: /spec-kitty.specify
    Claude->>Dashboard: WP01-WP05 (planned)

    par Parallel Work
        Lead->>Cursor: implement WP01
        Lead->>Cursor: implement WP02
    end

    Cursor->>Dashboard: WP01 → in_progress (Doing)
    Cursor->>Dashboard: WP01 → for_review
    Lead->>Gemini: /spec-kitty.review WP01
    Gemini->>Dashboard: WP01 → done

    Note over Dashboard: Real-time updates<br/>No branch switching

Key Benefits:

• 🔀 Parallel execution - Multiple WPs simultaneously
• 🌳 Worktree isolation - Each swim lane gets one worktree, and sequential WPs in the same swim lane reuse it
• 👀 Full visibility - Dashboard shows who's doing what
• 🔒 Security boundary - Orchestration policy and transitions are validated at the host API boundary

Spec Kitty includes a live dashboard that automatically tracks your feature development progress. View your kanban board, monitor work package status, and see which agents are working on what—all updating in real-time as you work.

Kanban board showing work packages across all lanes with agent assignments

Feature overview with completion metrics and available artifacts

Start the dashboard when you want it with /spec-kitty.dashboard or spec-kitty dashboard. The CLI starts the correct project dashboard if it is not already running, lets you request a specific port with --port <PORT> (defaults to auto-select from 3000-5000), can open the browser for you with --open, and stops the instance cleanly with --kill.

Key Features:

• 📋 Kanban Board: Visual workflow across canonical lifecycle lanes (including blocked and canceled) with Doing rendered as in_progress
• 📈 Progress Tracking: Real-time completion percentages and task counts
• 👥 Multi-Agent Support: See which AI agents are working on which tasks
• 📦 Artifact Status: Track specification, plan, tasks, and other deliverables
• 🔄 Live Updates: Dashboard refreshes automatically as you work

Work packages flow through automated quality gates using the canonical 2.x lifecycle FSM. Agents move tasks between lanes, and the dashboard tracks state transitions in real-time.

stateDiagram-v2
    [*] --> planned
    planned --> claimed
    claimed --> in_progress
    in_progress --> for_review
    in_progress --> approved: direct approval
    for_review --> in_review: reviewer claims
    in_review --> approved: approved
    in_review --> done: approved + done
    in_review --> in_progress: changes requested
    in_review --> planned: replan
    approved --> done
    planned --> blocked
    claimed --> blocked
    in_progress --> blocked
    for_review --> blocked
    in_review --> blocked
    approved --> blocked
    blocked --> in_progress
    planned --> canceled
    claimed --> canceled
    in_progress --> canceled
    for_review --> canceled
    in_review --> canceled
    approved --> canceled
    blocked --> canceled

Key Lane Transitions & CLI Commands:

• planned → in_progress: /spec-kitty.implement or spec-kitty implement WP##
• in_progress → for_review: Automatic on completion, or manual via /spec-kitty.finalize WP##
• for_review → in_review: Automated by reviewer claim
• in_review → approved: /spec-kitty.review --approve WP##
• in_review → done: /spec-kitty.review --approve --done WP##
• in_progress → approved: Direct approval (bypasses review), see docs/how-to/direct-approval.md

Lane terminology follows the glossary: see glossary/contexts/orchestration.md#lane.

New to Spec Kitty? Here's the complete lifecycle from zero to shipping features:

# 1. Install the CLI
pip install spec-kitty-cli
# or
uv tool install spec-kitty-cli

# 2. Initialize your project
spec-kitty init my-project --ai claude

# 3. Verify setup (optional)
cd my-project
spec-kitty verify-setup  # Checks that everything is configured correctly

# 4. View your dashboard
spec-kitty dashboard  # Opens http://localhost:3000-5000

What just happened:

• ✅ Created .claude/commands/ (or .gemini/, .cursor/, etc.) with 13 slash commands
• ✅ Created .kittify/ directory with scripts, templates, and mission configuration
• ✅ Started real-time kanban dashboard (runs in background)
• ✅ Initialized git repository with proper .gitignore

cd your-project
spec-kitty upgrade              # Upgrade to current version

# Preview changes without applying
spec-kitty upgrade --dry-run

# Show detailed migration information
spec-kitty upgrade --verbose

# Upgrade to specific version
spec-kitty upgrade --target 0.6.5

# Skip worktree upgrades (main project only)
spec-kitty upgrade --no-worktrees

# JSON output for CI/CD integration
spec-kitty upgrade --json

# Launch your chosen AI coding agent
claude   # For Claude Code
# or
gemini   # For Gemini CLI
# or
code     # For GitHub Copilot / Cursor

Verify slash commands loaded: Type /spec-kitty and you should see autocomplete with all 13 commands.

Still in main repo - Start with your project's governing principles:

/spec-kitty.charter

Create principles focused on code quality, testing standards,
user experience consistency, and performance requirements.

What this creates:

• .kittify/memory/charter.md - Your project's architectural DNA
• These principles will guide all subsequent development
• Missions do not have separate charters; the project charter is the single source of truth

Now begin the feature development cycle:

/spec-kitty.specify

Build a user authentication system with email/password login,
password reset, and session management. Users should be able to
register, login, logout, and recover forgotten passwords.

What this does:

• Creates kitty-specs/auth-system/spec.md with user stories and mints a canonical mission_id (ULID) in meta.json
• Enters discovery interview - Answer questions before continuing!
• All planning happens in the main repo (worktrees created later during implementation)

Note: Mission identity is a ULID (mission_id in meta.json). The three-digit numeric prefix (e.g. 001-auth-system) is display-only and is only assigned at merge time. Branches and worktrees use the mission's mid8 (first 8 chars of the ULID) for collision-free naming. See the mission identity migration runbook.

⚠️ Important: Continue in the same session - no need to change directories!

/spec-kitty.plan

Use Python FastAPI for backend, PostgreSQL for database,
JWT tokens for sessions, bcrypt for password hashing,
SendGrid for email delivery.

What this creates:

• kitty-specs/001-auth-system/plan.md - Technical architecture
• kitty-specs/001-auth-system/data-model.md - Database schema
• kitty-specs/001-auth-system/contracts/ - API specifications
• Enters planning interview - Answer architecture questions!

/spec-kitty.research

Investigate best practices for password reset token expiration,
JWT refresh token rotation, and rate limiting for auth endpoints.

What this creates:

• kitty-specs/001-auth-system/research.md - Research findings
• Evidence logs for decisions made

/spec-kitty.tasks

What this creates:

• kitty-specs/001-auth-system/tasks.md - Kanban checklist
• kitty-specs/001-auth-system/tasks/WP01.md - Work package prompts (flat structure)
• Up to 10 work packages ready for implementation

Check your dashboard: You'll now see tasks in the planned lane.

spec-kitty next --agent <agent> --mission <slug>

What this does:

• Returns the next action for the mission (implement, review, decide) based on current WP states
• Your agent invokes spec-kitty agent action implement <WP> --agent <name> per the returned action
• Each call advances the WP through planned → in_progress → for_review → approved
• Repeat until all work packages reach approved, then merge

Repeat until all work packages are done!

/spec-kitty.review

What this does:

• Auto-detects first WP with lane: "for_review" (or specify WP ID)
• Moves review execution to lane: "in_progress" (displayed as "Doing") and shows the prompt
• Agent reviews code and provides feedback or approval
• Shows commands to move to lane: "done" (passed) or lane: "planned" (changes needed)

/spec-kitty.accept

What this does:

• Verifies all WPs have lane: "done"
• Checks metadata and activity logs
• Confirms no NEEDS CLARIFICATION markers remain
• Records acceptance timestamp

/spec-kitty.merge --push

What this does:

• Switches to main branch
• Merges feature branch
• Pushes to remote (if --push specified)
• Cleans up worktree
• Deletes feature branch

🎉 Feature complete! Return to main repo and start your next feature with /spec-kitty.specify

1️⃣  /spec-kitty.charter     → In main repo (sets project principles)

2️⃣  /spec-kitty.specify          → Create spec (in main repo)
3️⃣  /spec-kitty.plan             → Define technical approach (in main repo)
4️⃣  /spec-kitty.tasks            → Generate work packages (in main repo)
5️⃣  spec-kitty next --agent <agent> --mission <slug>  → Agent loop: implement & review each WP
    spec-kitty agent action implement <WP> --agent <name>  → (per-WP: build the work package)
6️⃣  /spec-kitty.review           → Review completed work
7️⃣  /spec-kitty.accept           → Validate feature ready
8️⃣  /spec-kitty.merge            → Merge to main + cleanup

/spec-kitty.research   → After /plan: Investigate technical decisions
/spec-kitty.analyze    → After /tasks: Cross-artifact consistency check
/spec-kitty.checklist  → Anytime: Generate custom quality checklists
/spec-kitty.dashboard  → Anytime: Open/restart the kanban dashboard

Important: Agent directories (.claude/, .codex/, .gemini/, etc.) should NEVER be committed to git.

These directories may contain:

• Authentication tokens and API keys
• User-specific credentials (auth.json)
• Session data and conversation history

Spec Kitty automatically protects you with multiple layers:

During spec-kitty init:

• ✅ Adds supported agent directories to .gitignore
• ✅ Creates .claudeignore to optimize AI scanning (excludes .kittify/ templates)

Worktree Charter Sharing: When creating execution workspaces, Spec Kitty uses symlinks to share the charter:

.worktrees/my-feature-01J6XW9K-lane-a/.kittify/memory -> ../../../../.kittify/memory

This ensures all work packages follow the same project principles.

✅ DO commit:

• .kittify/templates/ - Command templates (source)
• .kittify/missions/ - Mission workflows
• .kittify/memory/charter.md - Project principles
• .gitignore - Protection rules

❌ NEVER commit:

• .claude/, .gemini/, .cursor/, etc. - Agent runtime directories
• Any auth.json or credentials files

See AGENTS.md for complete guidelines.

Learn from real-world workflows used by teams building production software with AI agents. Each playbook demonstrates specific coordination patterns and best practices:

• Multi-Agent Feature Development Coordinate 3-5 AI agents on a single large feature using an external orchestrator plus host API

• Parallel Implementation Tracking Monitor multiple teams/agents delivering features simultaneously with dashboard metrics

• Dashboard-Driven Development Product trio workflow: PM + Designer + Engineers using live kanban visibility

• Claude + Cursor Collaboration Blend different AI agents within a single spec-driven workflow

Browse our examples directory for additional workflows including:

• Agency client transparency workflows
• Solo developer productivity patterns
• Enterprise parallel development
• Research mission templates

Spec Kitty integrates with 14 AI tools. Thirteen tools receive project-local slash commands or prompt files written to an agent-specific directory (for example .claude/commands/ or .codex/prompts/). One tool — Mistral Vibe — uses the Agent Skills pipeline: Spec Kitty installs shared skills once under .agents/skills/spec-kitty.<command>/, and Vibe discovers them through project-local .vibe/config.toml skill_paths.

# Basic initialization in current directory (default)
spec-kitty init --ai claude

# Basic project initialization in a new directory
spec-kitty init my-project

# Initialize with specific AI assistant
spec-kitty init my-project --ai claude

# Initialize with Cursor support
spec-kitty init my-project --ai cursor

# Initialize with Windsurf support
spec-kitty init my-project --ai windsurf

# Initialize in current directory
spec-kitty init . --ai copilot

# Initialize multiple agents in one pass
spec-kitty init my-project --ai claude,codex

# Non-interactive setup for automation
spec-kitty init my-project --ai gemini --non-interactive

# Use a local template checkout during Spec Kitty development
SPEC_KITTY_TEMPLATE_ROOT=/path/to/spec-kitty spec-kitty init my-project --ai claude

# Check system requirements
spec-kitty verify-setup --diagnostics

# Upgrade to current version
spec-kitty upgrade

# Preview what would be changed
spec-kitty upgrade --dry-run

# Upgrade with detailed output
spec-kitty upgrade --verbose

# Upgrade to specific version
spec-kitty upgrade --target 0.6.5

# JSON output for scripting
spec-kitty upgrade --json

# Skip worktree upgrades
spec-kitty upgrade --no-worktrees

# Create mission (agent-friendly)
spec-kitty agent mission create "Payment Flow" --json

# Display WP prompt and auto-move to in_progress ("Doing")
spec-kitty agent action implement WP01 --agent __AGENT__

# Run workflow to advance lanes
spec-kitty agent action implement WP01 --agent __AGENT__

# Validate workflow
spec-kitty agent tasks validate-workflow WP01 --json

# Accept mission
spec-kitty agent mission accept --json

# Open dashboard (auto-detects port)
spec-kitty dashboard

# Open on specific port
spec-kitty dashboard --port 4000

# Stop dashboard
spec-kitty dashboard --kill

# Validate feature (auto-detect)
spec-kitty accept

# Validate specific mission
spec-kitty accept --mission 001-auth-system

# Get checklist only (no commit)
spec-kitty accept --mode checklist

# Accept with custom test validation
spec-kitty accept --test "pytest tests/" --test "npm run lint"

# JSON output for CI integration
spec-kitty accept --json

# Standard merge and push
spec-kitty merge --push

# Squash commits into one
spec-kitty merge --strategy squash --push

# Keep branch for reference
spec-kitty merge --keep-branch --push

# Preview merge without executing
spec-kitty merge --dry-run

# Merge to different target
spec-kitty merge --target develop --push

cd my-project
spec-kitty verify-setup

spec-kitty diagnostics

📖 Quick Start: See the Getting Started guide for practical examples of worktree usage in context.

Spec Kitty uses an opinionated swim-lane worktree model for parallel feature development. Think of each computed lane as a swim lane on the board: that swim lane owns one long-lived branch and one long-lived worktree, and sequential WPs stay in that swim lane instead of creating a fresh worktree per WP.

graph TD
    Main[main branch<br/>🔒 Clean production code]
    WT1[.worktrees/001-auth-lane-a<br/>🔐 Shared foundation swim lane]
    WT2[.worktrees/001-auth-lane-b<br/>💾 Parallel API swim lane]
    WT3[.worktrees/002-dashboard-lane-a<br/>📊 Dashboard swim lane]

    Main --> WT1
    Main --> WT2
    Main --> WT3

    WT1 -.->|🚀 Parallel work| WT2
    WT2 -.->|✅ No conflicts| WT3

    style Main fill:#e8f5e9
    style WT1 fill:#e1f5ff
    style WT2 fill:#fff3e0
    style WT3 fill:#f3e5f5

Why this works:

• Planning stays in the main checkout, so artifacts remain visible and auditable
• Sequential WPs in the same swim lane reuse the same worktree instead of spinning up a new one
• Independent swim lanes still run in parallel in separate directories with separate branches
• If task finalization computes one swim lane, the feature uses one worktree
• Main branch stays clean without manual git checkout juggling

my-project/                    # Main repo (main branch)
├── .worktrees/
│   ├── 001-auth-system-lane-a/  # Feature 1 swim lane A (shared by sequential WPs)
│   ├── 001-auth-system-lane-b/  # Feature 1 swim lane B (parallel work)
│   └── 002-dashboard-lane-a/    # Single-swim-lane feature
├── .kittify/
├── kitty-specs/
└── ... (main branch files)

1. Planning commands run in the primary repo root
2. Implementation branches live under .worktrees/
3. Trust the path printed by Spec Kitty instead of guessing the worktree name
4. Swim-lane features reuse .worktrees/<feature>-lane-<id> when multiple WPs share a swim lane
5. One computed swim lane means one worktree for the whole feature
6. Automatic cleanup removes swim-lane worktrees after merge

# ========== IN MAIN REPO ==========
/spec-kitty.charter     # Step 1: Establish project governance (one time per project)

# ========== PLAN IN MAIN REPO ==========
/spec-kitty.specify          # Step 2: Create the feature artifacts
/spec-kitty.plan             # Step 3: Design technical implementation
/spec-kitty.research         # Step 4 (as needed): Research technologies, patterns, etc.
/spec-kitty.tasks            # Step 5: Break plan into actionable tasks
/spec-kitty.analyze          # Step 6 (optional): Check cross-artifact consistency

# ========== RUN AGENT LOOP (implement + review each WP) ==========
spec-kitty next --agent <agent> --mission <slug>  # Step 7: Start the agent loop
# Your agent calls: spec-kitty agent action implement WP01 --agent <name>
# Then:            spec-kitty agent action review WP01 --agent <name>
# Repeat for each WP until all are done.

# ========== IN EXECUTION WORKSPACE ==========
# spec-kitty next handles dispatch to agent action implement/review for each WP
/spec-kitty.review           # Step 9: Review and refine completed work
/spec-kitty.accept           # Step 10: Acceptance checks & final metadata
/spec-kitty.merge --push     # Step 11: Merge to main + cleanup swim-lane worktrees

# ========== BACK IN MAIN REPO ==========
# Ready for next feature!

Spec Kitty supports missions: curated bundles of templates, commands, and guardrails for different domains. Two missions ship out of the box:

• Software Dev Kitty – the original Spec-Driven Development workflow for shipping application features (default).
• Deep Research Kitty – a methodology-focused workflow for evidence gathering, analysis, and synthesis.

Each mission lives under .kittify/missions/<mission-key>/ and provides:

• Mission-specific templates (spec-template.md, plan-template.md, tasks-template.md, etc.)
• Command guidance tuned to the domain (specify, plan, tasks, implement, review, accept)
• Optional charters to bias the agent toward best practices

Choose your mission during initialization:

# Select mission interactively
spec-kitty init my-project --ai claude

# Or specify mission directly
spec-kitty init my-project --ai claude --mission software-dev
spec-kitty init research-project --ai claude --mission research

After initialization, mission selection is recorded in project metadata:

# View active mission
spec-kitty mission current

# Project metadata
cat .kittify/metadata.yaml

Note: In current 2.x, missions are selected during spec-kitty init and remain active for the project lifecycle.

• Linux/macOS (or WSL2 on Windows)
• AI coding agent: Claude Code, GitHub Copilot, Gemini CLI, Cursor, Qwen CLI, opencode, Codex CLI, Mistral Vibe, Windsurf, or Kiro CLI (formerly Amazon Q Developer CLI)
• uv for package management
• Python 3.11+
• Git

If you encounter issues with an agent, please open an issue so we can refine the integration.

git checkout main
git pull origin main
git checkout -b release/vX.Y.Z

# Update pyproject.toml to a release version (example: X.Y.Z or X.Y.ZaN)
# Add CHANGELOG.md entry under: ## [X.Y.Z] - YYYY-MM-DD (or prerelease ## [X.Y.ZaN] - YYYY-MM-DD)

python scripts/release/validate_release.py --mode branch --tag-pattern "v*.*.*"
python -m pytest
python -m build
twine check dist/*
rm -rf dist/ build/

git add pyproject.toml CHANGELOG.md
git commit -m "chore(release): prepare X.Y.Z"
git push origin release/vX.Y.Z

git checkout main
git pull origin main
git tag vX.Y.Z -m "Release vX.Y.Z"
git push origin vX.Y.Z

git tag vX.Y.ZaN -m "Release vX.Y.ZaN"
git push origin vX.Y.ZaN

gh release view vX.Y.Z
python -m pip index versions spec-kitty-cli

git tag -d vX.Y.Z
git push origin :refs/tags/vX.Y.Z
git tag vX.Y.Z -m "Release vX.Y.Z"
git push origin vX.Y.Z

• Complete Spec-Driven Development Methodology - Deep dive into the full process
• Getting Started Guide - Step-by-step walkthrough from installation to feature completion

If you're contributing to Spec Kitty or working with the source code directly, you'll need to install it in development mode:

# Clone the repository
git clone https://github.com/Priivacy-ai/spec-kitty.git
cd spec-kitty

# Install in editable mode with development dependencies
pip install -e ".[test]"

# When running spec-kitty init, set the template root to your local checkout:
export SPEC_KITTY_TEMPLATE_ROOT=$(pwd)
spec-kitty init <PROJECT_NAME> --ai=claude

# Or use the --template-root flag directly (no env var needed):
spec-kitty init <PROJECT_NAME> --ai=claude --template-root=/path/to/spec-kitty

The CLI searches for templates in this order:

1. Packaged resources: Built-in templates from the installed spec-kitty-cli
2. Environment override: SPEC_KITTY_TEMPLATE_ROOT for local development or source checkouts
3. Remote repository: SPECIFY_TEMPLATE_REPO when you explicitly want a remote template source

For development installs from source, set SPEC_KITTY_TEMPLATE_ROOT to your checkout before running spec-kitty init.

# Reinstall the package
pip install --upgrade spec-kitty-cli

# Verify templates are bundled
python -c "from importlib.resources import files; print(files('specify_cli').joinpath('templates'))"

# Make sure you installed in editable mode from the repo root
cd /path/to/spec-kitty
pip install -e .

# Option 1: Use environment variable
export SPEC_KITTY_TEMPLATE_ROOT=$(pwd)
spec-kitty init my-project --ai=claude

# Option 2: Use --template-root flag (no env var needed)
spec-kitty init my-project --ai=claude --template-root=$(pwd)

# Option 3: Verify the path exists
ls -la ./templates/commands

export SPEC_KITTY_TEMPLATE_ROOT=/new/path/to/spec-kitty
spec-kitty init my-project --ai=claude

# Use --debug flag to see which paths were checked
spec-kitty init my-project --ai=claude --debug --template-root=/path/to/spec-kitty

#!/usr/bin/env bash
set -e
echo "Downloading Git Credential Manager v2.6.1..."
wget https://github.com/git-ecosystem/git-credential-manager/releases/download/v2.6.1/gcm-linux_amd64.2.6.1.deb
echo "Installing Git Credential Manager..."
sudo dpkg -i gcm-linux_amd64.2.6.1.deb
echo "Configuring Git to use GCM..."
git config --global credential.helper manager
echo "Cleaning up..."
rm gcm-linux_amd64.2.6.1.deb

0xCA11 💻	Adam Paterson 💻	Ahmet Çetinkaya 💻	Arifia Kasastra R 💻	Bitan Paul 💻	Brian Anderson 💻	Bruno Borges 💻
Dan Washusen 💻	Den Delimarsky 💻	Emanuel Turis 💻	Emre 💻	Faizan Khan 💻	Govind Kamtamneni 💻	Insik Han 💻
Jerome Lacube 💻	Korakot Chaovavanich 💻	LM 💻	Lucien 💻	Mark Beacom 💻	Maxi Ferreira 💻	Mingholy 💻
Minsu Lee 💻	Riya Amemiya 💻	Robert Douglass 💻 🎨 📖	Rodrigo D. L. 💻	Sascha Buehrle 💻	Shayne Boyer 💻	Stenyin 💻
Stijn Dejongh 💻	Tanner 💻	Thai Nguyen Hung 💻	Tine Kondo 💻	Zhiqiang ZHOU 💻	azuma 💻	danyow 💻
gaatjeniksaan 💻	np-yoe 💻	pluo 💻	pumakuma 💻	ramusbucket 💻	shyn 💻	y-yagi 💻
yamkazu 💻	本城博昭 💻

• Spec Kitty maintainers (contributors)

For support, please open a GitHub issue. We welcome bug reports, feature requests, and questions about using Spec-Driven Development.

This project is heavily influenced by and based on the work and research of John Lam.

This project is licensed under the terms of the MIT open source license. Please refer to the LICENSE file for the full terms.