publish

你是 oh-my-opencode 的发布经理。请从头到尾执行完整的发布工作流。

重要：发布只负责交付——直接进入工作流

origin/dev 已通过门禁：每个 PR 和推送都会在 3 个操作系统上运行 CI（测试／类型检查／codex-compatibility），发布工作流也会在发布任何内容之前重新运行这些门禁。

• 发布请求中绝不可运行 /pre-publish-review、/review-work 或进行任何代码复审。 仅当用户明确要求审查时才运行这些流程。
• 发布过程中绝不可“修复”代码、创建 PR，或进入修复后重新审计的循环。 如果工作流失败或发现异常，请报告并停止——发布不是修复代码树的合适时机。
• 指定了版本升级类型的发布请求应在几分钟内从步骤 0 进入步骤 3（触发）。唯一需要人工投入较多时间的工作是编写发布说明，可在 CI 运行期间起草。

重要：完整工作流意味着涵盖三个发布层面

只有验证完所有发布层面，发布才算完成：

发布层	范围	所需证明
omo pure components	已发布软件包内容中的 Core／MCP／共享技能变更	发布说明需指出各层面的版本影响（来自工作流变更日志；如果用户提出要求，则使用 /get-unpublished-changes）。
omo opencode	oh-my-opencode 和 oh-my-openagent npm 软件包及平台软件包	已选定版本对应的 npm 版本和 GitHub release 均已存在。
omo codex	lazycodex-ai、Codex 插件元数据和 code-yeongyu/lazycodex marketplace release	Codex 插件元数据已标记发布版本，lazycodex-ai 已发布；如果 marketplace 内容有变更，也已创建 LazyCodex 仓库 release。

在 oh-my-opencode、oh-my-openagent、lazycodex-ai 或 code-yeongyu/lazycodex 的验证尚未完成时，绝不可报告发布工作流已完成。

重要：完整工作流也包括 Discord

只有尝试发布 Discord 发布公告后，发布才算完成。

• 创建 GitHub release 后不可停止。
• 起草或应用发布说明后不可停止。
• 如果用户已确认发布，不要等待用户再次确认。
• 发布说明定稿后，立即执行步骤 7.5 并发布到 Discord。
• 如果身份验证／重试后 Discord 发布仍失败，请明确报告失败，并继续完成其余验证步骤。跳过 Discord 步骤即表示工作流失败。

关键：触发后不得提前结束当前轮次（完成约定）

gh workflow run publish 成功后，发布流程并未完成。之前有个会话忘记了这一点：它触发工作流后就结束了当前轮次，导致发布未验证、增强版摘要未编写，Discord 公告也未发送。正因如此，才有了本节。

在步骤 3（触发）之后，你 MUST 推进运行直至得出最终结果，并完成触发后的每个步骤，然后才能结束当前轮次。只要以下任一事项仍未解决，你就不得结束当前轮次、移交工作或当天收工：

1. 运行结果 — gh run view <id> --json conclusion 必须返回 success（起草说明时轮询；不要空等）。
2. 发布版本已存在 — 步骤 5：gh release view v${NEW_VERSION} 能够成功解析。
3. 已应用增强版摘要 — 步骤 6 + 步骤 7：起草摘要（patch/minor/major 版本均为必需），并通过 gh release edit --notes-file 应用。“Patch 是可选的”这种说法是错误的；Patch 摘要是必需的。
4. 已发布 Discord 公告 — 步骤 7.5：已尝试执行 agent-discordbot message send；要么记录了消息 ID，要么向用户明确报告失败。跳过 Discord 步骤即表示工作流失败。
5. 已验证 npm — 步骤 8：npm view oh-my-opencode version（以及 oh-my-openagent、lazycodex-ai）显示 ${NEW_VERSION}。

只有以上五项全部通过后，才能结束当前轮次。如果运行失败，则执行 gh run view <id> --log-failed，报告失败并停止（发布期间不要修复代码树）。如果触发后的步骤因外部原因失败（npm 传播、Discord 身份验证），应明确报告并继续执行剩余步骤；不要让单项失败中止其余流程。

此约定也适用于斜杠命令副本（.agents/command/publish.md、.opencode/command/publish.md）；根据 .agents/AGENTS.md 中的差异规则，这些副本与此技能保持逐字节一致。

关键：参数要求

你 MUST 从用户处获得一个发布选择器。 有效选项：

• patch：错误修复，向后兼容（1.1.7 → 1.1.8）
• minor：新功能，向后兼容（1.1.7 → 1.2.0）
• major：破坏性变更（1.1.7 → 2.0.0）
• 明确有效的语义化版本号，包括预发布版本，例如 5.0.0-beta.9

如果用户未提供发布选择器，请立即停止并询问：

"要继续部署，请指定 patch、minor、major，或明确的语义化版本号，例如 5.0.0-beta.9。"

拒绝任何其他值。不要推断或修复格式错误的版本号。

---

步骤 0：登记待办列表（必须首先执行）

在执行任何其他操作之前，使用 TodoWrite 创建详细的待办列表：

[
  { "id": "confirm-release-input", "content": "Confirm release selector with user (patch/minor/major or explicit semver)", "status": "in_progress", "priority": "high" },
  { "id": "check-uncommitted", "content": "Check for uncommitted changes and commit if needed", "status": "pending", "priority": "high" },
  { "id": "sync-remote", "content": "Sync with remote (pull --rebase && push if unpushed commits)", "status": "pending", "priority": "high" },
  { "id": "run-workflow", "content": "Trigger GitHub Actions publish workflow", "status": "pending", "priority": "high" },
  { "id": "wait-workflow", "content": "Wait for workflow completion (poll every 30s)", "status": "pending", "priority": "high" },
  { "id": "verify-and-preview", "content": "Verify release created + preview auto-generated changelog & contributor thanks", "status": "pending", "priority": "high" },
  { "id": "draft-summary", "content": "Draft enhanced release summary (mandatory for all release types)", "status": "pending", "priority": "high" },
  { "id": "apply-summary", "content": "Prepend enhanced summary to release", "status": "pending", "priority": "high" },
  { "id": "discord-announce", "content": "MANDATORY: post release announcement to Discord channel immediately after release notes are finalized", "status": "pending", "priority": "high" },
  { "id": "verify-npm", "content": "Verify npm package published successfully", "status": "pending", "priority": "high" },
  { "id": "verify-lazycodex", "content": "Verify lazycodex-ai publish, Codex plugin metadata version stamp, and code-yeongyu/lazycodex release/sync", "status": "pending", "priority": "high" },
  { "id": "verify-platform-binaries", "content": "Spot-check platform binary packages on npm", "status": "pending", "priority": "high" },
  { "id": "final-confirmation", "content": "Final confirmation to user with links", "status": "pending", "priority": "low" }
]

开始处理每项待办时将其标记为 in_progress，完成后标记为 completed。一次只处理一项。

---

步骤 1：确认并分类发布选择器

如果用户已在命令参数或消息中提供选择器，即视为已确认。准确解析一次：

RELEASE_INPUT="${ARGUMENTS}"
if [[ "$RELEASE_INPUT" =~ ^(patch|minor|major)$ ]]; then
  RELEASE_KIND=bump
elif [[ "$RELEASE_INPUT" =~ ^([0-9]+\.){2}[0-9]+(-[0-9A-Za-z]+(\.[0-9A-Za-z]+)*)?$ ]]; then
  RELEASE_KIND=version
else
  echo "Invalid release selector: $RELEASE_INPUT" >&2
  exit 1
fi

仅在未提供选择器时才询问并等待。

---

步骤 2：检查未提交的变更

运行：git status --porcelain

• 如果存在未提交的变更，警告用户并询问是否要先提交
• 如果工作区干净，则继续

---

步骤 2.5：与远程同步（必须执行）

检查是否存在尚未推送的提交：

git log @{u}..HEAD --oneline

如果有尚未推送的提交，触发工作流之前 MUST 先同步：

git pull --rebase && git push

这样可以确保 GitHub Actions 工作流基于包含所有本地提交的最新代码运行。

---

步骤 3：触发 GitHub Actions 工作流

从 dev 分支派发，通过 bump 传入升级选择器，通过 version 传入确切版本号。显式版本派发时，必需的 bump 输入仍为 patch，但工作流会优先采用 version，因此忽略 bump。

if [ "$RELEASE_KIND" = bump ]; then
  RUN_URL="$(gh workflow run publish.yml --ref dev -f "bump=${RELEASE_INPUT}")"
else
  RUN_URL="$(gh workflow run publish.yml --ref dev -f bump=patch -f "version=${RELEASE_INPUT}")"
fi

if ! [[ "$RUN_URL" =~ ^https://github.com/code-yeongyu/oh-my-openagent/actions/runs/[0-9]+$ ]]; then
  echo "Publish dispatch did not return an exact workflow run URL: $RUN_URL" >&2
  exit 1
fi
RUN_ID="${RUN_URL##*/}"
if ! [[ "$RUN_ID" =~ ^[0-9]+$ ]]; then
  echo "Publish dispatch returned an invalid run ID: $RUN_ID" >&2
  exit 1
fi
gh run view "${RUN_ID}" --json databaseId,status,url --jq '{databaseId,status,url}'

返回的运行 ID 对应本次发布尝试。切勿用最新运行查询结果替换它。

---

步骤 4：等待工作流完成

发布运行是一个包含多个顺序阶段的工作流。预计耗时如下（根据近期实际运行情况，总计约 30 分钟）：

阶段（作业）	执行内容	典型耗时
test / typecheck / codex-compatibility（3 种操作系统）	在发布源代码上重新运行 CI 检查	4–8 分钟（Windows 最耗时）
prepare-release-state	标记版本、创建并自动合并 release: vX.Y.Z PR，等待该 PR 必须通过的 CI 检查	10–15 分钟（主要耗时阶段）
publish-platform（构建 + 发布，12 个目标）	构建并发布两个平台软件包系列	3–4 分钟
publish-main → release	发布 oh-my-opencode / oh-my-openagent / lazycodex-ai，创建 GitHub 发布，并同步 code-yeongyu/lazycodex	4–6 分钟

每 30 秒轮询一次作业级状态，并向用户报告阶段转换：

gh run view "${RUN_ID}" --json status,conclusion,jobs --jq '{status, conclusion, stage: ([.jobs[] | select(.status=="in_progress") | .name] | join(", "))}'

重要：使用轮询循环，不要使用 sleep 命令。 利用等待时间起草增强版发布摘要（步骤 6）——不要闲等，也不要开始任何审核工作。

如果结论为 failure，请显示错误并停止：

gh run view "${RUN_ID}" --log-failed

---

步骤 5：验证发布并预览自动生成的内容

有两个目标：确认发布已创建，然后向用户展示工作流已生成的内容。

# Pull latest (workflow committed version bump)
git pull --rebase
NEW_VERSION=$(node -p "require('./package.json').version")

# Verify release exists on GitHub
gh release view "v${NEW_VERSION}" --json tagName,url --jq '{tag: .tagName, url: .url}'

发布说明会在发布之前写入，而不是之后。

发布正文取自 CHANGELOG.md 中该版本对应的部分。将面向用户的说明作为 changes/unreleased/<pr-number>.md 片段添加（每个 PR 一个，文件名使用 PR 编号），并在触发 /publish 之前合并。发布状态准备阶段会将该标题标记为 ## [<version>] - <UTC date>，并与发布状态一同提交，因此已发布的提交本身就包含发布说明。

准确预览发布正文：

bun run script/generate-changelog.ts > /tmp/contributors.md
bun run script/print-release-notes.ts "${NEW_VERSION}" /tmp/contributors.md

预览完成后，向用户展示输出并说明：

以下是发布将要发布的确切正文： 已汇总的片段、 非团队贡献者的致谢，以及安装页脚。

两个步骤都会在失败时停止：如果缺少章节、章节为空或重复，将中止发布，而不会发布空白说明；如果某个版本已有章节，则拒绝重新标记。

如果 changes/unreleased/ 中没有片段，请停止并先编写片段——无法继续发布。

审批关卡（单一、二元）： 用户最初提出的发布请求中指定的版本升级类型，就是此工作流所需的唯一审批。此处不要等待另行确认。展示预览后，立即继续步骤 6。唯一例外：如果用户明确表示“继续之前让我先审核变更日志”（或类似表述），则停止并等待。否则继续执行，不要结束本轮对话。

---

步骤 6：起草增强版发布摘要

发布类型	操作
patch	必须起草简明的错误修复／变更摘要。没有摘要不得继续。
minor	必须起草简明的功能摘要。没有摘要不得继续。
major	必须起草完整的发布说明，并在适用时附上迁移说明。没有摘要不得继续。

OMO 原生 CLI 公开发布前的最后一次发布

当用户指出这是 OmO 原生 CLI 公开发布前的最后一次发布时，GitHub 摘要必须以专用标题开头；Discord 公告必须在 @here 后立即重复该专用标题：

## LAST RELEASE BEFORE THE OMO NATIVE CLI PUBLIC RELEASE

你要写什么（以及不写什么）

你要写的是标题层——一则位于自动生成的提交日志上方的产品公告。想想“版本发布博文”，而不是“Git 日志”。

- 绝不要重复提交消息。自动生成的部分已经列出每个提交。 - 绝不要写“各种错误修复和改进”或“若干项增强”这类泛泛的填充内容。 - 始终聚焦于**用户影响**：现在用户能做哪些以前做不到的事？ - 始终按**主题或能力**分组，而不是按提交类型（feat/fix/refactor）分组。 - 始终使用具体的表述：“现在你可以做 X”，而不是“新增了 X 功能”。 - 绝不要在任何一种版本说明中包含与 `senpi`、`omo-senpi`、`senpi-task`、`pi-goal` 或 `pi-webfetch` 匹配的内部适配器更改。 ## What's New - feat(auth): add JWT refresh token rotation - fix(auth): handle expired token edge case - refactor(auth): extract middleware ## 🔐 更智能的身份验证

令牌现在会自动无缝刷新。会话不会再在任务进行到一半时过期——系统会在后台悄悄轮换凭据。如果你一直被随机登出困扰，此版本解决了这个问题。

## 改进 - 各种性能改进 - 错误修复和稳定性增强 ## ⚡ 规则解析速度提升 3 倍

现在会根据文件修改时间缓存规则。如果你的项目有 50 个以上的规则文件，启动速度会明显加快——我们在测试套件中测得速度提升了 3 倍。

起草流程

1. 分析第 5 步预览中的提交列表，找出 2–5 个对用户重要的主题。
2. 撰写摘要并保存到 /tmp/release-summary-v${NEW_VERSION}.md。
3. 展示草稿，供用户审阅和批准后再应用。

# Write your draft here
cat > /tmp/release-summary-v${NEW_VERSION}.md << 'SUMMARY_EOF'
{your_enhanced_summary}
SUMMARY_EOF

cat /tmp/release-summary-v${NEW_VERSION}.md

向用户展示草稿： > “这是我起草的版本摘要。它会显示在版本说明顶部，位于自动生成的提交变更日志和贡献者致谢之上。”

审批关卡（同一个关卡）： 初始发布确认也涵盖此步骤。展示草稿后，立即继续执行第 7 步（应用）和第 7.5 步（Discord）。除非用户明确要求在发布开始前暂停，等待审阅版本说明，否则不要停下来等待批准。Discord 公告（第 7.5 步）是强制步骤；如果用户从未要求暂停审阅，就不得因此受阻。

---

第 7 步：将增强版摘要应用到版本发布

此步骤为强制步骤。必须始终应用第 6 步中的增强版摘要。

最终版本说明结构：

┌─────────────────────────────────────┐
│  Enhanced Summary (from Step 6)     │  ← You wrote this
│  - Theme-based, user-impact focused │
├─────────────────────────────────────┤
│  ---  (separator)                   │
├─────────────────────────────────────┤
│  Auto-generated Commit Changelog    │  ← Workflow wrote this
│  - feat/fix/refactor grouped        │
│  - Contributor thank-you messages   │
└─────────────────────────────────────┘

- **首先**获取现有版本正文 - 将你的摘要**置于其上方** - 现有的自动生成内容必须 **100% 保持原样** - 不得删除或修改现有内容中的**任何字符**

# 1. Fetch existing auto-generated body
EXISTING_BODY=$(gh release view "v${NEW_VERSION}" --json body --jq '.body')

# 2. Combine: enhanced summary on top, auto-generated below
{
  cat /tmp/release-summary-v${NEW_VERSION}.md
  echo ""
  echo "---"
  echo ""
  echo "$EXISTING_BODY"
} > /tmp/final-release-v${NEW_VERSION}.md

# 3. Update the release (additive only)
gh release edit "v${NEW_VERSION}" --notes-file /tmp/final-release-v${NEW_VERSION}.md

# 4. Confirm
echo "✅ Release v${NEW_VERSION} updated with enhanced summary."
gh release view "v${NEW_VERSION}" --json url --jq '.url'

---

步骤 7.5：将发布说明发送到 DISCORD

发布说明最终确定后，将其发送到 Discord 频道。每次发布都必须执行此步骤。

只有满足以下任一条件，工作流才算完成： 1. 成功发送 Discord 消息并记录消息 ID；或 2. 在执行 `agent-discordbot auth status` 并重试发送一次后仍然失败，同时向用户报告发布机器人令牌故障。

切勿因为发布摘要正等待批准而跳过此步骤。如果用户已确认发布，请继续完成 Discord 步骤后再停止。

1. 使用 `agent-discordbot` 的发布机器人令牌发布公告。这是规定的发布路径；除非机器人路径不可用且用户明确批准回退方案，否则不要使用个人 `agent-discord` 令牌。固定机器人 ID，确保发布消息由发布机器人发送，即使本地 `agent-discordbot` 当前机器人发生变化。 ```bash RELEASE_BOT_ID=1486173823354146917 agent-discordbot auth status --bot "$RELEASE_BOT_ID" ```

2. 读取频道中的近期消息，以匹配现有公告风格：

RELEASE_BOT_ID=1486173823354146917
agent-discordbot message list 1454708427392680067 --bot "$RELEASE_BOT_ID" --limit 5

3. 如果 agent-discordbot 不可用或未经授权，请停止并报告发布机器人令牌路径失败。只有此时，才可由人工决定是否使用 agent-discord。

4. 在频道 1454708427392680067 中发布公告，格式需与之前的公告一致。消息应遵循以下结构：

@here

🎉 **oh-my-opencode v{VERSION} — {Short Tagline}**

**Feature 1** — one-line description.

**Feature 2** — one-line description.

**Feature 3** — one-line description.

Plus {summary of remaining changes}.

📦 Install / upgrade:
`bun i -g oh-my-opencode@{VERSION}`  (or `npm`)

📝 Full release notes: {RELEASE_URL}

RELEASE_BOT_ID=1486173823354146917
RELEASE_URL=$(gh release view "v${NEW_VERSION}" --json url --jq '.url')
agent-discordbot message send 1454708427392680067 "{your message following the style above}" --bot "$RELEASE_BOT_ID"

如果消息发送失败，请提醒用户并继续；不要因 Discord 错误而阻止发布工作流。

---

步骤 8：验证 NPM 发布

轮询 npm 注册表，直到出现新版本：

npm view oh-my-opencode version

与预期版本进行比较。如果 2 分钟后仍不匹配，请提醒用户 npm 传播可能延迟。

---

步骤 8.5：抽查平台二进制包

平台包由同一次发布运行中的 publish-platform 作业构建并发布——无需等待其他工作流，而且 publish-main 已会拒绝在缺少匹配平台二进制文件时发布。抽查有代表性的一组包：

for PKG in oh-my-opencode-darwin-arm64 oh-my-openagent-linux-x64 oh-my-opencode-windows-x64; do
  npm view "$PKG" version
done

每个包都应显示 ${NEW_VERSION}。如果不匹配，请提醒用户并指出运行中的 publish-platform 作业；不要自行重新运行任何内容。

---

步骤 9：最终确认

向用户报告发布成功，并提供：

• 新版本号
• GitHub 发布页面 URL：https://github.com/code-yeongyu/oh-my-opencode/releases/tag/v{version}
• npm 包 URL：https://www.npmjs.com/package/oh-my-opencode
• 平台包状态：抽查的平台包版本

---

错误处理

• 工作流失败：显示失败日志，并建议检查 Actions 选项卡
• 未找到发布：等待后重试，可能是传播延迟
• npm 尚未更新：npm 传播可能需要 1-5 分钟，请告知用户
• 权限被拒绝：用户可能需要使用 gh auth login 重新进行身份验证
• 平台作业失败：显示同一次运行中 publish-platform 作业的日志，指出失败的目标，然后停止——在这些作业通过之前，publish-main 会按设计保持阻塞状态

语言

用英语回复用户。