Pre Release Check

pre-release-check

Run the full release gate. All checks must pass before tagging a release.

Steps

1. Run the six component skills

Run each skill in order and collect its result (PASS or FAIL with details):

1. check-licenses -- must run first because a license failure is the most fundamental blocker.
2. run-tests-and-linters -- lint, typecheck, and coverage at 90%.
3. check-fixture-repo -- drive the built CLI against the examples/test-repo fixture end to end. This is the only check that exercises the real binary against a real working tree, so it catches wiring regressions the unit tests (which run against an in-memory filesystem) cannot see.
4. check-docs -- README.md, docs/ nav, command accuracy, version refs.
5. check-glibc-floor -- the Linux glibc floor agrees across the release workflow, scripts/install.sh, docs/, and the download labels, and the musl CLI is still published. Belongs in the release gate because the floor is set by the runner image the release itself builds on: a bumped image quietly invalidates every stated version, and a raised floor strands hosts that the self-updater will still offer the update to.
6. check-changes -- CHANGES.md Development section vs. commit history.

If check-licenses, run-tests-and-linters, or check-fixture-repo fails, report the failure and stop. The remaining checks can still be reported for completeness, but a release must not proceed while tests, licenses, or the end-to-end run are failing.

If the fixture submodule is not checked out, check-fixture-repo cannot run. Initialize it (git submodule update --init) rather than skipping the check -- a release must not ship without an end-to-end pass.

2. Verify the version bump

• Read version from the root package.json.
• Confirm the same version appears in all workspace package package.json files that ship to npm (i.e., under packages/).
• Confirm CHANGES.md has a ## Version <X.Y.Z> section that matches the version in package.json, OR that the developer has prepared the entry under ## Development and it is ready to be promoted.
• If versions are inconsistent across packages, list the discrepancies.

3. Verify the tag will be accepted from this branch

git branch --show-current
node scripts/check-tag-branch.mjs v<version>

A release candidate (v<version>-rc.<n>) is cut from develop; a final release (v<version>) is cut from main. Only RC tags may come from develop. The release pipeline enforces this in its first job, so checking here turns a failed release run into a one-second local answer.

If the intended tag is final and the current branch is develop, the release is not ready: merge to main first, or cut an RC instead.

4. Verify conventional-commits format for commits since the last release

git log --oneline <last-release-boundary>..HEAD

For each commit subject, verify:

• Starts with a valid type prefix: feat, fix, chore, docs, test, refactor, perf, ci, build, or release, optionally followed by (scope) and a colon.
• Subject is under 72 characters.
• Contains no AI-tool mentions (no "Co-Authored-By: Claude", "Co-Authored-By: Codex", "generated by", "with the help of AI", or similar).

Report each non-conforming commit with its hash and the specific violation.

5. Report

Produce a release-readiness summary:

check-licenses:            PASS / FAIL
run-tests-and-linters:     PASS / FAIL
check-fixture-repo:        PASS / FAIL
check-docs:                PASS / FAIL
check-glibc-floor:         PASS / FAIL
check-changes:             PASS / FAIL
tag provenance (branch):   PASS / FAIL
version bump consistent:   PASS / FAIL
conventional commits:      PASS / FAIL (N non-conforming commits)

Release gate: PASS / FAIL

If the gate is PASS, confirm: "All checks passed. The release may proceed." If the gate is FAIL, list every blocking issue with enough detail for the developer to act immediately. Do not tag or publish a release while any check is failing.