Review Summary

Review Summary

Verdict: APPROVE | REQUEST CHANGES

Overview: [1-2 句话概括改动与整体评估]

Critical Issues

• [文件:行号] [描述与建议的修复方案]

Required Changes

• [文件:行号] [描述与建议的修复方案]

Optional

• [文件:行号] [描述]

Nits

• [文件:行号] [描述]

What's Done Well

• [正向观察 —— 至少包含一条]

Verification Story

• Tests reviewed: [yes/no, 观察]
• Build verified: [yes/no]
• Security checked: [yes/no, 观察]

模板里有两个容易被忽略但很关键的约束:其一,**每条 Critical 与 Required 发现都必须带具体修复建议**(见下文规则 3);其二,**必须包含至少一条"What's Done Well"**——具体地肯定做得好的地方,这是技能"评审中的诚实"一节明确的行为准则,也是人格规则第 5 条。

## 四、评审规则(Rules)

人格末尾的六条规则,定义了"怎样才算认真评审":

1. **先评审测试** —— 测试揭示了意图与覆盖度;
2. **先看规格或任务描述,再评审代码** —— 没有参照系,正确性无从谈起;
3. **每条 Critical 与 Required 发现都给出具体修复建议** —— 只说"有问题"等于让作者猜;
4. **绝不批准带 Critical 问题的代码**;
5. **肯定做得好的部分** —— 具体的表扬能激励良好实践;
6. **不确定就明说**,建议去调查而不是瞎猜。

其中规则 1、2 与技能"Review Process"中的 Step 1(理解上下文)、Step 2(先评审测试)完全对齐;规则 3 与"结构性补救"原则(提出搬移方案而非只提问题)呼应;规则 6 则直接对应技能"评审中的诚实"里"Don't soften real issues"与"接受合理覆盖(override)时保持礼貌"。

## 五、组合与编排(Composition)

这是理解该人格在整个仓库里位置的关键,原文档明确写了三段式组合契约:

- **直接调用**:当用户要求评审某个具体改动、文件或 PR 时;
- **通过命令调用**:`/review`(单视角评审)或 `/ship`(与 `security-auditor`、`test-engineer` 并行 fan-out);
- **绝不由另一个人格调用**。如果你发现自己想委托给 `security-auditor` 或 `test-engineer`,应把这一点作为**建议**写进报告,而不是自己去调——编排属于斜杠命令,不属于人格。

这一条"人格不调用人格"是 agent-skills 的硬性治理规则。在 [docs/agents.md](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/docs/agents.md?utm_source=gitcode_repo_files) 与 [references/orchestration-patterns.md](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/references/orchestration-patterns.md?utm_source=gitcode_repo_files) 中,它被反复强调:用户(或斜杠命令)才是编排者,技能是人格工作流里"必经的跳点"。之所以禁止人格互相调用,原因是:人格被设计为只产出单一视角,链式调用会丢失上下文、放大故障模式、并隐藏成本。因此 `code-reviewer` 若发现某个改动需要更深的审计,正确做法是在报告里"推荐一次后续安全审计",由用户或命令发起第二遍——正如 [agents/security-auditor.md](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/agents/security-auditor.md?utm_source=gitcode_repo_files) 的组合块所写的反向约定。

### `/review`:单人格命令

[commands/review.toml](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/commands/review.toml?utm_source=gitcode_repo_files) 是最直接的人格封装,它调用 `code-review-and-quality` 技能,对"当前改动(staged 或近期提交)"跑五轴评审,并要求:

- 把发现归类为 Critical / Important / Suggestion;
- 输出带 `文件:行号` 与修复建议的结构化评审;
- 在安全轴调用 `security-and-hardening`,在性能轴调用 `performance-optimization`。

这对应编排模式目录里的"单人格局部命令"——成本与直接调用相同,斜杠命令只是"存下来的提示词"。

### `/ship`:并行 fan-out 编排器

[commands/ship.toml](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/commands/ship.toml?utm_source=gitcode_repo_files) 展示了 `code-reviewer` 如何进入多智能体流水线。`/ship` 是**并行 fan-out 编排器**:它在**同一个助手轮次内**并发派发三个人格(顺序调用会让并行失去意义),再由主智能体合并报告:

/ship ├── (并行) code-reviewer → 五轴评审报告 ├── (并行) security-auditor → 安全审计报告 └── (并行) test-engineer → 覆盖度分析报告 ↓ 合并阶段(主智能体) ↓ go/no-go 决策 + 回滚计划

并行之所以成立,是因为三个人格"对同一 diff 产出不同视角、彼此无共享可变状态、无顺序依赖"。合并阶段主智能体要处理:聚合 Critical/Important 发现并去重、把安全审计的 Critical/High 提升为上线阻断项、交叉核对性能轴、以及补充三个人格都没覆盖的无障碍与基础设施检查。规则里还有一条很实用的跳过判据:**仅当改动不超过 2 个文件、diff 小于 50 行、且不涉及 auth/支付/数据访问/配置时**才跳过 fan-out;否则一律跑并行评审——`/ship` 面向的是生产级改动。

人格文档里的决策矩阵与这条编排完全一致:

工作是对单个工件的单一视角吗? ├── 是 → 直接调用人格 └── 否 → 子任务是否独立(无共享可变状态、无顺序)? ├── 是 → 带并行 fan-out 的斜杠命令(如 /ship) └── 否 → 用户依次运行的斜杠命令(/spec → /plan → /build → /test → /review)