К основному содержанию
скилл CX Codex

jackin-release-check — скилл для Claude Code: проверка готовности

Прогоняет релизные гейты проекта jackin❯ и выдаёт отчёт по каждому. Нужен перед выпуском версии, когда надо понять, всё ли зелёное.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add jackin-project/jackin-dev --skill jackin-release-check -a claude-code
Открыть на GitHub

Что делает jackin-release-check

Скилл запускает проверки готовности к релизу по порядку. Каждый гейт бинарный: зелёный пропускает, красный блокирует. Релиз считается готовым, только если все гейты зелёные, а предупреждения просто всплывают в отчёте и ничего не останавливают. Команды берутся из самого репозитория — из CONTRIBUTING.md и .github/workflows/ci.yml, без урезанных замен.

Гейтов семь. Сначала CI: проверяется последний прогон ci.yml на main, а если с прошлого тега менялись docker/construct/** или docs/**, то ещё и construct.yml с docs.yml. Дальше статика — cargo fmt --check и cargo clippy --all-targets --all-features -- -D warnings. Потом тесты через cargo nextest run --all-features и отдельный прогон -p jackin --features e2e --profile docker-e2e. Ещё проверяются внутренние ссылки в docs/content/docs/, свежесть задач в TODO.md и todo/, записи в SECURITY_EXCEPTIONS.md и наличие PR у коммитов после последнего тега.

Важная деталь: гейт по SECURITY_EXCEPTIONS.md блокирует, пока оператор не подтвердит, что каждая запись ещё актуальна. То же с CI — если менялись docker/ или docs/, нельзя ограничиваться одним ci.yml. Скилл вызывается только по явной просьбе, сам он не сработает. Для выпуска версии есть отдельный jackin-release, который запускает этот скилл первым гейтом.

Какие задачи решает

  • проверить, готов ли проект к релизу, до нарезки тега
  • собрать отчёт по всем релизным гейтам в одном месте
  • поймать красный CI или clippy до выпуска
  • найти битые внутренние ссылки в документации
  • отсеять устаревшие записи в списке исключений безопасности

Примеры запросов агенту

  • прогони jackin-release-check и покажи отчёт по гейтам
  • jackin-release-check: готов ли проект к релизу?
  • запусти проверку готовности релиза для текущей ветки

Как установить jackin-release-check

1Через Skills CLI (Vercel)

npx skills add jackin-project/jackin-dev --skill jackin-release-check -a claude-code

2Вручную: положить файлы

~/.claude/skills/jackin-release-check/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/jackin-release-check/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Вопросы о jackin-release-check

Как установить jackin-release-check в Claude?

Выполните npx skills add jackin-project/jackin-dev --skill jackin-release-check -a claude-code. Скилл окажется в ~/.claude/skills/jackin-release-check/SKILL.md.

Что делает jackin-release-check?

Прогоняет семь релизных гейтов по порядку и выдаёт по каждому вердикт: зелёный, красный, предупреждение или пропуск. Красный гейт останавливает релиз, предупреждение выносится оператору на решение.

Чем отличается от jackin-release?

Этот скилл только проверяет готовность. Сам выпуск версии делает jackin-release, и он запускает jackin-release-check своим первым гейтом.

Исходный текст

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

Похожие скиллы

Всё по теме «DevOps и инфраструктура» →
re0-release LilMGenius Проводит готовое изменение по чек-листу релиза репозитория, а потом по подтверждению ставит тег и публикует. Запускается вручную, когда вы решили выпускать. CX Codex +1 1 200установок release cyrusagents Скилл проводит релиз Cyrus CLI через trusted-publishing: подготовка, проверка, публикация и финал. Пригодится, когда нужно выпустить версию, не трогая пакеты руками. CX Codex +1 829установок goal-release dyoshikawa Ведёт релиз целиком: открывает PR, ждёт зелёный CI, мержит и обновляет формулу Homebrew. Пригодится, когда версию надо выпустить одной командой. CX Codex +1 ★ 1 552звёзд репо cargo-workflows mohitmishra786 Скилл ведёт агента по воркспейсам Cargo, фичам, build.rs, кэшу сборки и аудиту зависимостей. Пригодится, когда Rust-проект разрастается до нескольких крейтов. CX Codex +1 558установок release-skills JimLiu Автоматизирует подготовку релизов, анализ коммитов и обновление версий в проектах на Node.js, Python или Rust. Сгенерирует ченджлог и создаст GitHub Release. CX Codex +1 25 600установок cmux-release manaflow-ai Автоматизирует подготовку релизов cmux: собирает журнал изменений из пулл-реквестов и обновляет версии проекта. CX Codex +1 4 700установок

Из того же набора2

Спонсоры проекта

Компании, которые помогают держать аналитику открытой