pre-publish-review

name	pre-publish-review
description	核弹级16代理预发布门禁。运行/get-unpublished-changes检测自上次npm发布以来的所有更改，为每个更改生成最多10个ultrabrain代理进行深入分析，调用/review-work（5个代理）进行整体审查，以及1个oracle进行整体发布合成。每次npm发布前使用。触发词：'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'。

Pre-Publish Review — 16代理发布门禁

发布到npm前的三层审查。每一层覆盖不同的角度 — 结合在一起可以捕获单个审查者无法发现的问题。

层级	代理	类型	检查内容
逐更改深入分析	最多10个	ultrabrain	每个逻辑更改组单独 — 正确性、边缘情况、模式遵循
整体审查	5个	review-work	目标遵循、QA执行、代码质量、安全、跨整个变更集的上下文挖掘
发布合成	1个	oracle	整体发布就绪状态、版本升级、破坏性更改、部署风险

---

阶段 0: 检测未发布的更改

首先运行/get-unpublished-changes。这是关于什么的单一真实来源。

skill(name="get-unpublished-changes")

此命令自动：

• 检测已发布的npm版本与本地版本
• 列出自上次发布以来的所有提交
• 读取实际差异（不仅仅是提交消息）来描述真实更改
• 按类型（feat/fix/refactor/docs）分组更改并附带范围
• 识别破坏性更改
• 建议版本升级（patch/minor/major）

保存完整输出 — 它直接馈入阶段1分组和所有代理提示。

然后捕获代理提示所需的原始数据：

# 提取版本（已在/get-unpublished-changes输出中）
PUBLISHED=$(npm view oh-my-opencode version 2>/dev/null || echo "not published")
LOCAL=$(node -p "require('./package.json').version" 2>/dev/null || echo "unknown")

# 代理的原始数据（差异、文件列表）
COMMITS=$(git log "v${PUBLISHED}"..HEAD --oneline 2>/dev/null || echo "no commits")
COMMIT_COUNT=$(echo "$COMMITS" | wc -l | tr -d ' ')
DIFF_STAT=$(git diff "v${PUBLISHED}"..HEAD --stat 2>/dev/null || echo "no diff")
CHANGED_FILES=$(git diff --name-only "v${PUBLISHED}"..HEAD 2>/dev/null || echo "none")
FILE_COUNT=$(echo "$CHANGED_FILES" | wc -l | tr -d ' ')

如果PUBLISHED是"not published"，这是首次发布 — 改用完整git历史。

阶段 1: 将更改解析为分组

以/get-unpublished-changes输出为起点 — 它已经按范围和类型分组。

分组策略：

1. 从已按feat/fix/refactor/docs和范围分类的/get-unpublished-changes分析开始
2. 按模块/区域进一步拆分 — 触及相同模块或功能区域的更改属于一起
3. 目标最多10个分组。如果提交少于10个，每个提交是自己的分组。如果逻辑区域超过10个，合并最小的分组。
4. 对于每个分组，提取：
   • 分组名称：简短描述标签（例如，"agent-model-resolution", "hook-system-refactor"）
   • 提交：提交哈希和消息的列表
   • 文件：此分组中更改的文件
   • 差异：完整差异的相关部分（git diff v${PUBLISHED}..HEAD -- {group files}）

---

阶段 2: 生成所有代理

一次启动所有代理。每个代理使用run_in_background=true。无顺序启动。

层级 1: Ultrabrain逐更改分析（最多10个）

对于每个更改分组，生成一个ultrabrain代理。每个只获取其部分的差异 — 不是整个变更集。

task(
  category="ultrabrain",
  run_in_background=true,
  load_skills=[],
  description="Deep analysis: {GROUP_NAME}",
  prompt="""
<review_type>逐更改深入分析</review_type>
<change_group>{GROUP_NAME}</change_group>

<project>oh-my-opencode (npm包)</project>
<published_version>{PUBLISHED}</published_version>
<target_version>{LOCAL}</target_version>

<commits>
{GROUP_COMMITS — 此分组中每个提交的哈希和消息}
</commits>

<changed_files>
{GROUP_FILES — 此分组中更改的文件}
</changed_files>

<diff>
{GROUP_DIFF — 仅此分组文件的差异}
</diff>

<file_contents>
{读取并包含此分组中每个更改文件的完整内容}
</file_contents>

您正在审查准备进入npm发布的更改的特定子集。专注于此更改分组。其他分组由并行代理审查。

分析清单：

1. **意图清晰度**：此更改试图做什么？从代码和提交消息中意图是否清晰？如果需要猜测，那就是一个发现。

2. **正确性**：跟踪3+种场景的逻辑。代码是否真的做了它声称的？边界错误、空处理、异步边缘情况、资源清理。

3. **破坏性更改**：此更改是否改变了任何公共API、配置格式、CLI行为或钩子契约？如果是，是否向后兼容？现有用户会感到意外吗？

4. **模式遵循**：新代码是否遵循现有文件中可见的既定模式？存在旧模式的地方出现新模式 = 发现。

5. **边缘情况**：什么输入或条件会破坏这个？空数组、未定义值、并发调用、非常大的输入、缺失的配置字段。

6. **错误处理**：错误是否被正确捕获和传播？没有空的catch块？没有被吞掉的promise？

7. **类型安全**：有任何`as any`、`@ts-ignore`、`@ts-expect-error`吗？可以在严格类型的地方使用宽松类型？

8. **测试覆盖**：行为更改是否有测试覆盖？测试是有意义的还是仅仅是覆盖率填充？

9. **副作用**：此更改是否可能破坏不同模块中的东西？检查导入和导出 — 谁依赖于更改的东西？

10. **发布风险**：在SAFE / CAUTION / RISKY的尺度上 — 您对此更改不会在生产中造成问题的信心如何？

输出格式：
<group_name>{GROUP_NAME}</group_name>
<verdict>PASS 或 FAIL</verdict>
<risk>SAFE / CAUTION / RISKY</risk>
<summary>此更改分组2-3句评估</summary>
<has_breaking_changes>YES 或 NO</has_breaking_changes>
<breaking_change_details>如果是YES，描述什么被破坏以及针对谁</breaking_change_details>
<findings>
  对于每个发现：
  - [CRITICAL/MAJOR/MINOR] 类别：描述
  - 文件：路径（行范围）
  - 证据：具体代码引用
  - 建议：如何修复
</findings>
<blocking_issues>发布前必须修复的问题。如果PASS则为空。</blocking_issues>
""")

层级 2: 通过/review-work进行整体审查（5个代理）

生成一个加载/review-work技能的子代理。review-work技能内部启动5个并行代理：Oracle（目标验证）、unspecified-high（QA执行）、Oracle（代码质量）、Oracle（安全）、unspecified-high（上下文挖掘）。所有5个必须通过审查才能通过。

task(
  category="unspecified-high",
  run_in_background=true,
  load_skills=["review-work"],
  description="Run /review-work on all unpublished changes",
  prompt="""
对v{PUBLISHED}和HEAD之间未发布的更改运行/review-work。

目标：审查所有准备进入oh-my-opencode的npm发布的更改。这些更改跨越{COMMIT_COUNT}个提交，跨{FILE_COUNT}个文件。

约束：
- 这是一个发布到npm的插件 — 公共API稳定性很重要
- TypeScript严格模式、Bun运行时
- 无`as any`、`@ts-ignore`、`@ts-expect-error`
- 工具、钩子、代理的工厂模式（createXXX）
- kebab-case文件、桶导出、无一揽子文件

背景：oh-my-opencode的预发布审查，一个OpenCode插件，有1268个TypeScript文件，160k LOC。自v{PUBLISHED}以来的更改即将发布。

差异基线是：git diff v{PUBLISHED}..HEAD

严格遵循/review-work技能流程 — 启动所有5个审查代理并收集结果。不要跳过任何5个代理。
""")

层级 3: Oracle发布合成（1个代理）

oracle获得全貌 — 所有提交、完整差异统计和更改的文件列表。它提供最终的发布就绪状态评估。

task(
  subagent_type="oracle",
  run_in_background=true,
  load_skills=[],
  description="Oracle: overall release synthesis and version bump recommendation",
  prompt="""
<review_type>发布合成 — 整体评估</review_type>

<project>oh-my-opencode (npm包)</project>
<published_version>{PUBLISHED}</published_version>
<local_version>{LOCAL}</local_version>

<all_commits>
{自发布版本以来的所有提交 — 哈希、消息、作者、日期}
</all_commits>

<diff_stat>
{DIFF_STAT — 更改的文件、插入、删除}
</diff_stat>

<changed_files>
{CHANGED_FILES — 修改文件路径的完整列表}
</changed_files>

<full_diff>
{FULL_DIFF — 已发布版本和HEAD之间的完整git差异}
</full_diff>

<file_contents>
{读取并包含关键更改文件的完整内容 — 专注于公共API表面、配置模式、代理定义、钩子注册、工具注册}
</file_contents>

您是npm发布前的最终门禁。10个ultrabrain代理正在审查单个更改，5个review-work代理正在进行整体审查。您的工作是那些专注的审查可能会错过的鸟瞰视图。

合成清单：

1. **发布一致性**：这些更改是否讲述了一个连贯的故事？还是这应该是分成多个发布的一堆不相关的更改？

2. **版本升级**：基于semver：
   - PATCH：仅bug修复，无行为更改
   - MINOR：新功能，向后兼容的更改
   - MAJOR：公共API、配置格式或行为的破坏性更改
   用具体理由推荐正确的升级。

3. **破坏性更改审计**：详尽列出可能破坏现有用户的每个更改。检查：
   - 配置模式更改（新必填字段、移除字段、重命名字段）
   - 代理行为更改（不同提示、不同模型路由）
   - 钩子契约更改（新参数、移除钩子、重命名钩子）
   - 工具接口更改（新必填参数、不同返回类型）
   - CLI更改（新命令、更改标志、不同输出）
   - 技能格式更改（SKILL.md模式更改）

4. **迁移要求**：如果有破坏性更改，用户需要什么迁移步骤？是否有自动迁移？

5. **依赖更改**：添加了新依赖？移除了依赖？版本升级？任何供应链风险？

6. **变更日志草稿**：按以下内容编写变更日志条目草稿：
   - feat：新功能
   - fix：bug修复
   - refactor：内部更改（无用户影响）
   - breaking：带迁移说明的破坏性更改
   - docs：文档更改

7. **部署风险评估**：
   - SAFE：例行更改、充分测试、低风险
   - CAUTION：重大更改但可管理的风险
   - RISKY：大面积更改、测试不足或没有迁移的破坏性更改
   - BLOCK：发现关键问题，不要发布

8. **发布后监控**：发布后应该监控什么？错误率、特定功能、用户反馈渠道。

输出格式：
<verdict>SAFE / CAUTION / RISKY / BLOCK</verdict>
<recommended_version_bump>PATCH / MINOR / MAJOR</recommended_version_bump>
<version_bump_justification>为什么这个升级级别</version_bump_justification>
<release_coherence>更改是否属于一次发布的评估</release_coherence>
<breaking_changes>
  详尽列表，如果没有则写"None"。
  对于每个：
  - 什么更改
  - 谁受影响
  - 迁移步骤
</breaking_changes>
<changelog_draft>
  可直接使用的变更日志条目
</changelog_draft>
<deployment_risk>
  整体风险评估及具体问题
</deployment_risk>
<monitoring_recommendations>
  发布后要关注什么
</monitoring_recommendations>
<blocking_issues>发布前必须修复的问题。如果SAFE则为空。</blocking_issues>
""")

---

阶段 3: 收集结果

当代理完成时（系统通知），通过background_output(task_id="...")收集。

在表格中跟踪完成情况：

#	代理	类型	状态	判定
1-10	Ultrabrain: {group_name}	ultrabrain	pending	—
11	Review-Work Coordinator	unspecified-high	pending	—
12	Release Synthesis Oracle	oracle	pending	—

在所有代理完成之前不要交付最终报告。

---

阶段 4: 最终判定

<verdict_logic>

BLOCK如果：

• Oracle判定为BLOCK
• 任何ultrabrain发现CRITICAL阻塞问题
• review-work在任何MAIN代理上失败

RISKY如果：

• Oracle判定为RISKY
• 多个ultrabrain返回CAUTION或FAIL
• review-work通过但有重大发现

CAUTION如果：

• Oracle判定为CAUTION
• 一些ultrabrain标记了轻微问题
• review-work干净通过

SAFE如果：

• Oracle判定为SAFE
• 所有ultrabrain通过
• review-work通过

</verdict_logic>

编译最终报告：

# Pre-Publish Review — oh-my-opencode

## Release: v{PUBLISHED} -> v{LOCAL}
**Commits:** {COMMIT_COUNT} | **Files Changed:** {FILE_COUNT} | **Agents:** {AGENT_COUNT}

---

## Overall Verdict: SAFE / CAUTION / RISKY / BLOCK

## Recommended Version Bump: PATCH / MINOR / MAJOR
{Oracle的理由}

---

## Per-Change Analysis (Ultrabrains)

| # | Change Group | Verdict | Risk | Breaking? | Blocking Issues |
|---|-------------|---------|------|-----------|-----------------|
| 1 | {name} | PASS/FAIL | SAFE/CAUTION/RISKY | YES/NO | {count or "none"} |
| ... | ... | ... | ... | ... | ... |

### Blocking Issues from Per-Change Analysis
{从所有ultrabrains聚合 — 去重}

---

## Holistic Review (Review-Work)

| # | Review Area | Verdict | Confidence |
|---|------------|---------|------------|
| 1 | Goal & Constraint Verification | PASS/FAIL | HIGH/MED/LOW |
| 2 | QA Execution | PASS/FAIL | HIGH/MED/LOW |
| 3 | Code Quality | PASS/FAIL | HIGH/MED/LOW |
| 4 | Security | PASS/FAIL | Severity |
| 5 | Context Mining | PASS/FAIL | HIGH/MED/LOW |

### Blocking Issues from Holistic Review
{从review-work聚合}

---

## Release Synthesis (Oracle)

### Breaking Changes
{从Oracle — 详尽列表或"None"}

### Changelog Draft
{从Oracle — 可直接使用}

### Deployment Risk
{从Oracle — 具体问题}

### Post-Publish Monitoring
{从Oracle — 要关注什么}

---

## All Blocking Issues (Prioritized)
{去重，合并自三层，按严重性排序}

## Recommendations
{如果BLOCK/RISKY：需要修复的确切内容，按优先级排序}
{如果CAUTION：发布前值得考虑的建议}
{如果SAFE：未来非阻塞的改进}

---

反模式

违反	严重性
不等待所有代理完成就发布	CRITICAL
顺序生成ultrabrain而不是并行	CRITICAL
对任何代理使用run_in_background=false	CRITICAL
跳过Oracle合成	HIGH
不为Oracle读取文件内容（它无法读取文件）	HIGH
将所有更改分组到1-2个ultrabrain而不是分配	HIGH
在所有代理完成之前交付判定	HIGH
在ultrabrain提示中不包含差异	MAJOR