用途：对拉取请求或一组代码变更执行结构化、可落地的代码审查，可用于合并前质量评估、模块技术债审计，以及建立审查标准或检查清单。
审查维度（按优先级）：1. 正确性：代码是否实现其声称的功能，空值、空集合、溢出、并发等边界情况是否处理，错误路径与测试是否覆盖变更行为。2. 安全性：系统边界处的输入校验，代码中不得含密钥（API key、密码、token），防止 SQL/命令注入，检查身份认证与授权；更深入分析可参考 security-audit 技能。3. 可读性：变量、函数、类命名清晰，函数只做一件事，嵌套不超过 3 层，注释解释“为什么”而非“做什么”，风格与周边代码一致。4. 可维护性：避免不必要的抽象，遵循三次法则做到 DRY 但不过度抽象，依赖需有合理理由，破坏性变更需标记。5. 性能：仅在真实关注点（热路径、大数据、N+1 查询）时提出，除非上下文需要，不做微观优化。
输出格式：按“## Review: <PR 标题或文件>”组织，分 Must Fix（缺陷、安全问题或破坏契约，阻止合并）、Should Fix（重要可读性/可维护性问题，要求修改）、Consider（可选改进或风格偏好，可批准并评论）、Positive（值得肯定的良好模式）四部分；每条反馈标注文件名、行号、类别与具体建议。
指南：指出确切行号并给出具体替代方案；解释原因，如“这会因 Y 导致 X”，而非仅说“改一下”；将风格与实质分离，风格交给 linter 自动化，逻辑人工审查；限定范围，只审查变更内容而非整个文件（除非被要求）；至少给出一条正面观察；用建议语气“考虑使用 X”而非强制“必须使用 X”（Must Fix 除外）。