feat: add /release skill for version assessment and release execution

[markshust]

Summary

Cutting a release has two judgment steps that .claude/release-process.md explicitly lists as manual, with no tooling behind them:

1. Audit labels on every PR merged since the last tag. .github/release.yml buckets PRs into release-notes sections by label; anything unlabeled silently lands in a generic "Other Changes" bucket, and nothing catches it before the tag is pushed.
2. Pick the version number. All 70 packages share it, and while in 0.x the patch-vs-minor call decides whether downstream projects can even resolve the release — Composer treats the minor as the breaking position below 1.0, so ^0.8.4 accepts 0.8.5 but refuses 0.9.0.

This adds a zero-argument /release skill that does the assessment and then gets out of the way.

What it does

• Step 1 — verifies preconditions (on develop, clean tree, in sync with origin, PHP 8.5, gh/jq present, something actually to release) and aborts with the specific failure rather than self-fixing.
• Step 2 — resolves every PR merged since the last tag from git log, reading title/body/labels rather than trusting commit subjects. Flags commits with no #NN reference, since bin/release.sh resolves notes by PR number and silently omits those.
• Step 3 — audits labels against every category in .github/release.yml, using the gh api REST endpoint (gh pr edit silently fails on this repo).
• Step 4 — classifies each PR into a tier (below), recommends a version including the Composer reachability tiebreak for a genuinely mixed batch, and says whether the release is urgent or worth deferring.
• Step 5 — presents PRs with labels and assigned tiers, label fixes, version + rationale, and what will happen — then stops. One approval gate; confirmation or an override both land here.
• Steps 6–7 — runs ./bin/release.sh <version> and reports the release URL plus the async split/Packagist follow-ups.

Labels route notes; they do not decide the version

Step 3 has the skill reading labels, and the enhancement bucket feeds a section titled "New Features" — close enough to a minor bump to invite the conflation. So Step 4 classifies each PR by what a consumer can actually observe after composer update, and only tier 3 forces a minor:

Tier	What it is	Effect on version
1	Never leaves the monorepo — .claude/, bin/, .github/, root tests/. Only packages/* is copied into split repos, so this cannot reach anyone's vendor/.	None, whatever the label
2	Ships in a package but adds no callable surface — CLI wording, docs, internal refactor	Patch
3	Adds or changes surface a consumer builds against — interface, method, config key, binding, command, package; or changes existing behavior	Minor

Tier 1 has a mechanical check rather than a judgment call — gh pr view <N> --json files returning zero packages/ paths proves it, which is the common shape for maintainer-facing enhancement PRs like this one.

The skill presents the assigned tier per PR, so a disagreement lands on one classification instead of the whole recommendation, and it states explicitly when an enhancement did not escalate the bump rather than leaving it ambiguous whether it was overlooked.

All mechanical work stays in bin/release.sh. The skill never hand-edits CHANGELOG.md (the script generates and commits it), never runs from a branch other than develop, and never narrows the test suite to get past a failure.

Structure follows the existing marko-skills plugin skills (name/description frontmatter, numbered steps, explicit guardrails), but lives in .claude/skills/ because this is maintainer-only tooling for the monorepo — not something to ship to Marko app developers.

Also included

• .claude/release-process.md — points at the skill from Cutting a Release, and documents the patch-vs-minor reachability rule under Versioning so it is authoritative rather than living only in the skill.
• CLAUDE.md — lists the skill alongside the other .claude/ configuration files.

Test plan

• tests/ReleaseSkillTest.php — 9 tests covering frontmatter discoverability, the zero-argument contract, the approval gate, the version-decision rules, the enhancement tier classification, delegation to bin/release.sh, and the precondition checks. Follows the content-assertion style of the existing ReleaseDocumentationTest.
• One test parses .github/release.yml and asserts the skill documents every category title and label, so adding a release-notes bucket without updating the skill fails the suite.
• composer test — 6870 passed (up from 6861)
• phpcs and php-cs-fixer --dry-run clean on tests/ReleaseSkillTest.php