review

审查

以项目原则为依据，进行全面、交互式的审查。不要进行任何更改——审查结果就是交付物。

自主会话模式

当此技能在非交互式 Noodle 执行会话中运行时（例如 Cook、Oops 或 Repair）：

• 不要使用 AskUserQuestion。 对于发现的每个问题，直接说明建议采取的行动，而不是提供选项。
• 将发现写入报告文件 brain/audits/review-<date>-<subject>.md，并在会话输出中一并呈现。
• 对于高严重性问题，使用 /todo 技能在 brain/todos.md 中创建待办事项。
• 对于低严重性问题，在报告中注明，但不要单独创建待办事项。
• 最后提交审查报告。不要等待指示。

使用 Tasks 跟踪进度。 为下方每个步骤创建一个任务（TaskCreate），开始时将其标记为 in_progress，完成后标记为 completed。每个步骤之后都检查 TaskList。

步骤 1 — 加载原则

阅读 brain/principles.md。遵循其中的每个 [[wikilink]] 并阅读所有关联的原则文件。这些原则是审查判断的依据——评估问题时请回顾相关原则。

不要跳过此步骤。不要依赖记忆中的原则内容——每次都必须重新阅读。

步骤 2 — 确定范围

根据上下文推断审查对象——用户消息、近期差异或引用的计划/PR。如果确实无法判断（没有任何线索），请询问。

根据更改规模自动检测审查模式：

• 重大更改（更改 50 行以上、涉及 3 个以上文件，或引入新架构）——检查所有章节，每个章节最多列出 4 个主要问题
• 小型更改（低于上述门槛）——每个章节列出一个问题

步骤 3 — 收集上下文

对于小型更改审查，直接在主上下文中阅读文件——委派任务的开销高于阅读少量文件的成本。对于重大更改审查，通过 Task 工具将代码探索委派给子 Agent。

启动探索 Agent（subagent_type: Explore）以：

• 阅读待审查的代码或计划
• 识别依赖项、调用方和下游影响
• 梳理相关类型、测试和基础设施

调查相互独立的领域时，并行运行多个 Agent。

步骤 4 — 收集领域技能

检查已安装的技能（.claude/skills/），查看是否有与审查领域匹配的技能。常见匹配项：

领域	技能	适用场景
前端 UI	frontend-design	Web UI 组件、布局、视觉设计
Codex 委派	codex	委派给 Codex 工作器的任务

对于上方未列出的领域，使用 find-skills 搜索相关技能。

立即调用匹配的技能——阅读其输出，并在审查中参考领域指导。

步骤 5 — 审查章节

逐一检查所有章节，然后提交完整审查结果。如有需要，用户可以在过程中调整方向。

1. 架构

• 系统设计与组件边界
• 依赖关系图与耦合
• 数据流模式与瓶颈
• 扩展特性与单点故障
• 安全架构（身份验证、数据访问、API 边界）

2. 代码质量

• 代码组织与模块结构
• DRY 违规——严格检查
• 错误处理模式与遗漏的边界情况（请明确指出）
• 技术债务热点
• 相对于基础思维原则而言的过度设计或设计不足；考虑从第一性原理重新设计

3. 测试

• 覆盖率缺口（单元、集成、端到端）
• 测试质量与断言力度
• 遗漏的边界情况覆盖——务必全面
• 未经测试的故障模式与错误路径

4. 性能

• N+1 查询与数据库访问模式
• 内存使用方面的隐患
• 缓存机会
• 缓慢或复杂度较高的代码路径

步骤 6 — 问题格式

为每个问题编号（1、2、3……）。对于每个问题：

• 结合文件和行号，具体描述问题
• 提供 2–3 个带字母（A、B、C）的选项，在合理的情况下包括“什么也不做”
• 针对每个选项，说明实施工作量、风险、对其他代码的影响以及维护负担
• 给出推荐选项及理由，并将其对应到基础思维原则
• 询问用户是否同意，或是否希望采用其他方向

使用 AskUserQuestion 时，为每个选项标注问题编号和选项字母。始终将推荐选项放在第一位。

交互规则

• 不要假设时间安排或规模上的优先级
• 不要进行任何更改——展示发现并等待指示
• 一次性展示所有部分，然后在最后统一征求反馈
• 根据“验证可行性”原则：如果某项内容可以测试，请在问题描述中说明测试方法