Tagout

v2.5.0: the kit stops assuming it is the only host

Released 2026-09-12, a day after 2.4.0. Three features and twelve fixes, and the theme of all three features is that Claude Code is no longer the only place this kit runs.

What we were trying to fix

The routing table, the thing that says “broken test goes to debug-issue, a ready PR goes to merge-pr”, lived in a Claude Code specific rule file. Every other host (Codex, Copilot CLI, Gemini CLI, Antigravity, pi) either could not read it or needed its own hand written copy, and a hand written copy of a routing table is a copy that drifts. The same applied to installation: the kit was a plugin in one host’s format and a pile of instructions everywhere else.

What we decided

To make AGENTS.md the single home of the routing table (#525) and to generate each host’s rule file from it rather than maintaining six of them, and to ship real plugin manifests so the kit installs as a plugin on five more hosts (#526). The docs site grew an Install page and a Platforms page with a host picker to match. merge-pr also stopped polling CI in a loop and now waits in one wait-ci.sh call, then re-derives the verdict once (#521).

The twelve fixes are mostly gates catching the kit’s own bad habits: the write gate learned to deny a raw gh pr merge (#512) and to see through more bypass shapes in judge() (#533), the stop gate stopped reading a credential’s token as the host (#532), finish-task.sh stopped staging the whole worktree (#536), and every kit script learned to reach the repository’s own gh host rather than the default one (#514).

What got cut

The second tracker. Making the lifecycle skills work against GitLab and Azure DevOps means putting a contract behind roughly three hundred hard wired gh calls, and that was scoped into a chain of issues (#503 through #509) rather than rushed into this release. Archify, which would draw the architecture the migration phases can currently only describe in prose (#476), was also left open.

What bit us

The release path, in exactly the shape 2.3.1’s article had written down and 2.4.0’s article had to repeat. Tagging 2.5.0 moved the journal gate’s one release exemption forward, 2.4.0 had no article, and main went red on tests/skills/test.sh for every open pull request at once. The recovery was the documented one, and it cost a full session of diagnosis first, because a red kit check on a two line documentation PR looks like the PR’s fault and is not.

So this article was written while 2.5.1’s release pull request was still open, which is the rule 2.3.1 stated and the first time it has actually been followed. The lesson that survives three releases running is worth stating plainly: the gate is not the problem, the ordering is. A journal article is release work, not follow up work, and nothing in the release path asks for it, so it has to be written before the tag exists rather than after the gate goes red.