Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Understand how Spec Kitty manages git: what git operations Python handles automatically, what agents must do manually, worktree lifecycle, auto-commit behavior, merge execution, and the safe-commit pattern. Triggers: "how does spec-kitty use git", "worktree management", "auto-commit", "who commits what", "git workflow", "merge workflow", "rebase WPs", "worktree cleanup", "safe commit". Does NOT handle: runtime loop advancement (use runtime-next), setup or repair (use setup-doctor), mission selec
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-12 | ✗→✓ | ▲ Improved | 86% | 0% |
| case-04 | ✗→✓ | ▲ Improved | 127% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 140% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 138% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 30% | 0% |
Understand the boundary between what spec-kitty's Python code does with git and what LLM agents are expected to do. This boundary is critical — agents that try to create worktrees manually or skip implementation commits will break the workflow.
Python handles infrastructure git — worktrees, lane commits, merges, cleanup. Agents handle content git — implementation commits, rebases, conflict resolution.
| Git Operation | Who Does It | When | |---|---|---| | git worktree add | Python | spec-kitty implement WP## | | git commit (planning artifacts) | Python | Before worktree creation | | git commit (lane transitions) | Python | WP moves through claimed/in_progress/for_review/in_review | | git commit (implementation code) | Agent | After writing code in worktree | | git merge/auto-rebase (stale lane sync) | Python or Agent | When stale checks classify the lane as recoverable | | git merge (lane → mission → target) | Python | spec-kitty merge | | git push | Python (opt-in) | spec-kitty merge --push only | | git push | Agent | Any other push scenario | | Conflict resolution | Agent | During rebase or manual merge | | git worktree remove | Python | After successful merge | | git branch -d (cleanup) | Python | After successful merge |
When you run spec-kitty implement WP01, Python:
git worktree add -b kitty/mission-042-mission-lane-a .worktrees/042-mission-lane-a kitty/mission-042-missionIt also records the lane workspace context in .kittify/workspaces/<feature>-<lane>.json so later commands resolve the same lane worktree deterministically.
The agent never creates worktrees. Always use spec-kitty implement.
For dependent WPs in the same execution lane:
spec-kitty implement WP02This reuses the lane worktree instead of creating a second workspace:
# WP02 reuses .worktrees/042-mission-lane-aBefore creating a worktree, Python checks if kitty-specs/042-mission/ has uncommitted changes on the primary branch. If so, it commits through BookkeepingTransaction and safe_commit:
safe_commit(paths=["kitty-specs/042-mission/"], message="chore: Planning artifacts for 042-mission")Controlled by: auto_commit: true in .kittify/config.yaml (default: true). Can be disabled per-command with --no-auto-commit.
When a WP moves to doing or for_review, Python uses the safe-commit pattern to commit only the WP frontmatter file:
"chore: Start WP01 implementation [claude]""chore: Start WP01 review [claude]"The safe-commit pattern prevents accidentally committing agent work-in-progress:
emit_status_transition() appends to status.events.jsonl, updates status.json, and modifies WP frontmatter — but does NOT auto-commit these files. They accumulate as uncommitted changes until the next lane transition auto-commit or the agent commits them.
This is by design — status changes happen frequently and committing each one would create excessive git noise.
Run spec-kitty accept --mission 042-mission before merge once every WP is approved. Acceptance is a readiness nudge and artifact check; merge still owns the final mission-close transition.
spec-kitty merge --mission 042-mission runs the full merge sequence:
Python creates a detached merge worktree from the target branch, merges lane branches into the mission branch, merges the mission ref using the selected strategy, advances the target branch ref to the detached result, then removes merged lane worktrees and branches.
Merge order follows the dependency graph (topological sort).
Supports 3 strategies: squash (default), merge (--no-ff), rebase.
--push is opt-in — without it, the merge is local only.
Before merge, Python validates:
git status --porcelain)git rev-list --left-right --count)If any check fails, merge is blocked with specific error messages.
All actual code work must be committed by the agent. Python creates the worktree but never commits code:
bashcd .worktrees/042-mission-lane-a # ... write code, run tests ... git add src/ tests/ git commit -m "feat(WP01): implement auth middleware"
Validation: When the agent tries to move WP to for_review, spec-kitty checks that the worktree has commits ahead of the base branch (git rev-list --count <base>..HEAD). If zero commits, the transition is rejected.
If a lane branch has advanced while you were away:
bashcd .worktrees/042-mission-lane-a spec-kitty implement WP## --mission 042-mission
Let the stale-check and auto-merge classifier decide whether the lane can be refreshed automatically from the mission branch. Only perform a manual rebase when the CLI reports a conflict that requires agent resolution.
Python displays the lane workspace and branch, but the agent resolves conflicts and completes the rebase manually when needed.
Task finalization computes a lane that already contains the required dependency shape. Agents do not choose one dependency as a manual base and do not manually merge sibling lane outputs to reconstruct the lane.
spec-kitty merge only pushes with --push. All other pushing is the agent's responsibility.
If spec-kitty merge encounters conflicts, the agent must resolve them. Python does not attempt automatic conflict resolution.
yaml# .kittify/config.yaml auto_commit: true # default
When true, spec-kitty auto-commits:
When false, agents must commit everything manually.
Per-command override: --no-auto-commit flag on spec-kitty implement.
1. CREATED
spec-kitty implement WP01
→ git worktree add -b kitty/mission-042-mission-lane-a .worktrees/042-mission-lane-a kitty/mission-042-mission
→ .kittify/workspaces/042-mission-lane-a.json created
2. ACTIVE (agent works here)
cd .worktrees/042-mission-lane-a
→ agent writes code, commits, tests
→ WP status: in_progress
3. FOR REVIEW
spec-kitty agent tasks move-task WP01 --to for_review
→ auto-commit: "chore: Start WP01 review"
→ reviewer checks the diff
4. MERGED
spec-kitty accept --mission 042-mission
spec-kitty merge --mission 042-mission
→ detached merge worktree validates and advances target branch
→ git worktree remove .worktrees/042-mission-lane-a --force
→ git branch -d kitty/mission-042-mission-lane-a
→ .kittify/workspaces/042-mission-lane-a.json removed
5. CLEANED UP
Worktree directory gone, branch deleted, workspace context removedSpec Kitty installs a scoped commit-guard hook for managed workflows. Do not edit .git/hooks/ by hand; use the CLI repair path when hook state is stale.
git worktree add yourself.Use spec-kitty implement. Manual worktrees won't have workspace context, canonical workspace context, or proper branch naming.
commits belong in the worktree, not in the repository root checkout. The repository root checkout is for planning artifacts only.
the user explicitly requests it or when using spec-kitty merge --push.
to one WP. Don't modify files belonging to other WPs.
worktree has commits ahead of base before accepting the transition.
references/git-operations-matrix.md -- Complete matrix of every git command spec-kitty runsOther measured skills in the registry, with their headline benchmark lift.