release-skills

Release Skills

通用发布工作流，支持任何项目类型及多语言变更日志。

用户输入工具

当此技能提示用户时，请遵循以下工具选择规则（优先级顺序）：

优先使用当前代理运行时暴露的内置用户输入工具——例如 AskUserQuestion、request_user_input、clarify、ask_user 或任何等效工具。
回退：如果不存在此类工具，则发出编号的纯文本消息，并请用户回复每个问题的编号/答案。
批处理：如果工具支持单次调用多个问题，则将所有适用问题合并为一次调用；如果仅支持单个问题，则按优先级顺序逐一询问。

以下具体的 AskUserQuestion 引用仅为示例——在其他运行时中请替换为本地等效工具。

快速开始

直接运行 /release-skills - 自动检测您的项目配置。

支持的项目类型

项目类型	版本文件	自动检测
Node.js	package.json	✓
Python	pyproject.toml	✓
Rust	Cargo.toml	✓
Claude 插件	marketplace.json	✓
通用项目	VERSION / version.txt	✓

选项

标志	描述
`--dry-run`	预览更改而不执行
`--major`	强制主版本号升级
`--minor`	强制次版本号升级
`--patch`	强制补丁版本号升级
`--backfill-releases`	根据变更日志章节为现有标签创建缺失的 GitHub Releases

工作流

步骤 1：检测项目配置

检查 .releaserc.yml（可选配置覆盖）
- 如果存在，检查是否定义了 release hooks
按优先级顺序自动检测版本文件：
- package.json（Node.js）
- pyproject.toml（Python）
- Cargo.toml（Rust）
- marketplace.json 或 .claude-plugin/marketplace.json（Claude 插件）
- VERSION 或 version.txt（通用项目）
使用 glob 模式扫描变更日志文件：
- CHANGELOG*.md
- HISTORY*.md
- CHANGES*.md
通过文件名后缀识别每个变更日志的语言
检测 GitHub Release 支持：
- 检查 origin 是否指向 GitHub
- 检查 gh 是否已安装并认证
- 如果可用，使用 gh release list --limit 5 检查现有 releases
显示检测到的配置

项目 Hook 契约：

如果 .releaserc.yml 定义了 release.hooks，则保持发布工作流通用，并将项目特定的打包/发布委托给这些 hooks。

支持的 hooks：

Hook	目的	预期职责
`prepare_artifact`	使一个目标可发布	验证目标自包含，同步/嵌入本地依赖，可选地暂存额外文件
`publish_artifact`	发布一个可发布目标	上传准备好的目标（或如果项目使用暂存目录则上传该目录），附加版本/变更日志/标签

支持的占位符：

占位符	含义
`{project_root}`	仓库根目录的绝对路径
`{target}`	正在发布的模块/技能的绝对路径
`{artifact_dir}`	该目标的临时暂存目录的绝对路径（如果项目使用）
`{version}`	发布工作流选择的版本
`{dry_run}`	`true` 或 `false`
`{release_notes_file}`	包含发布说明/变更日志文本的 UTF-8 文件的绝对路径

执行规则：

保持技能通用：不要在此 SKILL 中硬编码注册表/包管理器/项目布局细节。
如果存在 prepare_artifact，则在需要最终可发布目标状态的发布相关检查之前，为每个目标运行一次。
将发布说明写入临时文件，并将该文件路径传递给 publish_artifact；不要将多行变更日志文本内联到 shell 命令中。
如果 hooks 不存在，则回退到默认的与项目无关的发布工作流。

语言检测规则：

变更日志文件遵循模式 CHANGELOG_{LANG}.md 或 CHANGELOG.{lang}.md，其中 {lang} / {LANG} 是语言或区域代码。

模式	示例	语言
无后缀	`CHANGELOG.md`	en（默认）
`_{LANG}`（大写）	`CHANGELOG_CN.md`, `CHANGELOG_JP.md`	对应语言
`.{lang}`（小写）	`CHANGELOG.zh.md`, `CHANGELOG.ja.md`	对应语言
`.{lang-region}`	`CHANGELOG.zh-CN.md`	对应区域变体

常见语言代码：zh（中文）、ja（日文）、ko（韩文）、de（德文）、fr（法文）、es（西班牙文）。

输出示例：

检测到项目：
  版本文件：package.json (1.2.3)
  变更日志：
    - CHANGELOG.md (en)
    - CHANGELOG.zh.md (zh)
    - CHANGELOG.ja.md (ja)

步骤 2：分析自上次标签以来的变更

LAST_TAG=$(git tag --sort=-v:refname | head -1)
git log ${LAST_TAG}..HEAD --oneline
git diff ${LAST_TAG}..HEAD --stat

按常规提交类型分类：

类型	描述
feat	新功能
fix	错误修复
docs	文档
refactor	代码重构
perf	性能改进
test	测试
style	格式、样式
chore	维护（在变更日志中跳过）

破坏性变更检测：

提交消息以 BREAKING CHANGE 开头
提交正文/页脚包含 BREAKING CHANGE:
删除了公共 API、重命名了导出、更改了接口

如果检测到破坏性变更，警告用户：“检测到破坏性变更。考虑主版本号升级（--major 标志）。”

步骤 3：确定版本升级

规则（按优先级顺序）：

用户标志 --major/--minor/--patch → 使用指定的
检测到 BREAKING CHANGE → 主版本升级（1.x.x → 2.0.0）
存在 feat: 提交 → 次版本升级（1.2.x → 1.3.0）
否则 → 补丁升级（1.2.3 → 1.2.4）

显示版本变更：1.2.3 → 1.3.0

步骤 4：生成多语言变更日志

对于每个检测到的变更日志文件：

从文件名后缀识别语言
检测第三方贡献者：
- 检查合并提交：git log ${LAST_TAG}..HEAD --merges --pretty=format:"%H %s"
- 对于每个合并的 PR，通过 gh pr view <number> --json author --jq '.author.login' 识别 PR 作者
- 与仓库所有者比较（gh repo view --json owner --jq '.owner.login'）
- 如果 PR 作者 ≠ 仓库所有者 → 第三方贡献者
以该语言生成内容：
- 章节标题使用目标语言
- 变更描述以目标语言自然书写（非翻译）
- 日期格式：YYYY-MM-DD（通用）
- 第三方贡献：在变更日志条目后附加贡献者归属 (by @username)
插入到文件头部（保留现有内容）

章节标题翻译（内置）：

类型	en	zh	ja	ko	de	fr	es
feat	Features	新功能	新機能	새로운 기능	Funktionen	Fonctionnalités	Características
fix	Fixes	修复	修正	수정	Fehlerbehebungen	Corrections	Correcciones
docs	Documentation	文档	ドキュメント	문서	Dokumentation	Documentation	Documentación
refactor	Refactor	重构	リファクタリング	리팩토링	Refactoring	Refactorisation	Refactorización
perf	Performance	性能优化	パフォーマンス	성능	Leistung	Performance	Rendimiento
breaking	Breaking Changes	破坏性变更	破壊的変更	주요 변경사항	Breaking Changes	Changements majeurs	Cambios importantes

变更日志格式：

## {VERSION} - {YYYY-MM-DD}

### Features
- 新功能描述
- 第三方贡献描述 (by @username)

### Fixes
- 修复描述

### Documentation
- 文档变更描述

仅包含有变更的章节。省略空章节。

第三方归属规则：

仅对非仓库所有者的贡献者添加 (by @username)
使用带有 @ 前缀的 GitHub 用户名
放置在变更日志条目行的末尾
对所有语言一致应用（始终使用 (by @username) 格式，不翻译）

多语言示例：

英文（CHANGELOG.md）：

## 1.3.0 - 2026-01-22

### Features
- Add user authentication module (by @contributor1)
- Support OAuth2 login

### Fixes
- Fix memory leak in connection pool

中文（CHANGELOG.zh.md）：

## 1.3.0 - 2026-01-22

### 新功能
- 新增用户认证模块 (by @contributor1)
- 支持 OAuth2 登录

### 修复
- 修复连接池内存泄漏问题

日文（CHANGELOG.ja.md）：

## 1.3.0 - 2026-01-22

### 新機能
- ユーザー認証モジュールを追加 (by @contributor1)
- OAuth2 ログインをサポート

### 修正
- コネクションプールのメモリリークを修正

步骤 5：按技能/模块分组变更

分析自上次标签以来的提交，并按受影响的技能/模块分组：

识别每个提交更改的文件
按技能/模块分组：
- skills/<skill-name>/* → 归入该技能下
- 根文件（CLAUDE.md 等）→ 归为“project”
- 一个提交中的多个技能 → 拆分为多个组
对于每个组，识别需要更新的相关 README

分组示例：

baoyu-cover-image:
  - feat: add new style options
  - fix: handle transparent backgrounds
  → README 更新：选项表

baoyu-comic:
  - refactor: improve panel layout algorithm
  → 无需 README 更新

project:
  - docs: update CLAUDE.md architecture section

步骤 6：分别提交每个技能/模块

对于每个技能/模块组（按变更顺序）：

检查需要更新的 README：
- 扫描 README*.md 中提及此技能/模块的内容
- 验证选项/标志是否正确记录
- 如果语法更改，更新使用示例
- 如果行为更改，更新功能描述

暂存并提交：

git add skills/<skill-name>/*
git add README.md README.zh.md  # 如果为此技能更新
git commit -m "<type>(<skill-name>): <meaningful description>"

提交消息格式：
- 使用常规提交格式：<type>(<scope>): <description>
- <type>：feat, fix, refactor, docs, perf 等
- <scope>：技能名称或“project”
- <description>：清晰、有意义的变更描述

提交示例：

git commit -m "feat(baoyu-cover-image): add watercolor and minimalist styles"
git commit -m "fix(baoyu-comic): improve panel layout for long dialogues"
git commit -m "docs(project): update architecture documentation"

常见 README 更新需求：

变更类型	需要检查的 README 章节
新选项/标志	选项表、使用示例
重命名选项	选项表、使用示例
新功能	功能描述、示例
破坏性变更	迁移说明、弃用警告
内部重构	架构章节（如果对用户公开）

步骤 7：生成变更日志并更新版本

生成多语言变更日志（如步骤 4 所述）
更新版本文件：
- 读取版本文件（JSON/TOML/文本）
- 更新版本号
- 写回（保留格式）
创建发布说明文件：
- 优先使用 CHANGELOG.md 中的新版本章节
- 如果不存在英文/默认变更日志，则使用第一个检测到的变更日志
- 仅提取从 ## {VERSION} - {YYYY-MM-DD} 到下一个 ## 的精确章节
- 根据需要匹配纯版本和带标签前缀的标题，例如 1.2.3 和 v1.2.3
- 将破坏性变更放在顶部附近；如果需要，在其他章节之前添加简短高亮
- 将说明写入 UTF-8 临时文件，并复用于带注释标签消息、GitHub Releases 和 publish_artifact
- 在正常模式下，如果找不到说明，则停止而不是创建空标签或 GitHub Release

按文件类型的版本路径：

文件	路径
package.json	`$.version`
pyproject.toml	`project.version`
Cargo.toml	`package.version`
marketplace.json	`$.metadata.version`
VERSION / version.txt	直接内容

步骤 8：用户确认

在创建发布提交之前，请用户确认：

使用 AskUserQuestion 提出三个问题：

版本升级（单选）：
- 显示基于步骤 3 分析的建议版本
- 选项：建议版本（带标签）、其他 semver 选项
- 示例：1.2.3 → 1.3.0 (Recommended)、1.2.3 → 1.2.4、1.2.3 → 2.0.0
推送到远程（单选）：
- 选项：“是，提交后推送”、“否，仅保留本地”
发布 GitHub Release（单选）：
- 仅在 GitHub release 支持可用时提供此选项
- 当用户也选择推送时，默认选择“是，标签推送后发布”
- 如果用户保留本地发布，则不创建或编辑 GitHub Release

确认前输出示例：

已创建提交：
  1. feat(baoyu-cover-image): add watercolor and minimalist styles
  2. fix(baoyu-comic): improve panel layout for long dialogues
  3. docs(project): update architecture documentation

变更日志预览（en）：
  ## 1.3.0 - 2026-01-22
  ### Features
  - Add watercolor and minimalist styles to cover-image
  ### Fixes
  - Improve panel layout for long dialogues in comic

发布说明来源：CHANGELOG.md#1.3.0
准备创建发布提交、带注释标签和 GitHub Release。

步骤 9：创建发布提交和带注释标签

用户确认后：

暂存版本和变更日志文件：

git add <version-file>
git add CHANGELOG*.md

创建发布提交：

git commit -m "chore: release v{VERSION}"

创建带注释标签：
```
git tag -a v{VERSION} -F <release-notes-file>
```
如果 .releaserc.yml 设置了 tag.sign: true，则使用相同的说明文件执行 git tag -s。

如果用户确认则推送（步骤 8）：

git push origin main
git push origin v{VERSION}

注意：不要添加 Co-Authored-By 行。这是发布提交，不是代码贡献。

步骤 10：发布 Release 工件和 GitHub Release

项目工件发布和 GitHub Releases 是独立的输出：

项目工件：
- 如果存在 release.hooks.publish_artifact，则为每个准备好的目标运行一次
- 传递与标签和 GitHub Release 相同的 {release_notes_file}
- 在 dry-run 模式下，传递 {dry_run}=true 并报告将要发布的内容

GitHub Release：

仅在用户确认远程发布且 GitHub 支持可用时运行
确保标签在创建 release 之前已存在于远程

使用提取的说明创建或更新：

if gh release view v{VERSION} >/dev/null 2>&1; then
  gh release edit v{VERSION} --title "v{VERSION}" --notes-file <release-notes-file>
else
  gh release create v{VERSION} --title "v{VERSION}" --notes-file <release-notes-file> --verify-tag
fi

切勿将多行发布说明内联到 shell 命令中

发布后输出：

Release v1.3.0 已创建。

提交：
  1. feat(baoyu-cover-image): add watercolor and minimalist styles
  2. fix(baoyu-comic): improve panel layout for long dialogues
  3. docs(project): update architecture documentation
  4. chore: release v1.3.0

标签：v1.3.0
标签类型：带注释
GitHub Release：已发布  # 或“已跳过/仅本地”
状态：已推送到 origin  # 或“仅本地 - 准备就绪时运行 git push”

回填现有 GitHub Releases

当用户要求回填历史 releases 或传递 --backfill-releases 时使用此模式。

不要升级版本、编辑变更日志或创建发布提交。
按版本顺序列出现有标签并检测缺失的 releases：
```
git tag --sort=v:refname
gh release view <tag>
```
对于每个没有 GitHub Release 的标签：
- 通过去除配置的标签前缀来规范化变更日志查找，例如 v1.2.3 -> 1.2.3
- 从 CHANGELOG.md 中提取匹配的章节；回退到第一个匹配的变更日志文件
- 如果不存在匹配的变更日志章节，则跳过或在发布前询问
- 使用以下命令创建 release：
```
gh release create <tag> --title "<tag>" --notes-file <release-notes-file> --verify-tag
```
使用 git cat-file -t <tag> 检测轻量标签（commit 表示轻量，tag 表示带注释）。
默认情况下不要重写公共轻量标签。将现有远程标签转换为带注释标签需要明确的用户确认，因为这会重写已发布的引用。

配置 (.releaserc.yml)

项目根目录中的可选配置文件，用于覆盖默认值：

# .releaserc.yml - 可选配置

# 版本文件（如果未指定则自动检测）
version:
  file: package.json
  path: $.version  # JSON 使用 JSONPath，TOML 使用点路径

# 变更日志文件（如果未指定则自动检测）
changelog:
  files:
    - path: CHANGELOG.md
      lang: en
    - path: CHANGELOG.zh.md
      lang: zh
    - path: CHANGELOG.ja.md
      lang: ja

  # 章节映射（常规提交类型 → 变更日志章节）
  # 使用 null 在变更日志中跳过该类型
  sections:
    feat: Features
    fix: Fixes
    docs: Documentation
    refactor: Refactor
    perf: Performance
    test: Tests
    chore: null

# 提交消息格式
commit:
  message: "chore: release v{version}"

# 标签格式
tag:
  prefix: v  # 结果为 v1.0.0
  sign: false

# 包含在发布提交中的额外文件
include:
  - README.md
  - package.json

Dry-Run 模式

当指定 --dry-run 时：

=== DRY RUN 模式 ===

检测到项目：
  版本文件：package.json (1.2.3)
  变更日志：CHANGELOG.md (en), CHANGELOG.zh.md (zh)

上次标签：v1.2.3
建议版本：v1.3.0

按技能/模块分组的变更：
  baoyu-cover-image:
    - feat: add watercolor style
    - feat: add minimalist style
    → 提交：feat(baoyu-cover-image): add watercolor and minimalist styles
    → README 更新：选项表

  baoyu-comic:
    - fix: panel layout for long dialogues
    → 提交：fix(baoyu-comic): improve panel layout for long dialogues
    → 无需 README 更新

变更日志预览（en）：
  ## 1.3.0 - 2026-01-22
  ### Features
  - Add watercolor and minimalist styles to cover-image
  ### Fixes
  - Improve panel layout for long dialogues in comic

变更日志预览（zh）：
  ## 1.3.0 - 2026-01-22
  ### 新功能
  - 为 cover-image 添加水彩和极简风格
  ### 修复
  - 改进 comic 长对话的面板布局

将要创建的提交：
  1. feat(baoyu-cover-image): add watercolor and minimalist styles
  2. fix(baoyu-comic): improve panel layout for long dialogues
  3. chore: release v1.3.0

未做任何更改。不带 --dry-run 运行以执行。

使用示例

/release-skills              # 自动检测版本升级
/release-skills --dry-run    # 仅预览
/release-skills --minor      # 强制次版本升级
/release-skills --patch      # 强制补丁升级
/release-skills --major      # 强制主版本升级（需确认）
/release-skills --backfill-releases  # 为现有标签创建缺失的 GitHub Releases

何时使用

当用户请求以下内容时触发此技能：

"release", "发布", "create release", "new version", "新版本"
"bump version", "update version", "更新版本"
"prepare release"
"release notes", "GitHub Release", "回填 Release"
"push to remote"（有未提交的更改）

重要：如果用户说“just push”或“直接 push”且有未提交的更改，仍然先执行上述所有步骤。

你可能还喜欢

pm-skills

24Kagent-workflows

Use when coordinating project-delivery work across the 8 project-management sub-skills — sprint/velocity analytics, portfolio health, Jira/JQL, Confluence, Atlassian admin, templates, meeting analysis, team comms. Triggers on 'our sprints feel off', 'project health report', 'audit our Jira permissions', 'when will it be done', 'run the delivery loop'. Forks context to route to one sub-skill via a deterministic signal router and returns a digest; can also drive a full goal→plan→execute→verify→close delivery loop through the repo-wide agent-harness with Jira MCP data bridged into the domain's analytics tools. Distinct from product-team (what to build vs how to deliver it), business-operations (internal ops), and engineering/agent-harness (the generic loop engine this orchestrator plugs into).

alirezarezvani

获取

planning-with-files-es

25Kagent-workflows

基于文件的类Manus规划系统，用于组织和跟踪复杂任务的进度。创建 task_plan.md、findings.md 和 progress.md。当用户请求规划、分解或多步骤项目组织、研究任务或需要超过5次工具调用的工作时使用。支持 /clear 后的自动会话恢复。关键词：任务规划、项目规划、创建工作计划、分析任务、组织项目、进度跟踪、多步骤规划、帮我规划、分解项目