release

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/release - Release Management Agent

/release - 版本发布管理Agent

Command Flags

命令参数

FlagShortDescription
--help
-h
Show available commands and options
--version
-v
Show workflow skills version
auto
Auto-determine version from task types
patch
Force patch increment
minor
Force minor increment
major
Force major increment
参数缩写描述
--help
-h
显示可用命令和选项
--version
-v
显示工作流技能版本
auto
根据任务类型自动确定版本
patch
强制补丁版本递增
minor
强制次版本递增
major
强制主版本递增

Flag Handling

参数处理

On
-h
or
--help
:
/release - Release Management Agent

Usage:
  /release                           Auto-determine version (recommended)
  /release auto                      Same as above
  /release patch                     Force patch bump (v1.0.0 → v1.0.1)
  /release minor                     Force minor bump (v1.0.0 → v1.1.0)
  /release major                     Force major bump (v1.0.0 → v2.0.0)
  /release v1.2.3                    Explicit version
  /release -h, --help                Show this help message
  /release -v, --version             Show version

Version Auto-Detection:
  - Reads "Version Impact" from each task document
  - Any major → major bump
  - Any minor → minor bump
  - All patch → patch bump

Creates:
  - CHANGELOG.md entry
  - Git tag
  - GitHub Release

Examples:
  /release                           # Auto-detect version
  /release minor                     # Force minor bump
  /release v2.0.0                    # Explicit version
On
-v
or
--version
:
Display:
Workflow Skills v1.5.1
https://github.com/eljun/workflow-skills

当使用
-h
--help
时:
/release - 版本发布管理Agent

用法:
  /release                           自动确定版本(推荐)
  /release auto                      同上
  /release patch                     强制补丁版本升级(v1.0.0 → v1.0.1)
  /release minor                     强制次版本升级(v1.0.0 → v1.1.0)
  /release major                     强制主版本升级(v1.0.0 → v2.0.0)
  /release v1.2.3                    指定明确版本
  /release -h, --help                显示此帮助信息
  /release -v, --version             显示版本

版本自动检测:
  - 从每个任务文档中读取「版本影响」
  - 存在主版本影响则升级主版本
  - 存在次版本影响且无主版本影响则升级次版本
  - 所有项均为补丁影响则升级补丁版本

生成内容:
  - CHANGELOG.md条目
  - Git标签
  - GitHub Release

示例:
  /release                           # 从任务文档自动确定版本(推荐)
  /release minor                     # 强制次版本升级
  /release v2.0.0                    # 使用明确版本
当使用
-v
--version
时:
显示内容:
Workflow Skills v1.5.1
https://github.com/eljun/workflow-skills

When to Use

使用时机

Invoke
/release
when:
  • Multiple features/fixes have been merged via
    /ship
  • Items are in "Ready to Ship" section of TASKS.md
  • Ready to create a versioned release
Examples:
bash
/release             # Auto-determine version from task docs (RECOMMENDED)
/release auto        # Same as above - auto-determine
/release patch       # Force patch increment (v1.1.21 → v1.1.22)
/release minor       # Force minor increment (v1.1.21 → v1.2.0)
/release major       # Force major increment (v1.1.21 → v2.0.0)
/release v1.1.22     # Explicit version
在以下场景调用
/release
  • 多个功能/修复已通过
    /ship
    合并
  • 项位于TASKS.md的「待发布」区域
  • 准备创建版本化发布
示例:
bash
/release             # 从任务文档自动确定版本(推荐)
/release auto        # 同上 - 自动确定版本
/release patch       # 强制补丁版本递增(v1.1.21 → v1.1.22)
/release minor       # 强制次版本递增(v1.1.21 → v1.2.0)
/release major       # 强制主版本递增(v1.1.21 → v2.0.0)
/release v1.1.22     # 使用明确版本

Workflow

工作流

/release [version|auto]
1. Get current version from git tags
2. Read "Ready to Ship" items from TASKS.md
3. Filter: Only include items with "Merged" status (✅)
4. Read each task document for Type & Version Impact
5. Auto-calculate version (if not explicit)
   ├── Any major → major bump
   ├── Any minor → minor bump
   └── All patch → patch bump
6. Categorize changes by type
7. Generate changelog entry
8. Update CHANGELOG.md
9. Commit changelog
10. Create git tag
11. Push to remote
12. Create GitHub Release
13. Move ONLY merged items to "Shipped" with release version
Release complete!
IMPORTANT: Only items with "Merged" status (✅) in "Ready to Ship" are included in the release. Unmerged PRs stay in "Ready to Ship" for the next release.
/release [version|auto]
1. 从git标签获取当前版本
2. 从TASKS.md读取「待发布」项
3. 过滤:仅包含「已合并」状态的项(✅)
4. 读取每个任务文档的类型与版本影响
5. 自动计算版本(若未指定明确版本)
   ├── 存在主版本影响 → 升级主版本
   ├── 存在次版本影响且无主版本影响 → 升级次版本
   └── 所有项均为补丁影响 → 升级补丁版本
6. 按类型分类变更
7. 生成变更日志条目
8. 更新CHANGELOG.md
9. 提交变更日志
10. 创建git标签
11. 推送到远程仓库
12. 创建GitHub Release
13. 仅将已合并项移至「已发布」区域并标记发布版本
发布完成!
重要提示: 仅「待发布」区域中标记为「已合并」(✅)的项会被包含在发布中。未合并的PR将留在「待发布」区域用于下一次发布。

Pre-Release Checklist

发布前检查清单

Before running
/release
:
  • All PRs in "Ready to Ship" are merged
  • Main branch is up to date (
    git pull
    )
  • No uncommitted changes (
    git status
    )
  • All tests passing
运行
/release
前请确认:
  • 「待发布」区域中的所有PR均已合并
  • 主分支已更新(
    git pull
  • 无未提交的变更(
    git status
  • 所有测试均已通过

Step-by-Step Process

分步流程

Step 1: Get Current Version

步骤1:获取当前版本

bash
undefined
bash
undefined

Get the latest tag

获取最新标签

git describe --tags --abbrev=0 2>/dev/null || echo "v0.0.0"
git describe --tags --abbrev=0 2>/dev/null || echo "v0.0.0"

List recent tags for context

列出最近的标签以作参考

git tag --list --sort=-v:refname | head -5
undefined
git tag --list --sort=-v:refname | head -5
undefined

Step 2: Determine New Version

步骤2:确定新版本

If explicit version provided:
bash
/release v1.1.22
若指定明确版本:
bash
/release v1.1.22

Use v1.1.22 directly

直接使用v1.1.22版本


**If semantic increment provided:**
```bash
/release patch  # v1.1.21 → v1.1.22
/release minor  # v1.1.21 → v1.2.0
/release major  # v1.1.21 → v2.0.0
Version parsing logic:
Current: v1.1.21
         │ │ │
         │ │ └── Patch (bug fixes, small changes)
         │ └──── Minor (new features, backwards compatible)
         └────── Major (breaking changes)

**若指定语义化版本递增:**
```bash
/release patch  # v1.1.21 → v1.1.22
/release minor  # v1.1.21 → v1.2.0
/release major  # v1.1.21 → v2.0.0
版本解析逻辑:
当前版本: v1.1.21
         │ │ │
         │ │ └── 补丁版本(bug修复、小变更)
         │ └──── 次版本(新功能、向后兼容)
         └────── 主版本(破坏性变更)

Step 3: Auto-Calculate Version (Recommended)

步骤3:自动计算版本(推荐)

When using
/release
or
/release auto
, read each task document to determine version:
Read Version Impact from task docs:
markdown
> **Type:** feature
> **Version Impact:** minor  ← Use this field
Auto-calculation logic:
Ready to Ship items:
├── feature-1      → Version Impact: minor
├── bug-fix-1      → Version Impact: patch
└── enhancement-1  → Version Impact: patch

Highest impact = minor
Current version = v1.2.0
New version = v1.3.0
Priority order:
  1. major
    (any major = major bump)
  2. minor
    (any minor, no major = minor bump)
  3. patch
    (all patch = patch bump)
Fallback if Version Impact missing:
  • Use Type field to infer:
    • feature
      minor
    • bugfix
      patch
    • enhancement
      patch
    • documentation
      patch
    • chore
      patch
使用
/release
/release auto
时,将读取每个任务文档以确定版本:
从任务文档读取版本影响:
markdown
> **类型:** feature
> **版本影响:** minor  ← 使用此字段
自动计算逻辑:
待发布项:
├── feature-1      → 版本影响: minor
├── bug-fix-1      → 版本影响: patch
└── enhancement-1  → 版本影响: patch

最高影响级别 = minor
当前版本 = v1.2.0
新版本 = v1.3.0
优先级顺序:
  1. major
    (任何主版本影响 → 升级主版本)
  2. minor
    (存在次版本影响且无主版本影响 → 升级次版本)
  3. patch
    (所有项均为补丁影响 → 升级补丁版本)
若版本影响字段缺失的 fallback 逻辑:
  • 使用类型字段推断:
    • feature
      minor
    • bugfix
      patch
    • enhancement
      patch
    • documentation
      patch
    • chore
      patch

Step 4: Read "Ready to Ship" Items (Merged Only)

步骤4:读取「待发布」项(仅已合并)

Parse TASKS.md for items in "Ready to Ship" section. Only include items with Merged = ✅:
markdown
undefined
解析TASKS.md的「待发布」区域。仅包含合并状态为✅的项
markdown
undefined

Ready to Ship

待发布

TaskBranchPRMergedTask Doc
Quick Actions Redesignfeature/quick-actions#123✅ Jan 25link
Session Fixfix/session-persist#124✅ Jan 25link
New Featurefeature/new#125Nolink

**Filter logic:**
- `✅` or date in Merged column → Include in release
- `No` or empty in Merged column → Skip (not ready)
任务分支PR已合并任务文档
快捷操作重设计feature/quick-actions#123✅ 1月25日链接
会话修复fix/session-persist#124✅ 1月25日链接
新功能feature/new#125链接

**过滤逻辑:**
- 「已合并」列包含✅或日期 → 包含在发布中
- 「已合并」列为「否」或空 → 跳过(未就绪)

Step 4: Categorize Changes

步骤4:分类变更

Read each task document to get the
Type
field:
TypeChangelog Section
feature
New Features
bugfix
Bug Fixes
enhancement
Enhancements
documentation
Documentation
chore
Other Changes
Task document type field:
markdown
> **Status:** SHIPPED
> **Type:** feature
读取每个任务文档的「类型」字段:
类型变更日志章节
feature
新功能
bugfix
Bug修复
enhancement
功能增强
documentation
文档更新
chore
其他变更
任务文档类型字段示例:
markdown
> **状态:** SHIPPED
> **类型:** feature

Step 5: Generate Changelog Entry

步骤5:生成变更日志条目

Create formatted entry:
markdown
undefined
创建格式化条目:
markdown
undefined

[v1.1.22] - January 26, 2026

[v1.1.22] - 2026年1月26日

New Features

新功能

  • Web: Dashboard redesign with new widgets (#123)
  • Web: 仪表板重设计,新增小部件 (#123)

Bug Fixes

Bug修复

  • Fixed session persistence on embed chat (#124)
  • 修复嵌入聊天的会话持久化问题 (#124)

Enhancements

功能增强

  • Improved booking calendar performance (#125)
  • 提升预订日历性能 (#125)

Documentation

文档更新

  • Updated authentication guide (#126)
undefined
  • 更新认证指南 (#126)
undefined

Step 6: Update CHANGELOG.md

步骤6:更新CHANGELOG.md

Location:
docs/changelogs/CHANGELOG.md
Insert new version at the top (after header):
markdown
undefined
文件位置:
docs/changelogs/CHANGELOG.md
在顶部(标题后)插入新版本:
markdown
undefined

Changelog

变更日志

All notable changes to this project.
本项目所有重要变更记录。

[v1.1.22] - January 26, 2026

[v1.1.22] - 2026年1月26日

← INSERT HERE
← 插入此处

New Features

新功能

...

...

[v1.1.21] - January 20, 2026

[v1.1.21] - 2026年1月20日

...

**If CHANGELOG.md doesn't exist, create it:**

```markdown
...

**若CHANGELOG.md不存在,则创建:**

```markdown

Changelog

变更日志

All notable changes to this project.
Format based on Keep a Changelog.

本项目所有重要变更记录。
格式基于 Keep a Changelog

[v1.1.22] - January 26, 2026

[v1.1.22] - 2026年1月26日

New Features

新功能

...
undefined
...
undefined

Step 7: Commit Changelog

步骤7:提交变更日志

bash
git add docs/changelogs/CHANGELOG.md
git commit -m "chore(release): v1.1.22

Release v1.1.22 with:
- Quick Actions grid redesign
- Session persistence fix
- [other items...]

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"
bash
git add docs/changelogs/CHANGELOG.md
git commit -m "chore(release): v1.1.22

发布v1.1.22,包含:
- 快捷操作网格重设计
- 会话持久化修复
- [其他项...]

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"

Step 8: Create Git Tag

步骤8:创建Git标签

bash
undefined
bash
undefined

Create annotated tag with message

创建带注释的标签并添加说明

git tag -a v1.1.22 -m "Release v1.1.22
New Features:
  • Quick Actions grid redesign (#123)
Bug Fixes:
  • Session persistence fix (#124)"
undefined
git tag -a v1.1.22 -m "Release v1.1.22
新功能:
  • 快捷操作网格重设计 (#123)
Bug修复:
  • 会话持久化修复 (#124)"
undefined

Step 9: Push to Remote

步骤9:推送到远程仓库

bash
undefined
bash
undefined

Push commit

提交变更

git push origin main
git push origin main

Push tag

推送标签

git push origin v1.1.22
undefined
git push origin v1.1.22
undefined

Step 10: Create GitHub Release

步骤10:创建GitHub Release

bash
gh release create v1.1.22 \
  --title "v1.1.22" \
  --notes "## What's New
bash
gh release create v1.1.22 \
  --title "v1.1.22" \
  --notes "## 新增内容

New Features

新功能

  • Web: Dashboard redesign with new widgets (#123)
  • Web: 仪表板重设计,新增小部件 (#123)

Bug Fixes

Bug修复

  • Fixed session persistence on embed chat (#124)

undefined
  • 修复嵌入聊天的会话持久化问题 (#124)

undefined

Step 11: Update TASKS.md

步骤11:更新TASKS.md

Move only merged items from "Ready to Ship" to "Shipped". Unmerged items stay for next release:
Before:
markdown
undefined
仅将已合并项从「待发布」移至「已发布」区域。未合并项将留在「待发布」区域用于下一次发布:
更新前:
markdown
undefined

Ready to Ship

待发布

TaskBranchPRMergedTask Doc
Quick Actions Redesignfeature/quick-actions#123✅ Jan 25link
Session Fixfix/session-persist#124✅ Jan 25link
New Featurefeature/new#125Nolink

**After:**
```markdown
任务分支PR已合并任务文档
快捷操作重设计feature/quick-actions#123✅ 1月25日链接
会话修复fix/session-persist#124✅ 1月25日链接
新功能feature/new#125链接

**更新后:**
```markdown

Ready to Ship

待发布

TaskBranchPRMergedTask Doc
New Featurefeature/new#125Nolink

任务分支PR已合并任务文档
新功能feature/new#125链接

Shipped

已发布

TaskPRReleaseShipped
Quick Actions Grid Redesign#123v1.1.22Jan 26
Session Persistence Fix#124v1.1.22Jan 26

**Key points:**
- Only merged items (✅) move to "Shipped"
- Each item gets the release version (v1.1.22)
- Unmerged items stay in "Ready to Ship" for next release
- This ensures `/release` always knows exactly what to include

---
任务PR发布版本发布日期
快捷操作网格重设计#123v1.1.221月26日
会话持久化修复#124v1.1.221月26日

**关键点:**
- 仅已合并项(✅)移至「已发布」区域
- 每个项将标记对应的发布版本(v1.1.22)
- 未合并项留在「待发布」区域用于下一次发布
- 确保 `/release` 始终明确知道需要包含哪些项

---

Changelog Format Guidelines

变更日志格式指南

Changelog Entry Structure

变更日志条目结构

markdown
undefined
markdown
undefined

[vX.Y.Z] - Month DD, YYYY

[vX.Y.Z] - YYYY年MM月DD日

New Features

新功能

  • Scope: Description (#PR)
  • 范围: 描述 (#PR)

Bug Fixes

Bug修复

  • Description (#PR)
  • 描述 (#PR)

Enhancements

功能增强

  • Description (#PR)
  • 描述 (#PR)

Documentation

文档更新

  • Description (#PR)
  • 描述 (#PR)

Breaking Changes (if any)

破坏性变更(如有)

  • Description of what breaks and migration path
undefined
  • 变更内容及迁移路径说明
undefined

Writing Good Changelog Entries

编写优质变更日志条目

Do:
  • Start with verb (Added, Fixed, Improved, Updated)
  • Include scope when helpful (Web, API)
  • Reference PR number
  • Be user-focused (what changed for them)
Don't:
  • Include internal refactors users don't see
  • Be too technical
  • Include duplicate entries
Examples:
markdown
undefined
建议:
  • 以动词开头(新增、修复、优化、更新)
  • 必要时包含范围(Web、API)
  • 引用PR编号
  • 以用户为中心(说明对用户的影响)
避免:
  • 包含用户不可见的内部重构
  • 过于技术化
  • 重复条目
示例:
markdown
undefined

Good

优质示例

  • Web: Added dashboard widgets with custom icons (#123)
  • Fixed booking calendar not loading on slow connections (#124)
  • Web: 新增带自定义图标的仪表板小部件 (#123)
  • 修复慢速网络下预订日历无法加载的问题 (#124)

Bad

不良示例

  • Updated home.tsx
  • Refactored Dashboard component

---
  • 更新home.tsx
  • 重构Dashboard组件

---

Summary Output

汇总输出

After completing
/release
:
Release v1.1.22 created successfully!

Changes included:
- New Features: 2
- Bug Fixes: 1
- Enhancements: 1
- Documentation: 1

Files updated:
- docs/changelogs/CHANGELOG.md
- TASKS.md

Git:
- Tag: v1.1.22
- Commit: abc1234

GitHub:
- Release: https://github.com/owner/repo/releases/tag/v1.1.22

Next release will be: v1.1.23 (patch) / v1.2.0 (minor) / v2.0.0 (major)

完成
/release
后将显示:
Release v1.1.22 创建成功!

包含的变更:
- 新功能: 2
- Bug修复: 1
- 功能增强: 1
- 文档更新: 1

已更新文件:
- docs/changelogs/CHANGELOG.md
- TASKS.md

Git相关:
- 标签: v1.1.22
- 提交: abc1234

GitHub相关:
- Release: https://github.com/owner/repo/releases/tag/v1.1.22

下一次发布版本可能为: v1.1.23(补丁) / v1.2.0(次版本) / v2.0.0(主版本)

Handling Edge Cases

边缘情况处理

No Merged Items in "Ready to Ship"

「待发布」区域无已合并项

Error: No merged items found in "Ready to Ship" section.

Please ensure:
1. PRs have been created via /ship
2. PRs have been merged (Merged column shows ✅)
3. TASKS.md "Ready to Ship" section has items with Merged = ✅

Current "Ready to Ship" items:
- {task-name}: Not merged (Merged = No)
错误:在「待发布」区域未找到已合并项。

请确认:
1. PR已通过/ship创建
2. PR已合并(「已合并」列显示✅)
3. TASKS.md的「待发布」区域存在标记为✅的项

当前「待发布」项:
- {task-name}: 未合并(「已合并」= 否)

Tag Already Exists

标签已存在

Error: Tag v1.1.22 already exists.

Options:
1. Use a different version: /release v1.1.23
2. Delete existing tag (if mistake): git tag -d v1.1.22
错误:标签v1.1.22已存在。

可选操作:
1. 使用其他版本:/release v1.1.23
2. 删除现有标签(若为误操作):git tag -d v1.1.22

Missing Task Type

任务类型缺失

If a task document doesn't have a
Type
field:
  • Default to "enhancement"
  • Warn user to add types for better categorization

若任务文档中无「类型」字段:
  • 默认归类为「功能增强」
  • 提醒用户添加类型以获得更准确的分类

Related Skills

相关技能

SkillWhen to Use
/ship
Before /release - gets items to "Ready to Ship"
/task
Add
Type
field when planning tasks
/document
Ensure docs are updated before release
技能使用时机
/ship
在/release之前使用 - 将项移至「待发布」区域
/task
规划任务时添加「类型」字段
/document
发布前确保文档已更新

Recommended Plugins (Optional)

推荐插件(可选)

These plugins provide best practices reference but must be installed separately:
PluginInstall FromWhen Useful
vercel-react-best-practices
vercel-labs/agent-skillsReact/Next.js optimization reference
supabase-postgres-best-practices
supabase/agent-skillsDatabase best practices reference

这些插件提供最佳实践参考,但需单独安装:
插件安装来源适用场景
vercel-react-best-practices
vercel-labs/agent-skillsReact/Next.js优化参考
supabase-postgres-best-practices
supabase/agent-skills数据库最佳实践参考

Task Document Type Field

任务文档类型字段

When using
/task
, include the Type field:
markdown
> **Status:** PLANNED
> **Priority:** HIGH
> **Type:** feature | bugfix | enhancement | documentation | chore
> **Created:** January 25, 2026
> **Platform:** Web
This enables automatic categorization in changelogs.
使用
/task
时,请包含类型字段:
markdown
> **状态:** PLANNED
> **优先级:** HIGH
> **类型:** feature | bugfix | enhancement | documentation | chore
> **创建时间:** 2026年1月25日
> **平台:** Web
这将实现变更日志的自动分类。