jackin-release-check — Claude Code skill: release-readiness gates
Runs the jackin❯ release-readiness gates and reports a verdict for each one. Use it before cutting a release.
npx skills add jackin-project/jackin-dev --skill jackin-release-check -a claude-codeWhat jackin-release-check does
The skill walks the release-readiness gates in order. Every gate is binary: green passes, red blocks. A release is ready only when all gates are green, while warnings surface in the report and block nothing. The commands come from the repo itself — CONTRIBUTING.md and .github/workflows/ci.yml — never stripped-down substitutes.
There are seven gates. CI comes first: it reads the latest ci.yml run on main, and if docker/construct/** or docs/** changed since the last tag, it also requires construct.yml and docs.yml green. Static checks follow with cargo fmt --check and cargo clippy --all-targets --all-features -- -D warnings. Then tests: cargo nextest run --all-features plus a separate -p jackin --features e2e --profile docker-e2e run. The remaining gates walk internal links under docs/content/docs/, flag stale items in TODO.md and todo/, review SECURITY_EXCEPTIONS.md, and match every non-merge commit since the last tag to a merged PR.
One gate blocks until the operator confirms it: the SECURITY_EXCEPTIONS.md review stays red until each entry is confirmed current or the file is updated. The same applies to CI when docker/ or docs/ changed since the last tag — one ci.yml run is not enough. The skill fires only on an explicit request. Cutting the release itself is a different skill, jackin-release, which runs this one as its first gate.
What it helps with
- check whether the project is release-ready before tagging
- collect every gate verdict into a single report
- catch a red CI run or clippy failure before shipping
- find broken internal links in the docs tree
- clear out stale entries in the security exceptions list
Example prompts for the agent
- run jackin-release-check and show me the gate report
- jackin-release-check: is the project ready to release?
- run the release-readiness gates on the current branch
How to install jackin-release-check
1Skills CLI (Vercel)
npx skills add jackin-project/jackin-dev --skill jackin-release-check -a claude-code2Manually: put the files in place
~/.claude/skills/jackin-release-check/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/jackin-release-check/
1Skills CLI (Vercel)
npx skills add jackin-project/jackin-dev --skill jackin-release-check -a codex2Manually: put the files in place
.agents/skills/jackin-release-check/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add jackin-project/jackin-dev --skill jackin-release-check -a cursor2Manually: put the files in place
.cursor/skills/jackin-release-check/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install jackin-project/jackin-dev jackin-release-check2Manually: put the files in place
.github/skills/jackin-release-check/SKILL.md1Skills CLI (Vercel)
npx skills add jackin-project/jackin-dev --skill jackin-release-check -a gemini-cli2Platform CLI
gemini skills install https://github.com/jackin-project/jackin-dev --path skills/jackin-release-checkManually: put the files in place
.devin/skills/jackin-release-check/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add jackin-project/jackin-dev --skill jackin-release-check -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about jackin-release-check
How do I install jackin-release-check in Claude?
Run npx skills add jackin-project/jackin-dev --skill jackin-release-check -a claude-code. The skill lands at ~/.claude/skills/jackin-release-check/SKILL.md.
What does jackin-release-check do?
It runs seven release-readiness gates in order and gives each one a verdict: green, red, warn or skip. A red gate stops the release; a warning goes to the operator to accept or fix.
How is it different from jackin-release?
This skill only checks readiness. The release itself is handled by jackin-release, which runs jackin-release-check as its first gate.
Source text
SKILL.md · Apache-2.0
--- name: jackin-release-check description: Use only when the user explicitly requests this skill. Runs the jackin❯ release-readiness gates. argument-hint: "[context]" disable-model-invocation: true license: Apache-2.0 user-invocable: true --- # jackin-release-check Run the release-readiness **gates**. Each gate is binary — green passes, red blocks — and the release is ready only when every gate is green (warnings surface but do not block). The commands are the repo's own (from `CONTRIBUTING.md` merge-readiness + `.github/workflows/ci.yml`), never stripped-down substitutes. ## When to use - Before cutting a release, or when the operator asks whether the project is release-ready. ## When NOT to use - Cutting the release itself → `jackin-release` (it runs this skill as its first gate). ## Process Run each gate in order; collect a green / red / skip verdict into a one-line-per-gate report. 1. **CI gate.** `gh run list --workflow=ci.yml --branch=main --limit=1 --json conclusion --jq '.[0].conclusion'` — green only on `success`. If `docker/construct/**` or `docs/**` changed since the last tag (`git diff --name-only <last-tag>..HEAD -- <path>`), also require `construct.yml` / `docs.yml` green on main. *Done when* every CI workflow that owns a changed path is green. 2. **Static gates.** `cargo fmt --check`; `cargo clippy --all-targets --all-features -- -D warnings`. Red on any violation. *Done when* both exit 0. 3. **Test gate.** `cargo nextest run --all-features`; `cargo nextest run -p jackin --features e2e --profile docker-e2e`. Red on any failure. *Done when* both suites pass. 4. **Doc-link gate.** Walk internal links under `docs/content/docs/` (relative paths + `href`s); verify each target file exists. Red only on a broken link to a shipped page; warn on external URLs you cannot reach. *Done when* every internal link resolves. 5. **TODO freshness.** Read `TODO.md` and `todo/`; flag items referencing completed work or showing no recent activity. Warn — does not block. *Done when* every TODO item is either live or flagged stale. 6. **Security exceptions.** Read `SECURITY_EXCEPTIONS.md`; ask the operator whether each entry is still current. Review (blocks) until confirmed or the file is updated and re-read. *Done when* the operator confirms the catalog. 7. **Direct-commit audit.** `git log <last-tag>..HEAD --oneline --no-merges`; for each commit, `gh pr list --state merged --search "<sha>"`. Warn on commits with no PR — does not block. *Done when* every non-merge commit since the last tag is matched to a PR or listed as ungrouped. ## Report One line per gate: `✓` green, `✗` red (block), `⚠` warn, `-` skip. A red gate stops the release; a warn surfaces for the operator to accept or fix. ## Common mistakes - Running `cargo test --locked` or `cargo clippy -- -D warnings` (stripped flags) — those are not the repo's gates; the real commands carry `--all-targets --all-features` and use `nextest`. - Treating a warn as a block, or a red gate as a warn. - Skipping the path-specific CI workflows when `docker/` or `docs/` changed since the last tag. - Inventing a doc-link check instead of walking the real `docs/content/docs/` tree.
© jackin-project · Apache-2.0 · jackin-project/jackin-dev