npx skills add https://github.com/boshu2/agentops --skill release用途: 将项目从“代码就绪”状态推进到“已标记并准备推送”状态。
发布前验证、从 git 历史记录生成变更日志、跨包文件版本号提升、发布提交、带注释的标签以及精心整理的发布说明。所有操作均在本地且可逆。发布(包括 GitHub Release 页面)是 CI 的工作。
/release 1.7.0 # 完整发布:变更日志 + 版本提升 + 提交 + 标签
/release 1.7.0 --dry-run # 显示将要执行的操作,但不做任何更改
/release --check # 仅进行就绪性验证(GO/NO-GO)
/release # 基于提交分析建议版本号
| 参数 | 是否必需 | 描述 |
|---|---|---|
version | 否 | Semver 字符串(例如 1.7.0)。如果省略,则基于提交分析建议版本号 |
--check |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 否 |
| 仅进行就绪性验证 — 不生成或写入任何内容 |
--dry-run | 否 | 显示生成的变更日志和版本提升信息,但不写入 |
--skip-checks | 否 | 跳过发布前验证(测试、代码检查) |
--changelog-only | 否 | 仅更新 CHANGELOG.md — 不提升版本号、不提交、不打标签 |
/release [version] — 完整的本地发布工作流。
步骤:发布前检查 → 变更日志 → 发布说明 → 版本提升 → 用户审核 → 写入 → 发布提交 → 标签 → 指导。
/release --check — 独立的就绪性验证。
运行所有发布前检查并报告 GO/NO-GO。在开始发布前、在 CI 中作为门控步骤或与 /vibe 组合使用时很有用。不生成或写入任何内容。
/release 1.7.0 --changelog-only — 仅更新 CHANGELOG.md。
生成变更日志条目并写入。不提升版本号、不提交、不打标签。
首先运行以下检查:
./scripts/ci-local-release.sh # 必需的本地 CI 对等门控(阻塞性)
git rev-parse --git-dir # 必须在 git 仓库中
git status --porcelain # 如果工作区不干净则发出警告
git branch --show-current # 显示当前分支
/release 必须首先运行仓库根目录的 ci-local-release.sh 门控。如果失败,则停止发布工作流并报告失败的检查。本地 CI 门控将可发布的工件写入 .agents/releases/local-ci/<timestamp>/,包括 SBOM 文件和完整的安全扫描报告。
检查项:
| 检查项 | 方法 | 严重性 |
|---|---|---|
| Git 仓库 | git rev-parse --git-dir | 阻塞 — 无法继续 |
| CHANGELOG.md 存在 | 全局搜索变更日志(不区分大小写) | 如果缺失则提供创建选项 |
有 [Unreleased] 部分 | 读取 CHANGELOG.md | 警告 |
| 工作区干净 | git status --porcelain | 警告(显示未跟踪的文件) |
| 在预期分支上 | git branch --show-current | 如果不是 main/master/release 则警告 |
| 本地 CI 对等门控 | 仓库根目录 ci-local-release.sh | 阻塞 — 发布前必须通过 |
| 可发布的 SBOM | 由本地 CI 门控生成(CycloneDX + SPDX) | 阻塞 — 必需工件 |
| 安全扫描报告 | 由本地 CI 门控生成(完整工具链扫描 JSON) | 阻塞 — 必需工件 |
| 测试通过 | 检测并运行测试命令 | 警告(显示失败项) |
| 代码检查干净 | 检测并运行代码检查命令 | 警告(显示问题) |
| 版本一致性 | 比较跨包文件的版本 | 警告(显示不匹配项) |
| 清单版本同步 | 比较 .claude-plugin/plugin.json 和 marketplace.json 的版本 | 警告(显示不匹配项) |
| 自上次标签后的提交 | git log --oneline <range> | 如果为空则阻塞 — 没有内容可发布 |
| 发布节奏 | 检查上次标签日期与今天的对比 | 如果距离上次非安全发布 <7 天则警告(参见 references/release-cadence.md) |
| 未处理的高严重性发现 | 统计 .agents/rpi/next-work.jsonl 中 consumed=false 且 severity=high 的项目 | 警告 — 非阻塞项(参见下面的检查) |
未处理发现项检查(软警告,非阻塞):
if [ -f .agents/rpi/next-work.jsonl ] && command -v jq &>/dev/null; then
high_count=$(jq -s '[.[] | select(.consumed == false) | .items[] | select(.severity == "high")] | length' \
.agents/rpi/next-work.jsonl 2>/dev/null || echo 0)
if [ "$high_count" -gt 0 ]; then
echo "[WARN] $high_count unconsumed high-severity item(s) in .agents/rpi/next-work.jsonl"
echo " These carry-forward findings have not been addressed. Review before releasing."
echo " Run: jq -s '[.[] | select(.consumed==false) | .items[] | select(.severity==\"high\")]' .agents/rpi/next-work.jsonl"
fi
fi
这是一个软警告 — 它不会阻塞发布。它展示了之前回顾/事后分析会议的遗留发现项,以便发布工程师可以做出明智的决定。
测试/代码检查检测:
| 文件 | 测试命令 | 代码检查命令 |
|---|---|---|
go.mod | go test ./... | golangci-lint run(如果已安装) |
package.json | npm test | npm run lint(如果脚本存在) |
pyproject.toml | pytest | ruff check .(如果已安装) |
Cargo.toml | cargo test | cargo clippy(如果已安装) |
Makefile 包含 test: | make test | make lint(如果目标存在) |
如果传递了 --skip-checks,则仅跳过临时的测试/代码检查检测。它不会跳过仓库根目录的 ci-local-release.sh 门控。
在 --check 模式下,运行所有检查并输出摘要表:
Release Readiness: NO-GO
[PASS] Git repo
[PASS] CHANGELOG.md exists
[PASS] Working tree clean
[WARN] Branch: feature/foo (expected main)
[FAIL] Tests: 2 failures in auth_test.go
[PASS] Lint clean
[PASS] Version consistency (1.6.0 in all 2 files)
[PASS] 14 commits since v1.6.0
[WARN] 2 unconsumed high-severity item(s) in .agents/rpi/next-work.jsonl
在 --check 模式下,在此停止。在默认模式下,继续(警告不会阻塞)。
查找上次发布标签:
git tag --sort=-version:refname -l 'v*' | head -1
v* 标签,则使用第一个提交:git rev-list --max-parents=0 HEAD<last-tag>..HEAD收集用于分类的提交数据:
git log --oneline --no-merges <range>
git log --format="%H %s" --no-merges <range>
git diff --stat <range>
使用 --oneline 获取摘要视图,当提交信息不明确时使用完整哈希值进行详细查找。
将每个提交分类为以下四类之一:
| 类别 | 信号 |
|---|---|
| 新增 | 新功能、新文件、"add"、"create"、"implement"、"introduce"、feat |
| 变更 | 修改、更新、重构、"update"、"refactor"、"rename"、"migrate" |
| 修复 | 错误修复、更正、"fix"、"correct"、"resolve"、"patch" |
| 移除 | 删除、"remove"、"delete"、"drop"、"deprecate" |
分组规则:
auth:、api:、feat(users))git show --stat <hash> 读取差异以澄清关键规则:
### Removed--no-merges 过滤如果未提供版本号,则基于提交分类建议一个:
| 条件 | 建议 |
|---|---|
任何提交包含 "BREAKING"、"breaking change" 或 !:(约定式提交) | 主版本 提升 |
| 任何提交分类为新增(新功能) | 次版本 提升 |
| 仅修复/变更提交 | 修订版本 提升 |
显示建议及理由:
Suggested version: 1.7.0 (minor)
Reason: 3 new features added, no breaking changes
Current version: 1.6.0 (from package.json, go tags)
使用 AskUserQuestion 来确认或让用户提供不同的版本号。
以 Keep a Changelog 格式生成一个 Markdown 块:
## [X.Y.Z] - YYYY-MM-DD
### Added
- description of new feature
### Changed
- description of change
### Fixed
- description of fix
使用 YYYY-MM-DD 格式的当天日期。
风格适配: 读取现有的 CHANGELOG 条目并匹配其约定:
—、连字符 -、冒号 : )如果没有现有条目可参考(首次发布),则使用默认的 Keep a Changelog 格式。
扫描包含版本字符串的文件:
| 文件 | 模式 | 示例 |
|---|---|---|
package.json | "version": "X.Y.Z" | "version": "1.6.0" |
pyproject.toml | version = "X.Y.Z" | version = "1.6.0" |
Cargo.toml | version = "X.Y.Z" | version = "1.6.0" |
*.go | const Version = "X.Y.Z" 或 var version = "X.Y.Z" | const Version = "1.6.0" |
version.txt | 纯版本字符串 | 1.6.0 |
VERSION | 纯版本字符串 | 1.6.0 |
.goreleaser.yml | 来自 ldflags 的版本(显示,不修改 — goreleaser 从 git 标签读取) | — |
显示找到的内容:
Version strings detected:
package.json: "version": "1.6.0" → "1.7.0"
src/version.go: const Version = "1.6.0" → "1.7.0"
.goreleaser.yml: (reads from git tag — no change needed)
使用 AskUserQuestion:"更新这些版本字符串吗?" — "是的,全部更新" / "让我选择" / "跳过版本提升"
展示所有将要更改的内容:
如果传递了 --dry-run,则在此停止。
使用 AskUserQuestion:
用户确认后:
## [Unreleased] 行## [ 行或文件结尾)## [Unreleased] + 空行 + 版本条目暂存并提交所有发布更改:
git add CHANGELOG.md <version-files...>
git commit -m "Release v<version>"
提交信息有意保持简单。变更日志包含详细信息。
创建带注释的标签:
git tag -a v<version> -m "Release v<version>"
阅读 references/release-notes.md 以获取完整的发布说明格式、质量标准、压缩规则和示例。要点:
.agents/releases/YYYY-MM-DD-v<version>-notes.md请勿在本地创建 GitHub Release 草稿。 CI 中的 GoReleaser 是唯一的发布创建者。本地的 gh release create --draft 会与 GoReleaser 冲突,导致发布正文为空。
位于 .agents/releases/YYYY-MM-DD-v<version>-notes.md 的精心整理的发布说明已提交到仓库。CI 流水线(仓库根目录的 extract-release-notes.sh)读取它们并通过 --release-notes 传递给 GoReleaser。CI 还将安全工件发布到 GitHub Release 资源:
sbom-cyclonedx-go-mod.jsonsecurity-gate-summary.json告知用户:
Release notes written to .agents/releases/YYYY-MM-DD-v<version>-notes.md
CI will use these as highlights on the GitHub Release page.
CI will attach SBOM and security scan report assets.
向用户展示下一步操作:
Release v1.7.0 prepared locally.
Next steps:
git push origin main --tags # push commit + tag
CI publisher will handle: release publish, GitHub Release page, SBOM/security assets, provenance
(detected: .github/workflows/release.yml, .goreleaser.yml)
Curated release notes: .agents/releases/YYYY-MM-DD-v1.7.0-notes.md
如果未检测到 CI:
Next steps:
git push origin main --tags # push commit + tag
gh release create v1.7.0 --title "v1.7.0" --notes-file .agents/releases/YYYY-MM-DD-v1.7.0-notes.md
No release CI detected. Consider adding a workflow for automated publishing.
写入内部发布记录(与步骤 12 中编写的公共发布说明分开):
mkdir -p .agents/releases
写入 .agents/releases/YYYY-MM-DD-v<version>-audit.md:
# Release v<version> — Audit
**Date:** YYYY-MM-DD
**Previous:** v<previous-version>
**Commits:** N commits in range
## Version Bumps
<files updated>
## Pre-flight Results
<check summary table>
这是一个内部记录,用于知识飞轮。它不会出现在 GitHub Release 页面上 — 那是步骤 12 中的 -notes.md 文件。
两个文件,两个受众:
| 文件 | 受众 | 包含内容 |
|---|---|---|
*-notes.md | GitHub 动态阅读者 | 亮点、新功能、所有更改 |
*-audit.md | 内部/飞轮 | 版本提升、发布前检查结果 |
当 CHANGELOG.md 不存在且用户接受创建时,写入:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
然后继续正常的工作流程来填充第一个版本条目。
npm publish、cargo publish、twine upload。由 CI 处理。go build、npm pack、docker build。由 CI 处理。git push、git push --tags。由用户决定何时推送。此技能执行的所有操作都是本地且可逆的:
git reset HEAD~1git tag -d v<version>.agents/releases/*-notes.md用户输入: /release 1.7.0
执行过程:
结果: 本地发布完全准备就绪:变更日志已更新、版本已提升、标签已创建、发布草稿已准备。
用户输入: /release --check
执行过程:
结果: 仅发布就绪性报告,未做任何更改。
用户输入: /release(未提供版本号)
执行过程:
结果: 基于提交分析建议版本号,用户确认或覆盖。
| 问题 | 原因 | 解决方案 |
|---|---|---|
| "自上次标签后无提交"错误 | 工作区干净,无新提交 | 提交待处理的更改或跳过发布(无内容可发布) |
| 版本不匹配警告 | package.json 显示 1.6.0,go 显示 1.5.9 | 在发布前手动同步版本,或选择一个作为事实来源 |
| 发布前检查中测试失败 | 之前未发现的破坏性变更 | 修复失败的测试或使用 --skip-checks(不推荐) |
| 工作区不干净警告 | 存在未提交的更改 | 在发布前提交或暂存更改以保持干净状态 |
| GitHub Release 页面正文为空 | GoReleaser 与现有草稿发布冲突 | CI 工作流在 GoReleaser 运行前删除现有发布;请勿在本地执行 gh release create |
每周安装数
216
仓库
GitHub Stars
205
首次出现
2026年2月7日
安全审计
安装于
opencode215
codex211
github-copilot210
gemini-cli210
kimi-cli208
amp208
Purpose: Take a project from "code is ready" to "tagged and ready to push."
Pre-flight validation, changelog from git history, version bumps across package files, release commit, annotated tag, and curated release notes. Everything is local and reversible. Publishing (including the GitHub Release page) is CI's job.
/release 1.7.0 # full release: changelog + bump + commit + tag
/release 1.7.0 --dry-run # show what would happen, change nothing
/release --check # readiness validation only (GO/NO-GO)
/release # suggest version from commit analysis
| Argument | Required | Description |
|---|---|---|
version | No | Semver string (e.g., 1.7.0). If omitted, suggest based on commit analysis |
--check | No | Readiness validation only — don't generate or write anything |
--dry-run | No | Show generated changelog + version bumps without writing |
--skip-checks | No | Skip pre-flight validation (tests, lint) |
--changelog-only | No | Only update CHANGELOG.md — no version bumps, no commit, no tag |
/release [version] — the complete local release workflow.
Steps: pre-flight → changelog → release notes → version bump → user review → write → release commit → tag → guidance.
/release --check — standalone readiness validation.
Runs all pre-flight checks and reports GO/NO-GO. Useful before starting the release, in CI as a gate, or composed with /vibe. Does not generate or write anything.
/release 1.7.0 --changelog-only — just update CHANGELOG.md.
Generates the changelog entry and writes it. No version bumps, no commit, no tag.
Run these checks before anything else:
./scripts/ci-local-release.sh # mandatory local CI parity gate (blocking)
git rev-parse --git-dir # must be in a git repo
git status --porcelain # warn if dirty
git branch --show-current # show current branch
/release MUST run the repo-root ci-local-release.sh gate first. If it fails, stop the release workflow and report the failing checks. The local CI gate writes publishable artifacts to .agents/releases/local-ci/<timestamp>/, including SBOM files and a full security scan report.
Checks:
| Check | How | Severity |
|---|---|---|
| Git repo | git rev-parse --git-dir | Block — cannot proceed |
| CHANGELOG.md exists | Glob for changelog (case-insensitive) | Offer to create if missing |
Has [Unreleased] section | Read CHANGELOG.md | Warn |
| Working tree clean | git status --porcelain | Warn (show dirty files) |
| On expected branch | git branch --show-current | Warn if not main/master/release |
| Local CI parity gate |
Unconsumed findings check (soft WARN, non-blocking):
if [ -f .agents/rpi/next-work.jsonl ] && command -v jq &>/dev/null; then
high_count=$(jq -s '[.[] | select(.consumed == false) | .items[] | select(.severity == "high")] | length' \
.agents/rpi/next-work.jsonl 2>/dev/null || echo 0)
if [ "$high_count" -gt 0 ]; then
echo "[WARN] $high_count unconsumed high-severity item(s) in .agents/rpi/next-work.jsonl"
echo " These carry-forward findings have not been addressed. Review before releasing."
echo " Run: jq -s '[.[] | select(.consumed==false) | .items[] | select(.severity==\"high\")]' .agents/rpi/next-work.jsonl"
fi
fi
This is a soft WARN — it does not block the release. It surfaces carry-forward findings from prior retro/post-mortem sessions so the release engineer can make an informed decision.
Test/lint detection:
| File | Test Command | Lint Command |
|---|---|---|
go.mod | go test ./... | golangci-lint run (if installed) |
package.json | npm test | npm run lint (if script exists) |
pyproject.toml | pytest |
If --skip-checks is passed, skip ad-hoc test/lint detection only. It does not skip the repo-root ci-local-release.sh gate.
In --check mode, run all checks and output a summary table:
Release Readiness: NO-GO
[PASS] Git repo
[PASS] CHANGELOG.md exists
[PASS] Working tree clean
[WARN] Branch: feature/foo (expected main)
[FAIL] Tests: 2 failures in auth_test.go
[PASS] Lint clean
[PASS] Version consistency (1.6.0 in all 2 files)
[PASS] 14 commits since v1.6.0
[WARN] 2 unconsumed high-severity item(s) in .agents/rpi/next-work.jsonl
In --check mode, stop here. In default mode, continue (warnings don't block).
Find the last release tag:
git tag --sort=-version:refname -l 'v*' | head -1
v* tags exist, use the first commit: git rev-list --max-parents=0 HEAD<last-tag>..HEADGather commit data for classification:
git log --oneline --no-merges <range>
git log --format="%H %s" --no-merges <range>
git diff --stat <range>
Use --oneline for the summary view and full hashes for detail lookups when a commit message is ambiguous.
Classify each commit into one of four categories:
| Category | Signal |
|---|---|
| Added | New features, new files, "add", "create", "implement", "introduce", feat |
| Changed | Modifications, updates, refactors, "update", "refactor", "rename", "migrate" |
| Fixed | Bug fixes, corrections, "fix", "correct", "resolve", "patch" |
| Removed | Deletions, "remove", "delete", "drop", "deprecate" |
Grouping rules:
auth:, api:, feat(users))git show --stat <hash> to clarifyKey rules:
### Removed if nothing was removed--no-mergesIf no version was provided, suggest one based on the commit classification:
| Condition | Suggestion |
|---|---|
Any commit contains "BREAKING", "breaking change", or !: (conventional commits) | Major bump |
| Any commits classified as Added (new features) | Minor bump |
| Only Fixed/Changed commits | Patch bump |
Show the suggestion with reasoning:
Suggested version: 1.7.0 (minor)
Reason: 3 new features added, no breaking changes
Current version: 1.6.0 (from package.json, go tags)
Use AskUserQuestion to confirm or let the user provide a different version.
Produce a markdown block in Keep a Changelog format:
## [X.Y.Z] - YYYY-MM-DD
### Added
- description of new feature
### Changed
- description of change
### Fixed
- description of fix
Use today's date in YYYY-MM-DD format.
Style adaptation: Read the existing CHANGELOG entries and match their conventions:
—, hyphen -, colon : )If no existing entries to reference (first release), use plain Keep a Changelog defaults.
Scan for files containing version strings:
| File | Pattern | Example |
|---|---|---|
package.json | "version": "X.Y.Z" | "version": "1.6.0" |
pyproject.toml | version = "X.Y.Z" | version = "1.6.0" |
Cargo.toml | version = "X.Y.Z" |
Show what was found:
Version strings detected:
package.json: "version": "1.6.0" → "1.7.0"
src/version.go: const Version = "1.6.0" → "1.7.0"
.goreleaser.yml: (reads from git tag — no change needed)
Use AskUserQuestion: "Update these version strings?" — "Yes, update all" / "Let me choose" / "Skip version bumps"
Present everything that will change:
If --dry-run was passed, stop here.
Use AskUserQuestion:
After user confirms:
## [Unreleased] line## [ line or EOF)## [Unreleased] + blank line + versioned entryStage and commit all release changes together:
git add CHANGELOG.md <version-files...>
git commit -m "Release v<version>"
The commit message is intentionally simple. The changelog has the details.
Create an annotated tag:
git tag -a v<version> -m "Release v<version>"
Read references/release-notes.md for the full release notes format, quality bar, condensing rules, and examples. Key points:
.agents/releases/YYYY-MM-DD-v<version>-notes.mdDo NOT create a draft GitHub Release locally. GoReleaser in CI is the sole release creator. A local gh release create --draft conflicts with GoReleaser and results in an empty release body.
The curated release notes at .agents/releases/YYYY-MM-DD-v<version>-notes.md are committed to the repo. The CI pipeline (extract-release-notes.sh at repo root) reads them and passes them to GoReleaser via --release-notes. CI also publishes security artifacts to the GitHub Release assets:
sbom-cyclonedx-go-mod.jsonsecurity-gate-summary.jsonTell the user:
Release notes written to .agents/releases/YYYY-MM-DD-v<version>-notes.md
CI will use these as highlights on the GitHub Release page.
CI will attach SBOM and security scan report assets.
Show the user what to do next:
Release v1.7.0 prepared locally.
Next steps:
git push origin main --tags # push commit + tag
CI publisher will handle: release publish, GitHub Release page, SBOM/security assets, provenance
(detected: .github/workflows/release.yml, .goreleaser.yml)
Curated release notes: .agents/releases/YYYY-MM-DD-v1.7.0-notes.md
If no CI detected:
Next steps:
git push origin main --tags # push commit + tag
gh release create v1.7.0 --title "v1.7.0" --notes-file .agents/releases/YYYY-MM-DD-v1.7.0-notes.md
No release CI detected. Consider adding a workflow for automated publishing.
Write an internal release record (separate from the public release notes written in Step 12):
mkdir -p .agents/releases
Write to .agents/releases/YYYY-MM-DD-v<version>-audit.md:
# Release v<version> — Audit
**Date:** YYYY-MM-DD
**Previous:** v<previous-version>
**Commits:** N commits in range
## Version Bumps
<files updated>
## Pre-flight Results
<check summary table>
This is an internal record for the knowledge flywheel. It does NOT go on the GitHub Release page — that's the -notes.md file from Step 12.
Two files, two audiences:
| File | Audience | Contains |
|---|---|---|
*-notes.md | GitHub feed readers | Highlights, What's New, All Changes |
*-audit.md | Internal/flywheel | Version bumps, pre-flight results |
When no CHANGELOG.md exists and the user accepts creation, write:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
Then proceed with the normal workflow to populate the first versioned entry.
npm publish, cargo publish, twine upload. CI handles this.go build, npm pack, docker build. CI handles this.git push, no git push --tags. The user decides when to push.Everything this skill does is local and reversible:
git reset HEAD~1git tag -d v<version>.agents/releases/*-notes.md before pushUser says: /release 1.7.0
What happens:
Result: Local release fully prepared: changelog updated, versions bumped, tag created, draft release ready.
User says: /release --check
What happens:
Result: Release readiness report only, no changes made.
User says: /release (no version provided)
What happens:
Result: Suggested version based on commit analysis, user confirms or overrides.
| Problem | Cause | Solution |
|---|---|---|
| "No commits since last tag" error | Working tree clean, no new commits | Commit pending changes or skip release (nothing to release) |
| Version mismatch warning | package.json shows 1.6.0, go shows 1.5.9 | Manually sync versions before release, or choose one as source of truth |
| Tests fail during pre-flight | Breaking changes not caught earlier | Fix failing tests or use --skip-checks (not recommended) |
| Dirty working tree warning | Uncommitted changes present | Commit or stash changes before release for clean state |
| GitHub Release page has empty body | GoReleaser conflicts with existing draft release | CI workflow deletes existing releases before GoReleaser runs; do NOT gh release create locally |
Weekly Installs
216
Repository
GitHub Stars
205
First Seen
Feb 7, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode215
codex211
github-copilot210
gemini-cli210
kimi-cli208
amp208
Azure Data Explorer (Kusto) 查询技能:KQL数据分析、日志遥测与时间序列处理
102,600 周安装
Notion知识捕获插件:将对话内容自动转化为结构化文档,提升团队知识管理效率
251 周安装
Shopify开发技能 - 集成ClaudeKit的电商自动化与AI助手解决方案
251 周安装
Hono Cloudflare Workers 教程 - 构建边缘API与无服务器应用
252 周安装
阿里云OpenSearch向量检索版使用指南:Python SDK推送文档与HA/SQL搜索教程
252 周安装
模板引擎技能:自动化生成Word/Excel/PPT文档,支持Jinja2语法与批量邮件合并
252 周安装
Sentry代码审查指南:最佳实践、安全漏洞检测与性能优化清单
252 周安装
repo-root ci-local-release.sh |
| Block — must pass before release |
| Publishable SBOM | Generated by local CI gate (CycloneDX + SPDX) | Block — required artifact |
| Security scan report | Generated by local CI gate (full toolchain scan JSON) | Block — required artifact |
| Tests pass | Detect and run test command | Warn (show failures) |
| Lint clean | Detect and run lint command | Warn (show issues) |
| Version consistency | Compare versions across package files | Warn (show mismatches) |
| Manifest versions sync | Compare .claude-plugin/plugin.json and marketplace.json versions | Warn (show mismatches) |
| Commits since last tag | git log --oneline <range> | Block if empty — nothing to release |
| Release cadence | Check date of last tag vs today | Warn if <7 days since last non-security release (see references/release-cadence.md) |
| Unconsumed high-severity findings | Count items in .agents/rpi/next-work.jsonl where consumed=false and severity=high | Warn — not a blocker (see check below) |
ruff check . (if installed) |
Cargo.toml | cargo test | cargo clippy (if installed) |
Makefile with test: | make test | make lint (if target exists) |
version = "1.6.0" |
*.go | const Version = "X.Y.Z" or var version = "X.Y.Z" | const Version = "1.6.0" |
version.txt | Plain version string | 1.6.0 |
VERSION | Plain version string | 1.6.0 |
.goreleaser.yml | Version from ldflags (show, don't modify — goreleaser reads from git tags) | — |