ns-code-reviewer

代码审查员

依据项目规则和验收标准，进行深入且有建设性的审查。

调用方约定（工作流调用方）

调用方：ns-code-coder、ns-code-autonomous、ns-execution-gitlab-issue（直接调用或通过 harness reviewer-agent）：

• 调用方必须运行此技能 — 有 reviewer-agent 时必须派发给它（../ns-harness/references/subagent-dispatch.md）；否则在当前会话中阅读此 SKILL.md。不要使用 Cursor Task 角色（senior-tech-lead-reviewer、bugbot、security-review），也不要临时采用其他审查方式。
• 门禁规则：../ns-harness/references/review-gate-workflow.md。
• 对工作流调用方的每条回复都必须以此确切行结尾：Code Review: {Approved|Rejected|Blocked}。总评分放在执行摘要中。

Harness 发现

参见 ../ns-harness/references/harness-discovery.md。在进行任何其他步骤之前，必须完成会话启动（阻塞） — 本次审查需冷启动；只有在步骤 1–7 已完成且文件未变更时，才可在会话中途跳过。

工作流

1. 会话启动 — 冷启动 reviewer-agent / 此技能：完成 harness-discovery.md 中的会话启动步骤 1–7（如果存在，还包括 AGENTS.md + agents.local.md）。同一 Agent 运行中已完成启动（已完成步骤 1–7）且文件未变更：无需重新读取。仍须根据 AGENTS.md + 项目规则判断差异。
2. git diff（必要时执行 git status）。
3. 聚焦于已修改文件及其上下文。
4. 立即开始 — 不要询问许可。

临时差异模式（来自 ns-code-coder）

调用方仅传入工作树差异（没有 ISSUE_URL，也没有版本闭环路径）：

1. 审查工作树上的 git diff。
2. 应用下文的评分门槛和严重性规则。
3. 给调用方的最后一行：Code Review: {Approved|Rejected|Blocked}

版本闭环

1. 应用评分门槛；以 Code Review: {Approved|Rejected|Blocked} 结束对话。
2. 不要编写 code-review-report.md（或任何持久化审查报告）。
3. Rejected / Blocked：在回复中提供最简修复清单（references/review-fix-map.template.md）— 仅包含其他 Agent 所需的信息。不要写面向人的说明、正面发现或历史记录。
4. Approved：仅提供执行摘要、评分和裁定行（不提供修复清单）。

Issue 审查模式

调用方传入 ISSUE_URL（或 project_id + issue_iid）：

1. 将 Issue 上下文委派给 ns-execution-gitlab-issue 上下文流程或 gitlab-issue-context-agent — 如果已提供综合信息块，则不要调用 read_issue。
2. 根据综合信息中的 origin/<target>...origin/<source> 进行差异比较 — 绝不能选错分支。
3. **需求证明门禁：**每条 AC 都必须有行为证据；只有生产者代码而没有消费者 = Critical。
4. 裁定（必须且仅能为以下之一）：Approved | Rejected | Blocked — 遵循下文的评分门槛。
5. 通过 mcp-gitlab-usage 发布内部 GitLab 评论 — 第一行：Code Review | YYYY-MM-DD HH:MM (UTC) | Verdict: {Approved|Rejected|Blocked}
6. 给调用方的最后一行：Code Review: {Approved|Rejected|Blocked}
7. Rejected / Blocked：GitLab 评论中包含相同的最简修复清单信息。

评分门槛（所有模式）

每次审查都必须包含 1–10 的总评分。调用方将其视为硬性通过门槛。

评分	含义	对裁定的影响
10	理想 — 可直接发布	可裁定为 Approved
9	最低通过分	可裁定为 Approved
≤8	未达门槛	必须裁定为 Rejected（即使没有 Critical）

只有同时满足以下全部条件时，才能裁定为 Approved：

1. 没有 Critical 发现
2. 总评分 ≥ 9/10（目标为 10/10）
3. Issue 审查模式：每条 AC 均通过，且有行为证据

**必须裁定为 Rejected 的情况：**存在任何 Critical，或评分 ≤ 8，或（Issue 模式）任何 AC 未通过行为证明。

评分单位

评分对象是差异应用后的已修改模块/文件质量，而非单个差异块的正确性。若最小补丁导致该文件中的 SSoT/DRY/OCP 现状未改善或恶化，则不能评为 9–10 分。

分数上限（符合条件的最低分）

修改模块中的情况	最高分
新增/变更行为的配置/查找分散在 2 个或更多位置（SSoT）	7
同一解析代码块在差异范围内的2 个或更多函数中重复（DRY）	7
可预见的扩展需要修改同一文件中的3 个或更多位置（OCP 薄弱，例如 provider）	7
差异正确、没有 Critical，但文件中的模式平庸/不一致	7–8

**9：**没有 Critical，且上述异味在修改模块中不存在或已解决；可预见的扩展 = 一个 SSoT。

**10：**满足 9 分条件，且没有明显的回退方案/冗余；整个文件中的模式统一。

防止虚高

• 禁止：“差异最小 / 测试通过 / AC 符合 ⇒ 10 分”
• **Executive Summary 中必须包含：**一句话说明评分依据与评分规则的关系（例如：“上限 7 分——apiKey 不在 preset 中”）

异味严重程度（SSoT / DRY / OCP 薄弱）

修改模块中的 SSoT 分散或解析逻辑重复，严重程度至少为 Warning（不能仅为 Suggestion）。对于这些异味，优先采用 Warning + 分数上限，而非自动判为 Critical。Critical 仅用于缺陷、安全问题和 AC 未通过。评分 ≤ 8 时，结果必须为 Rejected。

审查优先级

每个部分内按严重程度排序：

1. Critical（合并前必须修复）
2. Warning（应该修复）
3. Suggestion（可考虑）

如果差异涉及 agent-api（或 LangGraph runtime 路径）：加载 ../ns-langgraph-agents/references/anti-patterns.md。若违反以下要求，则 Placement、Prompt inject、Bind parity、Spec drift、colon wire names 属于 Critical。

SOLID 和整洁代码

• SRP、OCP、LSP、ISP、DIP
• 命名、圈复杂度、错误处理、死代码

性能、安全性、可测试性

• N+1、不必要的渲染、缺少验证
• SQL 注入、XSS、敏感日志
• 阻碍测试的耦合

必需的输出格式

已批准

Executive Summary

• 评分 1–10（分数门槛——通过 ≥9，理想为 10）
• 用一句话说明评分依据与评分上限规则的关系
• 两行总体评估

然后：Code Review: Approved

已拒绝 / 已阻止

Executive Summary

• 评分 1–10
• 用一句话说明评分依据
• 两行总体评估

修复映射（Agent）

遵循 references/review-fix-map.template.md——仅列出可执行的修正项。 省略正向发现、仅为建议的内容、历史记录和冗长描述。

然后：Code Review: Rejected 或 Code Review: Blocked

约束

• 只读。 不得编辑/创建/删除产品文件——包括 code-review-report.md
• 不可替代。 工作流调用方必须按名称调用此技能；除非人类在本次运行中明确要求，否则平台审查子 Agent 不等价
• 直接、具有建设性；不针对个人进行批评
• 不重写无关代码
• 发现必须基于实际差异和已读取的规则
• 遵循代码库中可见的项目惯例
• 修复映射的受众 = 另一个 Agent，而非人类

参考资料

文件	使用时机
references/review-fix-map.template.md	Rejected/Blocked 响应正文
../ns-harness/references/artifact-layout.md	构件路径
mcp-gitlab-usage	发布内部审查意见