You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Release: main has three merged PRs unpublished, and one question to settle first #16
main carries three merged PRs (#9, #11, #12) that are not in any release. The top-level version in .claude-plugin/marketplace.json is 2.1.0 and the latest tag is v2.1.0 —
equal, which scripts/check-version-sync reads as "released". So nothing is failing, and
nothing is published either.
What shipping this touches
Per CLAUDE.md, a plugin bump is three files at once, and a release is a fourth location:
.claude-plugin/marketplace.json — the plugin's entry
.claude-plugin/marketplace.json — the top-levelversion, plus a matching v* tag
Eighteen plugins are at 2.0.0 and pr-flow is at 2.1.0; every one of them changed: each description was
rewritten in #9, and the README blockquote, plugin.json and marketplace entry with it.
The question this issue exists to settle
Is a description rewrite a version bump? It changes no behaviour, but it is catalogue copy
— what /plugin shows and what the router matches on — and #9 showed it can change which
skill fires. Two defensible answers:
Yes, all nineteen to 2.1.0, top level to 2.2.0. The routing surface changed; a user
who reinstalls gets measurably different behaviour.
No, top level to 2.2.0 alone. Plugin versions track what the plugin does, and no
plugin does anything different. agent-smith, agent-ward, agent-hale, agent-ellis, sec-review and tenth-man would still bump, since their bodies changed.
The second is narrower and I would take it, but the call is the maintainer's and the checks
are satisfied either way.
Not blocked on
Nothing. This is a decision, not work waiting on #13, #14 or #15.
Reopening: this was closed by automation, not by being finished.
PR #17's body opened with Closes #16, except its last acceptance line — GitHub's linker reads
the first two words and ignores the qualifier, so the merge closed the issue at the same second
it landed. The qualifier was the operative part.
the question answered, and the answer recorded in CLAUDE.md
the chosen plugin versions bumped in all three locations each — seven plugins, not the six
this issue names in prose; agent-page's body changed in 0757a7b
the top-level version bumped, to 2.2.0
a matching v* tag pushed — deliberately not done; the maintainer holds this gate
make test and check-version-sync pass, with the marketplace version ahead of the tag,
which check-version-sync reads as release-pending
So one box is open and it is the one the issue's headline complaint depends on. Since #17 landed,
three further PRs (#18, #19, #20) have merged, which makes the unreleased pile bigger rather than
smaller — the second-order risk this issue named.
Current state of the release window: seventeen plugins at 2.1.0, briefing and shortcut at 2.0.0 (neither has phases, so #19 did not touch them), top level at 2.2.0, latest tag v2.1.0.
Still held, deliberately — the tag is not blocked on a defect
make eval was run on dab7767 and came back 8/13, exit 1. The maintainer chose not to tag
on that result, so v2.2.0 stays unpushed and this issue stays open.
Worth separating, because the red is easy to misread: make eval failing is not a release
blocker and was never a release gate. All four repo checks pass on main, and make eval sits
outside make test by design — it needs a credential, a network and money per run, and CI cannot
run it. Every one of the five failures is a routing gap that predates this work and that #14
deliberately left unfixed with a stated reason. None was introduced by the seven merged PRs.
The five are catalogued in #25, and the measurement problem behind them in #24 — the short version
being that the blind router this repo has judged descriptions with is a forced choice among 19
skills plus none, so its "skill A steals from skill B" verdicts overstate, where a real session
often invokes nothing at all.
Current release state
plugins at 2.1.0
17
plugins at 2.0.0
2 — briefing, shortcut; neither has phases, so #19 did not touch them
check-version-sync reads the marketplace version as ahead of the tag and treats that as
release-pending, so nothing fails; it simply stays unpublished.
This issue's headline complaint has therefore grown from three unreleased PRs to ten. That is the
cost of holding the gate, recorded rather than argued — the decision is the maintainer's, and the
tag command when it is wanted is git push GITHUB main v2.2.0.
15 since v2.1.0, 14 of them pull requests (#9 … #29)
plugin versions
17 at 2.1.0; briefing and shortcut at 2.0.0, having no phases to change
top-level version
2.2.0, now equal to the tag rather than ahead of it
pushed to
GITHUB and origin — both carry main and the tag
make test 4/4, scripts/check-version-sync passes with the tag matching the top-level
version rather than lagging it.
What this issue actually settled
Its headline complaint — three unreleased PRs — grew to fifteen while it was open, which was
the second-order risk it named. But the hold was the right call twice over, and both reasons
are worth keeping:
The question label was the real content. "Is a description rewrite a version bump?"
is answered and recorded in CLAUDE.md (Settle whether a description rewrite is a version bump, and publish what main already carries #17), so the next rewrite does not re-open it: a
bump tracks what a plugin does; catalogue copy alone moves the top-level version; and a
plugin moves at most once per release window, or the number stops naming a released state.
Activity
Merge: settle the version-bump rule, and stage 2.2.0 without tagging it
cmj0121 commentedon Sep 16, 2026
Reopening: this was closed by automation, not by being finished.
PR #17's body opened with
Closes #16, except its last acceptance line— GitHub's linker readsthe first two words and ignores the qualifier, so the merge closed the issue at the same second
it landed. The qualifier was the operative part.
What #17 actually did:
CLAUDE.mdthis issue names in prose;
agent-page's body changed in0757a7bversionbumped, to2.2.0v*tag pushed — deliberately not done; the maintainer holds this gatemake testandcheck-version-syncpass, with the marketplace version ahead of the tag,which
check-version-syncreads as release-pendingSo one box is open and it is the one the issue's headline complaint depends on. Since #17 landed,
three further PRs (#18, #19, #20) have merged, which makes the unreleased pile bigger rather than
smaller — the second-order risk this issue named.
Current state of the release window: seventeen plugins at
2.1.0,briefingandshortcutat2.0.0(neither has phases, so #19 did not touch them), top level at2.2.0, latest tagv2.1.0.cmj0121 commentedon Sep 16, 2026
Still held, deliberately — the tag is not blocked on a defect
make evalwas run ondab7767and came back 8/13, exit 1. The maintainer chose not to tagon that result, so
v2.2.0stays unpushed and this issue stays open.Worth separating, because the red is easy to misread:
make evalfailing is not a releaseblocker and was never a release gate. All four repo checks pass on
main, andmake evalsitsoutside
make testby design — it needs a credential, a network and money per run, and CI cannotrun it. Every one of the five failures is a routing gap that predates this work and that #14
deliberately left unfixed with a stated reason. None was introduced by the seven merged PRs.
The five are catalogued in #25, and the measurement problem behind them in #24 — the short version
being that the blind router this repo has judged descriptions with is a forced choice among 19
skills plus
none, so its "skill A steals from skill B" verdicts overstate, where a real sessionoften invokes nothing at all.
Current release state
2.1.02.0.0briefing,shortcut; neither has phases, so #19 did not touch themversion2.2.0v2.1.0maincheck-version-syncreads the marketplace version as ahead of the tag and treats that asrelease-pending, so nothing fails; it simply stays unpublished.
This issue's headline complaint has therefore grown from three unreleased PRs to ten. That is the
cost of holding the gate, recorded rather than argued — the decision is the maintainer's, and the
tag command when it is wanted is
git push GITHUB main v2.2.0.cmj0121 commentedon Sep 16, 2026
Released:
v2.2.0is tagged and publishedThe gate this issue was held open for is now closed by the maintainer, not by automation.
v2.2.0atce0aa0fv2.1.0, 14 of them pull requests (#9 … #29)2.1.0;briefingandshortcutat2.0.0, having no phases to changeversion2.2.0, now equal to the tag rather than ahead of itGITHUBandorigin— both carrymainand the tagmake test4/4,scripts/check-version-syncpasses with the tag matching the top-levelversion rather than lagging it.
What this issue actually settled
Its headline complaint — three unreleased PRs — grew to fifteen while it was open, which was
the second-order risk it named. But the hold was the right call twice over, and both reasons
are worth keeping:
questionlabel was the real content. "Is a description rewrite a version bump?"is answered and recorded in
CLAUDE.md(Settle whether a description rewrite is a version bump, and publish what main already carries #17), so the next rewrite does not re-open it: abump tracks what a plugin does; catalogue copy alone moves the top-level version; and a
plugin moves at most once per release window, or the number stops naming a released state.
make evalat 8/13 was correctly read as not a release blocker. All four repo checkspassed throughout. Every one of those five failures was a routing gap that predates this
work, catalogued in Five committed cases where no skill fires at all #25 with the measurement problem behind them in The blind router and make eval disagree, and the disagreement has a shape #24 — and Record when a skill should fire, and what each runner measures #26 has since
recorded the reading that explains four of them: a skill should not fire when the assistant
can simply comply in the current turn.
Also closed in this window
references/, ambiguity. Four items landed; two were answered bymeasuring rather than by doing, and the acceptance restated at the numbers the repo can hit.
declines, not backlog.
No open issues remain.