Pre Release Check

pre-release-check

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

Steps

1. Run the five 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.

1. run-tests-and-linters -- lint, typecheck, and coverage at 90%.
2. 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.

1. check-docs -- README.md, docs/ nav, command accuracy, version refs.
2. 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 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

A release candidate (v-rc.) is cut from develop; a final release (v) 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 ..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-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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: lorem-dev
• Source: lorem-dev/skillkeeper
• License: Apache-2.0
• Homepage: https://lorem-dev.github.io/skillkeeper/

Install and usage instructions live in the source repository linked above.