Repository navigation
v0.10.0
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 checkandcapcom agents --checkreport an existing Managed block as out of date, because the block now tells agents to claim work withcapcom start <id>and close it withcapcom finish <id> --reason <text>, and no longer asks them to keep the Lock token. What to do: runcapcom agentsonce 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 tokencapcom startkept (or a--tokenyou give), and ends with the next Ready Issue to pick up (or "nothing is ready to work on"). Add--keep-lockto 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 tocapcom 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--tokenyou pass is used instead,capcom lock releaseandcapcom lock breakclean up the kept tokens, and a lock held by another session still fails with exit code 3.
Improved
capcom primegives simpler lock advice — thethis worktree:lines now suggestcapcom 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.yamlno longer makescapcom checkreport 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 exactlycapcom prime, ascapcom init --claude-hookssets up.
Docs & install
- Guides teach the start-and-finish workflow — the README, the manual,
llms.txtand the plugin'scapcomskill now claim work withcapcom startand close it withcapcom 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 installedcapcomhas nostart, and the tree-locks guide has a new section on the kept token. - Output and plugin docs corrected — the README and
capcom --helpnow say that every command exceptcapcom uitakes--json, and thatcapcom helpandcapcom completionignore it. The--kvreference 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 runscapcom primebefore compaction.