Assay（代码审查）
使用此技能执行本地的、基于质量门的静态代码审查。审查按顺序打开质量门；如果低级别的门失败，则会阻止更高级别的门，因为在基本卫生、命名或错误处理已经出问题时，后续的判断没有意义。
此技能不调用远程服务、不发表评论、不批准代码，也不修改文件。它审查本地或粘贴的输入，并生成结构化报告。
工作流
阶段 0：解析本地输入
将用户的输入归一化为审查范围：
| 输入 | 解析方式 |
|---|---|
| 粘贴的代码或 diff | 直接审查提供的内容 |
| 本地文件路径 | 读取完整文件内容；除非有可用 diff 上下文，否则无 diff 上下文 |
| 本地 git diff | 审查变更的文件和块 |
| 提交哈希或范围 | 如果可用，使用本地 git diff |
| 分支名称 | 如果可用，使用本地 merge-base diff |
| 含糊请求 | 要求提供文件、diff、提交/范围、分支或粘贴的代码 |
不要获取 MR/PR 数据、调用远程 API 或要求认证。如果需要远程上下文，请要求用户提供本地 diff 或粘贴的内容。
阶段 1：校准审查深度
选择要打开多少个门。对于普通本地变更，默认使用门 1-5。
| 上下文 | 门范围 |
|---|---|
| 草稿、进行中、探索性代码 | 门 1-3 |
| 普通功能或内部工具 | 门 1-5 |
| 共享库、生产路径或公共 API | 门 1-7 |
| 安全敏感代码、认证、加密、命令执行或用户输入边界 | 门 1-8 |
当不确定时，询问代码的目标或风险级别。
阶段 2：大范围分类
当审查范围包含超过 5 个文件时，在深入检查之前进行快速分类。对于 5 个或更少的文件，跳过分类直接进入结构提取。
分类检查：
| # | 检查项 | 失败信号 |
|---|---|---|
| 1 | 死代码 | 注释掉的代码、未使用的导入、调试输出 |
| 2 | 命名清晰度 | 公共名称模糊或误导 |
| 3 | 嵌套深度 | 嵌套超过 3 层 |
| 4 | 函数长度 | 函数长到隐藏了多个职责 |
| 5 | 错误吞噬 | 空的 catch/except 或忽略的失败 |
| 6 | 领域混合 | I/O 和业务逻辑混在一个单元中 |
| 7 | 原始字段组装 | 复杂条件缺少语义辅助函数 |
| 8 | 重复迹象 | 相似逻辑反复出现 |
| 9 | 安全问题 | 密钥、不安全插值、敏感日志、未检查的危险输入 |
对文件进行分类：
| 类别 | 标准 | 下一步行动 |
|---|---|---|
| 红色 | 3 个或更多检查失败 | 完整门检查 |
| 黄色 | 1-2 个检查失败 | 检查目标门及其下所有门 |
| 绿色 | 0 个检查失败 | 除非特别要求，否则通过 |
安全问题采用双轨制：即使门 8 被更低级别的门阻塞，也要将其报告为分类警告。
阶段 3：结构提取
在打开门之前，为每个被审查的函数、类、模块或相关代码单元提取结构。使用提取结果来指导门审查；不要仅依赖原始 diff 文本。
记录以下内容：
- 闭包、回调或嵌套函数。
- 具有行为的内联对象或本地实体。
- I/O 操作和外部副作用。
- 最深嵌套及其原因。
- 领域分布：基础设施、业务、展示或混合。
- 生命周期：一次性、持久或混合。
- 捕获的变量和隐藏的依赖。
- 提取过程中发现的明显异常。
- 门 6 的可用事实依据：找到任何规范或治理文档
（
openspec/、PROJECT.md、AGENTS.md、ADRs、关联的 issue）来评判逻辑， 或注明未找到。
阶段 4：顺序门审查
阅读 references/gates.md 了解门定义。
按顺序打开门。如果一个门失败，则停止为该文件或审查范围打开更高级别的门。不要编造发现。沉默表示细节部分合规；门索引仍记录哪些门已打开、通过、失败或被阻塞。
阶段 5：报告
使用以下格式生成报告：
## 审查记录
**来源**：[输入引用]
**校准**：门 1-[N]（[原因]）
**分类**：[跳过 | 红色 M / 黄色 N / 绿色 K]
**结论**：[通过 | 在门 N 失败]
### 门索引
| 门 | 关注点 | 状态 |
|---:|---|---|
| 1 | 格式与语法卫生 | [通过 | 失败 | 阻塞 | 未检查] |
| 2 | 命名与可读性 | [通过 | 失败 | 阻塞 | 未检查] |
| 3 | 错误处理与可观测性 | [通过 | 失败 | 阻塞 | 未检查] |
| 4 | 控制流与结构清晰度 | [通过 | 失败 | 阻塞 | 未检查] |
| 5 | 职责与边界 | [通过 | 失败 | 阻塞 | 未检查] |
| 6 | 业务逻辑完整性 | [通过 | 失败 | 阻塞 | 未检查] |
| 7 | 去重与组合 | [通过 | 失败 | 阻塞 | 未检查] |
| 8 | 安全与参数完整性 | [通过 | 失败 | 阻塞 | 未检查] |
### 安全分类警告
[仅在分类检查 9 失败时包含]
### 门 N：[名称]
| # | 位置 | 违规说明 | 修正建议 |
|---|---|---|---|
| 1 | `文件:行号` | 门 N：具体违反的标准 | 具体的修正 |
### 结构附录
[包含与发现相关的代码单元摘要]
阶段 6：可选修复计划
仅在用户要求时才生成修复计划。
修复计划规则：
- 每个违规项一个修复。
- 修复顺序遵循门顺序。
- 在同一门内，按文件和行号顺序排列，除非逻辑依赖关系要求其他顺序。
- 无机会主义修复。
- 每个修复包含验证标准。
规则
- 仅审查；不修改代码。
- 仅使用本地或粘贴的输入；不调用远程 PR/MR API。
- 按顺序打开门，并在第一个失败的门处停止。
- 即使深度安全检查被阻塞，也要报告安全分类警告。
- 给出具体的修正；避免模糊的建议，例如“考虑改进”。
- 如果所有打开的门都通过，门索引就是报告；不要编造发现。
- 当未运行测试、构建或运行时检查时予以说明。
- 坚持本技能范围；在边界处移交。此技能仅为静态、本地审查。
对于运行时/行为正确性，请指向
verify；对于超出门 8 表面检查的深度安全分析， 请指向security-review。明确移交对象，而不是半途而废地执行其他技能的工作。