zuozh11 Code Review
对固定代码范围执行一次只读评审：
- Standards：检查项目工程规范，并判断改动是否选择了最小正确实现。
- Spec：检查实现是否符合 PRD、任务卡等已确认需求。
调用方或用户指定 --std / --spec 时，视为维度锁：只跑被锁定的维度。未锁维度时，由本 Skill 判断每条依据的适用性并归入 Standards 或 Spec，只启用有依据的维度。两个维度只共享固定代码范围，不共享依据或 finding。本 Skill 不修改代码、提交或远端状态。
1. 加载项目上下文
按项目知识协议使用相关 CONTEXT 与当前适用的 RULE。已有知识覆盖本次范围时复用，范围扩大时补充。知识不可用时继续并如实说明。
把约束代码结构、写法、测试或工程协作的内容归入 Standards；把约束系统行为、状态、数据、校验、权限或业务流程的内容归入 Spec。PRD、API 清单、任务卡、Issue 和当前对话中的已确认需求归入 Spec。每条依据只进入一个维度。历史、场景不匹配或被当前明确要求取代的内容不作为评审依据。
2. 固定评审范围
优先使用调用方或用户指定的 commit、branch、tag、range、PR 或路径，并记录实际 diff 命令和 commit 列表。分支使用 git diff <fixed-point>...HEAD。
调用方指定的 commit、range 或 pathspec 与用户指定同等优先。impl 传入单笔提交时，范围就是该 SHA，不使用分支 merge-base。
用户未明确固定点时：
- PR 编号或 URL：解析真实 base、head 和 patch；
- 当前分支：使用可确认的上游或默认分支 merge-base，无法确认时提问；
- 未提交改动：覆盖未暂存、已暂存和未跟踪文件；
- 文件或目录当前实现：完整读取 SNAPSHOT.md 固定文件列表和工作区状态。
用户指定路径时用同一 pathspec 限制范围。引用无效、diff 为空或 snapshot 无有效文件时停止。
3. Standards 快速评审
读取范围内生效的 AGENTS.md、CLAUDE.md 和适用的工程 RULE、其他工程规范、测试约定与模块约束。PRD、任务卡等需求不进入 Standards。
Standards 维度由一个 Standards 子 Agent 单次完成。主 Agent 先固定范围并准备全部工程规范，再把 diff、必要上下文和规范一次性交给它；子 Agent 逐个 changed hunk 阅读必要的调用者，只扩展到能够判断所有权、消费者和替代方案的范围。
先读取 MIN-IMPL.md，按阶梯停在第一项成立的位置。候选替代方案必须完整满足需求，并有可说明的正确性或维护收益。
修复缺陷时检查待修改位置的全部调用者：共同根因能够在真实所有者修复时，报告散落在调用者的补丁；不要以 diff 小为由接受错误层级。
不得仅凭代码味道或未来扩展可能性建议新类型、接口、多态、工厂、配置、wrapper、模块拆分或依赖注入。结构调整只有同时满足以下条件才成立：
- 当前存在可证明的维护或正确性影响；
- 删除、复用、标准库、平台原生和已安装依赖均不能解决；
- 替代方案减少净概念或把真实复杂度集中到正确所有者；
- 没有为单一实现创建可替换接口，也没有保留平行兼容层。
codebase-design 只在候选通过上述门槛且确实涉及必要模块形状时读取。用户显式要求、项目工程 RULE、信任边界校验、安全、无障碍和防止数据丢失的必要行为始终保留。
Standards 子 Agent 对每条加载的工程规范判定符合、不适用或违反，并返回完整覆盖状态；只把违反和具有具体影响的最小实现 finding 交给主 Agent。跳过纯偏好、无影响意见、工具已经确定性检查的问题和无法给出更小正确替代方案的建议。
4. Spec 评审
按以下顺序读取本次需求依据：
- 用户指定的 PRD、API 清单、任务卡、Issue、PR 或当前对话目标；
- 已加载且内容约束系统行为的 RULE；
- commit 或变更明确引用的需求来源；
- 与变更主题明确对应的本地需求文档。
CONTEXT 可帮助理解项目术语，但不代替需求来源。工程 RULE、当前代码和工程惯例不转成需求。没有可用需求依据时跳过 Spec，并如实说明。
Spec 只报告需求遗漏、错误行为和需求之外的 scope creep；命名、重复、架构和测试写法不进入 Spec。每条适用的已确认需求都在本轮内部判定为符合、不适用或违反。
调用方给出的候选 ruleId 与需求材料必须纳入分类，不得静默丢弃。判定不适用只允许四类可复核理由：历史、场景不匹配、被本次明确要求取代、不在本单元业务结果内；缺这类理由时保持适用。调用方声明本单元业务结果后，未纳入该结果的其余需求判不适用，不报遗漏。
需求材料在本提交中已被用户确认修正时，以修正后的文本为 Spec 依据。实现方私下的解释、注释或偏差记录不构成依据。Implementation Decisions 中来源为用户确认的授权例外，对应条款判定为不适用，并在覆盖状态中说明。
5. 执行与终检
只启用 Standards 时创建一个 Standards 子 Agent，只启用 Spec 时创建一个 Spec 子 Agent；两个维度同时启用时并行创建两者。每个子 Agent 只接收自己的完整依据和固定范围，一次返回工程规范或需求覆盖状态及候选 finding。
主 Agent 核实候选引用的代码、影响和本维度依据，删除不成立、越界或串用依据的候选，并确认适用规则已覆盖。缺少覆盖时只补核遗漏规则，不重复完整评审。
保留 finding 前必须同时确认：位置准确、影响具体、依据属于本维度、建议是最小正确方向。严重程度由终检结果确定：P0 阻断交付或造成重大事故，P1 高概率错误行为，P2 局部缺陷或明确维护风险，P3 低风险但有具体收益。
6. 输出
使用连续编号，内容保持紧凑：
评审范围：<固定点、diff 命令和路径>
本单元业务结果：<调用方声明；无则写「未声明」>
维度：
- Standards：启用 / 未启用（<依据列表>）
- Spec：启用 / 未启用（<依据或「无可用需求依据」>）
## Standards
- [STD-001] [P2] <delete/reuse/stdlib/native/dependency/shrink：问题> — `<文件:行>`
- 影响：<具体影响>
- 最小修复：<删除什么或使用什么替代>
工程规范：已覆盖 <来源列表>；<通过 / 存在上述违反 / 未完成>
## Spec
- [SPEC-001] [P1] <问题> — `<文件:行>`
- 需求依据：<需求来源及具体要求>
- 偏差：<遗漏、错误或 scope creep>
- 最小修复：<方向>
需求：已覆盖 <来源列表>；<通过 / 存在上述违反 / 未完成>
只输出启用的维度。没有 finding 时写「未发现问题」并停止，不制造改进意见，不估算净减少行数。