release-manager

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Release Manager

发布管理器

Automate the entire release lifecycle: version bump, changelog, README update, documentation sync, build, git tag, GitHub release, and publishing to PyPI/npm.

自动化完整的发布生命周期：版本号更新、变更日志生成、README更新、文档同步、构建、Git标签创建、GitHub发布，以及发布到PyPI/npm。

Architecture

架构

This skill uses a main-agent-as-orchestrator pattern. The main agent handles user communication, confirmation gates, and lightweight steps. Heavy work (scanning files, generating changelogs, updating docs) is delegated to subagents that run in isolated context — keeping the main conversation clean and enabling parallel execution.

Main Agent (orchestrator)
├── Step 1: Pre-flight checks (inline)
├── Step 2: Determine version (inline — needs user input)
│
├── Steps 3-6: Spawn subagents in parallel ──────────────┐
│   ├── version-bumper    — scan & propose version changes │
│   ├── changelog-generator — generate changelog from git  │
│   └── docs-updater      — find & propose doc updates     │
│                                                          │
├── Collect results, present to user for confirmation  ◄───┘
├── Spawn: release-reviewer — independent quality check
│
├── Step 7: Build (inline — needs user confirmation)
├── Step 8: Commit, tag, push (inline — needs user confirmation)
├── Step 9: GitHub Release (inline — needs user confirmation)
└── Step 10: Publish to registries (inline — needs user confirmation)

本技能采用主Agent作为编排器的模式。主Agent负责用户沟通、确认环节和轻量级步骤。繁重的工作（扫描文件、生成变更日志、更新文档）会委托给在独立上下文运行的子Agent（subagents）——保持主对话简洁，并支持并行执行。

Main Agent (orchestrator)
├── Step 1: Pre-flight checks (inline)
├── Step 2: Determine version (inline — needs user input)
│
├── Steps 3-6: Spawn subagents in parallel ──────────────┐
│   ├── version-bumper    — scan & propose version changes │
│   ├── changelog-generator — generate changelog from git  │
│   └── docs-updater      — find & propose doc updates     │
│                                                          │
├── Collect results, present to user for confirmation  ◄───┘
├── Spawn: release-reviewer — independent quality check
│
├── Step 7: Build (inline — needs user confirmation)
├── Step 8: Commit, tag, push (inline — needs user confirmation)
├── Step 9: GitHub Release (inline — needs user confirmation)
└── Step 10: Publish to registries (inline — needs user confirmation)

Graceful degradation

优雅降级

If the Agent tool is not available (e.g., Claude.ai), execute steps 3-6 inline instead of spawning subagents. Follow the same logic described in each agent file, but run it directly in the main conversation. This is less context-efficient but functionally identical.

如果Agent工具不可用（例如Claude.ai），则将步骤3-6改为内联执行，而非生成子Agent。遵循每个Agent文件中描述的相同逻辑，但直接在主对话中运行。这种方式上下文效率较低，但功能完全一致。

Repo Sync Before Edits (mandatory)

编辑前的仓库同步（必填）

Before creating/updating/deleting files in an existing repository, sync the current branch with remote:

bash

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

If the working tree is not clean, stash first, sync, then restore:

bash

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

origin

is missing, pull is unavailable, or rebase/stash conflicts occur, stop and ask the user before continuing.

在现有仓库中创建/更新/删除文件之前，需将当前分支与远程仓库同步：

bash

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

如果工作区未清理，请先暂存内容，同步后再恢复：

bash

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

如果

origin

不存在、无法拉取，或在变基/暂存时发生冲突，请停止操作并询问用户后再继续。

Overview

概述

A release typically involves these steps in order. Some are optional depending on the project. Walk through each one, confirming with the user before making changes.

Pre-flight checks — clean working tree, synced with remote
Determine version — analyze changes, suggest semver bump
Bump version numbers — (subagent) scan and propose version changes
Generate changelog / release notes — (subagent) from git history and PRs
Update README — (subagent, combined with docs) version badges, changelog entries
Update documentation — (subagent) sync all project docs
Build — run the project's build step if one exists
Commit, tag, push — create the release commit and tag
GitHub Release — publish on GitHub with release notes
Publish to registries — publish to PyPI and/or npm

发布通常按以下顺序执行步骤。部分步骤根据项目情况可选。逐步执行每个步骤，在做出更改前需与用户确认。

预检检查 — 工作区已清理、与远程仓库同步
确定版本号 — 分析变更，建议语义化版本（semver）更新
更新版本号 — (子Agent) 扫描并建议版本变更
生成变更日志/发布说明 — (子Agent) 从Git历史和PR中生成
更新README — (子Agent，与文档更新合并) 版本徽章、变更日志条目
更新文档 — (子Agent) 同步所有项目文档
构建 — 如果项目有构建步骤则执行
提交、标记、推送 — 创建发布提交和标签
GitHub发布 — 在GitHub上发布并附带发布说明
发布到包仓库 — 发布到PyPI和/或npm

Step 1: Pre-flight Checks (inline)

步骤1：预检检查（内联）

Verify the repo is in a clean state before starting:

bash

undefined

在开始前验证仓库处于干净状态：

bash

undefined

Check for uncommitted changes

检查未提交的更改

git status --porcelain

Check current branch (usually main or master)

检查当前分支（通常为main或master）

git rev-parse --abbrev-ref HEAD

Ensure we're up to date

确保已同步最新内容

git fetch origin git status -sb


If there are uncommitted changes, ask the user whether to stash them, commit them first, or abort. Do not silently discard work.

git fetch origin git status -sb


如果存在未提交的更改，请询问用户是暂存、先提交还是中止操作。请勿静默丢弃工作内容。

Check for existing release tools

检查现有发布工具

Before proceeding with manual steps, check if the project already uses a release tool:

bash

undefined

在执行手动步骤之前，检查项目是否已使用发布工具：

bash

undefined

package.json scripts

package.json脚本

grep -E '"(release|version|publish)"' package.json 2>/dev/null

Config files

配置文件

ls .releaserc* .changeset/ .versionrc* lerna.json 2>/dev/null


If found, tell the user: "This project uses `<tool>`. I'll run its release command instead of manual steps." and defer to that tool.

---

ls .releaserc* .changeset/ .versionrc* lerna.json 2>/dev/null


如果发现工具，告知用户：“此项目使用`<tool>`。我将运行其发布命令而非手动步骤。”并遵循该工具的流程。

---

Step 2: Determine Version (inline)

步骤2：确定版本号（内联）

Analyze changes since last release

分析自上次发布以来的变更

bash

undefined

bash

undefined

Find the latest tag

查找最新标签

git tag --sort=-creatordate | head -10

Show commits since last tag

显示自上次标签以来的提交

git log $(git describe --tags --abbrev=0 2>/dev/null || echo "HEAD~50")..HEAD --oneline --no-merges

Count by type for the recommendation

按类型统计以提供建议

git log $(git describe --tags --abbrev=0 2>/dev/null || echo "HEAD~~50")..HEAD --oneline --no-merges | grep -cE "^[a-f0-9]+ feat" || true git log $(git describe --tags --abbrev=0 2>/dev/null || echo "HEAD~~50")..HEAD --oneline --no-merges | grep -cE "^[a-f0-9]+ fix" || true git log $(git describe --tags --abbrev=0 2>/dev/null || echo "HEAD~50")..HEAD --oneline --no-merges | grep -ciE "^[a-f0-9]+ (BREAKING|!:)" || true

undefined

undefined

Suggest version bump

建议版本更新

Based on conventional commits:

MAJOR — any
```
BREAKING:
```
or
```
!:
```
commits exist
MINOR — any
```
feat:
```
commits (with no breaking changes)
PATCH — only
```
fix:
```
,
```
docs:
```
,
```
chore:
```
,
```
refactor:
```
, etc.

Present the suggestion: "Based on N features, M fixes, and K breaking changes since vX.Y.Z, I recommend bumping to vA.B.C. Does that look right?"

Always let the user override the version number. When in doubt, lean toward MINOR over PATCH — features are easy to miss in commit messages.

基于约定式提交：

MAJOR — 存在任何
```
BREAKING:
```
或
```
!:
```
提交
MINOR — 存在任何
```
feat:
```
提交（无破坏性变更）
PATCH — 仅包含
```
fix:
```
、
```
docs:
```
、
```
chore:
```
、
```
refactor:
```
等提交

呈现建议：“基于自vX.Y.Z以来的N个功能、M个修复和K个破坏性变更，我建议更新到vA.B.C。是否合适？”

始终允许用户覆盖版本号。如有疑问，优先选择MINOR版本而非PATCH版本——提交消息中容易遗漏功能变更。

Steps 3-6: Parallel Subagent Execution

步骤3-6：并行子Agent执行

Once the user confirms the version number, create a workspace directory and spawn three subagents in the same turn (parallel execution). This is where the orchestrator pattern pays off — all three agents work simultaneously in isolated context while the main conversation stays clean.

用户确认版本号后，创建工作区目录并在同一轮中生成三个子Agent（并行执行）。这就是编排器模式的优势——所有三个Agent在独立上下文同时工作，而主对话保持简洁。

Setup workspace

设置工作区

bash

WORKSPACE="/tmp/release-workspace-$(date +%s)"
mkdir -p "$WORKSPACE"/{version-bumper,changelog-generator,docs-updater}

bash

WORKSPACE="/tmp/release-workspace-$(date +%s)"
mkdir -p "$WORKSPACE"/{version-bumper,changelog-generator,docs-updater}

Spawn subagents (all in the same turn)

生成子Agent（同一轮中全部生成）

1. Version Bumper — Read

agents/version-bumper.md

for the full prompt. Spawn with:

```
PROJECT_PATH
```
: the project root
```
OLD_VERSION
```
: confirmed old version
```
NEW_VERSION
```
: confirmed new version
```
OUTPUT_DIR
```
:
```
$WORKSPACE/version-bumper
```

2. Changelog Generator — Read

agents/changelog-generator.md

for the full prompt. Spawn with:

```
PROJECT_PATH
```
: the project root
```
OLD_VERSION
```
: confirmed old version
```
NEW_VERSION
```
: confirmed new version

OUTPUT_DIR

$WORKSPACE/changelog-generator

3. Docs Updater — Read

agents/docs-updater.md

for the full prompt. Spawn with:

```
PROJECT_PATH
```
: the project root
```
OLD_VERSION
```
: confirmed old version
```
NEW_VERSION
```
: confirmed new version
```
CHANGELOG_SUMMARY
```
: brief summary of changes from Step 2 analysis (e.g., "3 features, 2 fixes, 0 breaking changes")
```
OUTPUT_DIR
```
:
```
$WORKSPACE/docs-updater
```

1. Version Bumper — 阅读

agents/version-bumper.md

获取完整提示。生成时传入：

```
PROJECT_PATH
```
: 项目根目录
```
OLD_VERSION
```
: 确认的旧版本
```
NEW_VERSION
```
: 确认的新版本
```
OUTPUT_DIR
```
:
```
$WORKSPACE/version-bumper
```

2. Changelog Generator — 阅读

agents/changelog-generator.md

获取完整提示。生成时传入：

```
PROJECT_PATH
```
: 项目根目录
```
OLD_VERSION
```
: 确认的旧版本
```
NEW_VERSION
```
: 确认的新版本

OUTPUT_DIR

$WORKSPACE/changelog-generator

3. Docs Updater — 阅读

agents/docs-updater.md

获取完整提示。生成时传入：

```
PROJECT_PATH
```
: 项目根目录
```
OLD_VERSION
```
: 确认的旧版本
```
NEW_VERSION
```
: 确认的新版本
```
CHANGELOG_SUMMARY
```
: 步骤2分析的变更简要总结（例如：“3个功能，2个修复，0个破坏性变更”）
```
OUTPUT_DIR
```
:
```
$WORKSPACE/docs-updater
```

Collect and present results

收集并呈现结果

After all three subagents complete, read their output files and present a consolidated summary to the user:

Version changes — read
```
$WORKSPACE/version-bumper/version-changes.md
```
and show which files will be updated

Changelog — read

$WORKSPACE/changelog-generator/changelog-entry.md

and show the formatted entry

Doc updates — read
```
$WORKSPACE/docs-updater/docs-changes.md
```
and show proposed documentation changes

Present all three together: "Here's the full picture of what this release will change. Review and confirm, or tell me what to adjust."

所有三个子Agent完成后，读取它们的输出文件并向用户呈现合并后的摘要：

版本变更 — 读取
```
$WORKSPACE/version-bumper/version-changes.md
```
并显示将更新的文件
变更日志 — 读取
```
$WORKSPACE/changelog-generator/changelog-entry.md
```
并显示格式化后的条目
文档更新 — 读取
```
$WORKSPACE/docs-updater/docs-changes.md
```
并显示建议的文档变更

将三者一起呈现：“以下是此发布将做出的完整变更内容。请审核确认，或告知我需要调整的部分。”

Independent review (optional but recommended)

独立审核（可选但推荐）

After the user has seen the proposed changes, spawn the release-reviewer subagent for an independent quality check. Read

agents/release-reviewer.md

for the full prompt. Spawn with:

```
PROJECT_PATH
```
: the project root
```
WORKSPACE_DIR
```
:
```
$WORKSPACE
```
```
OLD_VERSION
```
: confirmed old version
```
NEW_VERSION
```
: confirmed new version

If the reviewer returns

NEEDS_FIX

, present the issues to the user and address them before proceeding. If

PASS

, continue.

用户查看建议的变更后，生成release-reviewer子Agent进行独立质量检查。阅读

agents/release-reviewer.md

获取完整提示。生成时传入：

```
PROJECT_PATH
```
: 项目根目录
```
WORKSPACE_DIR
```
:
```
$WORKSPACE
```
```
OLD_VERSION
```
: 确认的旧版本
```
NEW_VERSION
```
: 确认的新版本

如果审核返回

NEEDS_FIX

，将问题呈现给用户并在继续前解决。如果返回

PASS

，则继续执行。

Apply changes

应用变更

Only after user confirmation, apply all changes:

Update version strings in all files identified by the version-bumper
Prepend the changelog entry to
```
CHANGELOG.md
```
(create the file with a
```
# Changelog
```
header if it doesn't exist). Do NOT create or update a
```
RELEASE_NOTES.md
```
file
Apply documentation updates identified by the docs-updater

仅在用户确认后，应用所有变更：

更新version-bumper识别的所有文件中的版本字符串
将变更日志条目添加到
```
CHANGELOG.md
```
顶部（如果文件不存在，则创建带
```
# Changelog
```
标题的文件）。请勿创建或更新
```
RELEASE_NOTES.md
```
文件
应用docs-updater识别的文档更新

Step 7: Build (inline)

步骤7：构建（内联）

Check if the project has a build step:

bash

undefined

检查项目是否有构建步骤：

bash

undefined

Check for build configuration

检查构建配置

[ -f package.json ] && grep -q '"build"' package.json && echo "npm run build" [ -f Makefile ] && grep -q '^build:' Makefile && echo "make build" [ -f Cargo.toml ] && echo "cargo build --release" [ -f pyproject.toml ] && echo "python -m build" [ -f build.gradle ] && echo "./gradlew build" [ -f pom.xml ] && echo "mvn package"


If a build step exists:
1. Ask the user: "This project has a build step (`<command>`). Should I run it?"
2. Run the build
3. If it fails, stop and help debug — do not continue with a broken build

If no build step is detected, skip this step and tell the user.

---


如果存在构建步骤：
1. 询问用户：“此项目有构建步骤(`<command>`)。是否需要运行？”
2. 执行构建
3. 如果构建失败，停止操作并帮助调试——请勿继续使用损坏的构建结果

如果未检测到构建步骤，则跳过此步骤并告知用户。

---

Step 8: Commit, Tag, Push (inline)

步骤8：提交、标记、推送（内联）

Create the release commit

创建发布提交

Stage all changed files (version bumps, changelog, README, documentation updates):

bash

git add <specific files that were changed>
git commit -m "chore(release): vX.Y.Z"

暂存所有变更文件（版本更新、变更日志、README、文档更新）：

bash

git add <specific files that were changed>
git commit -m "chore(release): vX.Y.Z"

Create annotated tag

创建带注释的标签

bash

git tag -a vX.Y.Z -m "Release vX.Y.Z"

bash

git tag -a vX.Y.Z -m "Release vX.Y.Z"

Push

推送

Ask the user before pushing — this is a visible action:

"Ready to push the release commit and tag to origin on

<branch>

. Proceed?"

bash

git push origin <branch>
git push origin vX.Y.Z

推送前询问用户——这是一个可见操作：

“准备将发布提交和标签推送到

<branch>

分支的origin仓库。是否继续？”

bash

git push origin <branch>
git push origin vX.Y.Z

Step 9: GitHub Release (inline)

步骤9：GitHub发布（内联）

gh

CLI is available and this is a GitHub repo, offer to create a GitHub release:

bash

gh release create vX.Y.Z \
  --title "vX.Y.Z" \
  --notes-file CHANGELOG.md \
  --latest

If there are build artifacts to attach (

.tar.gz

.zip

, binaries,

.skill

files, etc.):

bash

gh release create vX.Y.Z \
  --title "vX.Y.Z" \
  --notes-file CHANGELOG.md \
  --latest \
  path/to/artifact1 path/to/artifact2

After creating the release, share the release URL with the user.

如果

gh

CLI可用且为GitHub仓库，可提供创建GitHub发布的服务：

bash

gh release create vX.Y.Z \
  --title "vX.Y.Z" \
  --notes-file CHANGELOG.md \
  --latest

如果有构建产物需要附加（

.tar.gz

、

.zip

、二进制文件、

.skill

文件等）：

bash

gh release create vX.Y.Z \
  --title "vX.Y.Z" \
  --notes-file CHANGELOG.md \
  --latest \
  path/to/artifact1 path/to/artifact2

创建发布后，将发布URL分享给用户。

Step 10: Publish to Package Registries (inline)

步骤10：发布到包仓库（内联）

If the project publishes to PyPI and/or npm, read

references/publishing.md

for the full publishing workflow including pre-requisites, build, verify, upload, and post-publish verification steps.

如果项目发布到PyPI和/或npm，请阅读

references/publishing.md

获取完整的发布工作流，包括前置条件、构建、验证、上传和发布后验证步骤。

Expected Output

预期输出

After the release completes, a summary is presented:

Release v2.4.0 complete.

Version bumped: pyproject.toml, package.json (1.3.1 → 2.4.0)
Changelog: CHANGELOG.md updated (8 commits: 3 features, 4 fixes, 1 breaking change)
Git tag: v2.4.0 (annotated) pushed to origin
GitHub release: https://github.com/owner/repo/releases/tag/v2.4.0
Published: PyPI — https://pypi.org/project/mypackage/2.4.0/

Post-release reminders:
- [ ] Announce on Discord
- [ ] Monitor for install issues (pip install mypackage==2.4.0)

发布完成后，呈现摘要：

Release v2.4.0 complete.

Version bumped: pyproject.toml, package.json (1.3.1 → 2.4.0)
Changelog: CHANGELOG.md updated (8 commits: 3 features, 4 fixes, 1 breaking change)
Git tag: v2.4.0 (annotated) pushed to origin
GitHub release: https://github.com/owner/repo/releases/tag/v2.4.0
Published: PyPI — https://pypi.org/project/mypackage/2.4.0/

Post-release reminders:
- [ ] Announce on Discord
- [ ] Monitor for install issues (pip install mypackage==2.4.0)

Edge Cases

边缘情况

No conventional commits: If commit messages do not follow the
```
feat:
```
/
```
fix:
```
/
```
BREAKING:
```
convention, the version bump suggestion cannot be automated. Present the raw commit list to the user and ask them to confirm the semver bump explicitly.
No remote configured: If
```
git remote
```
returns nothing, skip the push and GitHub release steps. Warn the user and offer to create a local tag only.
Already published version: If the target version already exists on PyPI or npm (detected via
```
pip index versions
```
or
```
npm view
```
), abort the publish step and ask whether to bump to a new patch version or skip publishing.

无约定式提交：如果提交消息不遵循
```
feat:
```
/
```
fix:
```
/
```
BREAKING:
```
约定，则无法自动建议版本更新。向用户呈现原始提交列表并要求明确确认语义化版本更新。
未配置远程仓库：如果
```
git remote
```
返回空，则跳过推送和GitHub发布步骤。警告用户并仅提供创建本地标签的选项。
版本已发布：如果目标版本已在PyPI或npm上存在（通过
```
pip index versions
```
或
```
npm view
```
检测），则中止发布步骤并询问用户是更新到新的PATCH版本还是跳过发布。

Acceptance Criteria

验收标准

Version string is bumped consistently in all detected files (e.g.,
```
pyproject.toml
```
,
```
package.json
```
,
```
__version__
```
)
```
CHANGELOG.md
```
is updated with a new entry for the release version
An annotated git tag is created and pushed to origin
A GitHub release is created with release notes when
```
gh
```
CLI is available
The user is asked to confirm before each destructive or visible action (push, publish, GitHub release)
Post-release checklist is presented to the user after completion

版本字符串在所有检测到的文件中一致更新（例如
```
pyproject.toml
```
、
```
package.json
```
、
```
__version__
```
）
```
CHANGELOG.md
```
更新了对应发布版本的新条目
创建了带注释的Git标签并推送到origin
当
```
gh
```
CLI可用时，创建了附带发布说明的GitHub发布
在执行每个破坏性或可见操作（推送、发布、GitHub发布）前均询问用户确认
发布完成后向用户呈现发布后检查清单

Step Completion Reports

步骤完成报告

After completing each major step, output a status report in this format:

◆ [Step Name] ([step N of M] — [context])
··································································
  [Check 1]:          √ pass
  [Check 2]:          √ pass (note if relevant)
  [Check 3]:          × fail — [reason]
  [Check 4]:          √ pass
  [Criteria]:         √ N/M met
  ____________________________
  Result:             PASS | FAIL | PARTIAL

Adapt the check names to match what the step actually validates. Use

√

for pass,

×

for fail, and

—

to add brief context. The "Criteria" line summarizes how many acceptance criteria were met. The "Result" line gives the overall verdict.

完成每个主要步骤后，按以下格式输出状态报告：

◆ [Step Name] ([step N of M] — [context])
··································································
  [Check 1]:          √ pass
  [Check 2]:          √ pass (note if relevant)
  [Check 3]:          × fail — [reason]
  [Check 4]:          √ pass
  [Criteria]:         √ N/M met
  ____________________________
  Result:             PASS | FAIL | PARTIAL

调整检查名称以匹配步骤实际验证的内容。使用

√

表示通过，

×

表示失败，

—

添加简要上下文。“Criteria”行总结已满足的验收标准数量。“Result”行给出整体结论。

Phase-specific checks

阶段特定检查

Step 1 — Pre-flight

◆ Pre-flight (step 1 of 10 — repo state)
··································································
  Branch clean:             √ pass
  Tests pass:               √ pass
  Dependencies resolved:    √ pass (synced with remote)
  ____________________________
  Result:             PASS | FAIL | PARTIAL

Steps 2-3 — Version Bump

◆ Version Bump (step 3 of 10 — version consistency)
··································································
  Files updated:            √ pass (N files changed)
  Version consistent:       √ pass (all files match vX.Y.Z)
  ____________________________
  Result:             PASS | FAIL | PARTIAL

Step 4 — Changelog

◆ Changelog (step 4 of 10 — release notes)
··································································
  Changes extracted:        √ pass (N commits categorized)
  Notes formatted:          √ pass (conventional commit format)
  ____________________________
  Result:             PASS | FAIL | PARTIAL

Steps 7-10 — Build & Publish

◆ Build & Publish (step 7-10 of 10 — release delivery)
··································································
  Build success:            √ pass
  Tag created:              √ pass (vX.Y.Z annotated tag)
  Package published:        √ pass (PyPI | npm | skipped)
  GitHub release created:   √ pass (URL: ...)
  ____________________________
  Result:             PASS | FAIL | PARTIAL

步骤1 — 预检

◆ Pre-flight (step 1 of 10 — repo state)
··································································
  Branch clean:             √ pass
  Tests pass:               √ pass
  Dependencies resolved:    √ pass (synced with remote)
  ____________________________
  Result:             PASS | FAIL | PARTIAL

步骤2-3 — 版本更新

◆ Version Bump (step 3 of 10 — version consistency)
··································································
  Files updated:            √ pass (N files changed)
  Version consistent:       √ pass (all files match vX.Y.Z)
  ____________________________
  Result:             PASS | FAIL | PARTIAL

步骤4 — 变更日志

◆ Changelog (step 4 of 10 — release notes)
··································································
  Changes extracted:        √ pass (N commits categorized)
  Notes formatted:          √ pass (conventional commit format)
  ____________________________
  Result:             PASS | FAIL | PARTIAL

步骤7-10 — 构建与发布

◆ Build & Publish (step 7-10 of 10 — release delivery)
··································································
  Build success:            √ pass
  Tag created:              √ pass (vX.Y.Z annotated tag)
  Package published:        √ pass (PyPI | npm | skipped)
  GitHub release created:   √ pass (URL: ...)
  ____________________________
  Result:             PASS | FAIL | PARTIAL

Post-Release Checklist

发布后检查清单

After the release is complete, remind the user about common post-release tasks:

Announce the release (blog, social media, Discord, Slack)
Bump version to next development version (e.g.,
```
X.Y.Z-dev
```
) if the project uses that convention
Close the GitHub milestone if one exists
Monitor for issues related to the new release
Verify published packages are installable (
```
pip install pkg==X.Y.Z
```
,
```
npm install pkg@X.Y.Z
```
)

发布完成后，提醒用户常见的发布后任务：

宣布发布（博客、社交媒体、Discord、Slack）
如果项目遵循相关约定，将版本更新到下一个开发版本（例如
```
X.Y.Z-dev
```
）
如果存在GitHub里程碑，将其关闭
监控与新版本相关的问题
验证已发布的包可正常安装（
```
pip install pkg==X.Y.Z
```
、
```
npm install pkg@X.Y.Z
```
）

Tips

提示

Always confirm destructive or visible actions (push, release creation) with the user
For monorepos with multiple packages, handle each package's version independently
Respect existing CHANGELOG format — don't reformat the entire file, just add the new entry
If a release goes wrong mid-way, help the user roll back: delete the tag locally and remotely, revert the commit

执行破坏性或可见操作（推送、创建发布）前始终与用户确认
对于包含多个包的单体仓库，独立处理每个包的版本
尊重现有CHANGELOG格式——不要重新格式化整个文件，仅添加新条目
如果发布中途出错，帮助用户回滚：删除本地和远程标签，还原提交

Reference files

参考文件

```
agents/version-bumper.md
```
— Subagent prompt for scanning and proposing version string changes
```
agents/changelog-generator.md
```
— Subagent prompt for generating categorized changelog from git history
```
agents/docs-updater.md
```
— Subagent prompt for discovering and proposing documentation updates
```
agents/release-reviewer.md
```
— Subagent prompt for independent quality review of all release changes
```
references/publishing.md
```
— Full publishing workflow for PyPI and npm

```
agents/version-bumper.md
```
— 用于扫描并建议版本字符串变更的子Agent提示
```
agents/changelog-generator.md
```
— 用于从Git历史生成分类变更日志的子Agent提示
```
agents/docs-updater.md
```
— 用于发现并建议文档更新的子Agent提示
```
agents/release-reviewer.md
```
— 用于对所有发布变更进行独立质量审核的子Agent提示
```
references/publishing.md
```
— PyPI和npm的完整发布工作流