# Pre Release Check

> Gate a release by running check-changes, check-docs, run-tests-and-linters, check-licenses, check-fixture-repo, and check-glibc-floor, plus verifying the version bump and that all commits since the last release follow the conventional-commits format.

- Skill: `lorem-dev/pre-release-check` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lorem-dev/pre-release-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lorem-dev/pre-release-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lorem-dev (https://skillmd.com/u/lorem-dev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lorem-dev/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

```bash
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

```bash
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.