Skip to content

v0.10.0

Choose a tag to compare

@airiclenz airiclenz released this 23 Oct 16:46
· 231 commits to main since this release

capcom — v0.10.0 — 2026-10-23

Two commands now handle what agents do most: capcom start claims an Issue together with the Tree lock, and capcom finish closes it and frees the lock. capcom also keeps the Lock token for the session, so a lock survives a restart or compaction without anyone saving the token.

Breaking changes

  • The AGENTS.md Managed block has new instructions — after upgrading, capcom check and capcom agents --check report an existing Managed block as out of date, because the block now tells agents to claim work with capcom start <id> and close it with capcom finish <id> --reason <text>, and no longer asks them to keep the Lock token. What to do: run capcom agents once to rewrite the block.

New

  • capcom start <id> — claims a Ready Issue and this worktree's Tree lock in one step, printing the Issue in full and the Lock token; running it again on the same Issue resumes your lock without changing anything. It refuses an Issue that is Closed, standing, not Ready or already in doing without your lock, and a lock another session holds (exit code 3), writing nothing and naming the command that fixes each case.
  • capcom finish <id> --reason <text> — closes an Issue, frees the Tree lock using the token capcom start kept (or a --token you give), and ends with the next Ready Issue to pick up (or "nothing is ready to work on"). Add --keep-lock to hold on to the lock; if no token holds the lock, the Issue is still closed and the output says why the lock was left alone and points to capcom lock status.
  • Lock tokens are no longer lost — capcom lock acquire --purpose <text> keeps the Lock token for the session, so running the same command again, even after a restart, compaction or a stale lock, resumes your lock and prints the token again. A --token you pass is used instead, capcom lock release and capcom lock break clean up the kept tokens, and a lock held by another session still fails with exit code 3.

Improved

  • capcom prime gives simpler lock advice — the this worktree: lines now suggest capcom start <id> for issue work and, for a held or stale lock, tell you to run the same acquire or start again to resume it, instead of asking you to keep a token.
  • Renaming the doing status keeps the Managed block current — changing the name of your doing status in config.yaml no longer makes capcom check report the Managed block as out of date.

Fixed

  • The Claude Code plugin's Briefing no longer goes silent by mistake — a settings file that only mentions capcom prime, for example in a permission rule, used to stop the plugin from printing the Briefing at session start. Now the plugin steps aside only when a hook runs exactly capcom prime, as capcom init --claude-hooks sets up.

Docs & install

  • Guides teach the start-and-finish workflow — the README, the manual, llms.txt and the plugin's capcom skill now claim work with capcom start and close it with capcom finish, explain that running start or acquire again resumes the lock, and describe the Lock token as a shared signal between agents rather than a secret. The skill falls back to the older commands when the installed capcom has no start, and the tree-locks guide has a new section on the kept token.
  • Output and plugin docs corrected — the README and capcom --help now say that every command except capcom ui takes --json, and that capcom help and capcom completion ignore it. The --kv reference points to each command's own page and notes that warnings come before every record, and the README and plugin skill now say the plugin also runs capcom prime before compaction.