用途：对代码变更进行结构化、可操作的审查，适用于审查拉取请求或一组改动、合并前评估代码质量、审计模块技术债，以及建立审查标准或清单。
主要能力：按优先级从五个维度审查。一是正确性，检查代码是否实现其声称的功能、是否处理边界情况（空值、空集合、溢出、并发）、错误路径是否有测试、测试是否覆盖变更行为。二是安全，检查系统边界处的输入校验、代码中是否含密钥（API 密钥、密码、令牌）、是否防止 SQL/命令注入、认证与授权检查是否正确；更深入分析可参考 security-audit 技能。三是可读性，关注命名是否清晰、函数是否只做一件事、嵌套是否不超过三层、注释是否解释“为什么”而非“做什么”、风格是否与周边代码一致。四是可维护性，关注是否存在不必要的抽象、是否在避免过度抽象的前提下复用（三次法则）、依赖是否有正当理由、破坏性变更是否被标记。五是性能，仅在确有顾虑时指出（热路径、大数据量、N+1 查询），不做过早微优化。
使用方式：输出按固定格式组织，包含 Review 标题，以及 Must Fix、Should Fix、Consider、Positive 四类条目，每条指向具体文件与行号并标注维度。严重级别对应处理方式：Must Fix 为缺陷、安全问题或破坏契约，应阻止合并；Should Fix 为明显的可读性或可维护性问题，应请求修改；Consider 为可选改进或风格偏好，可批准并留言；Positive 用于指出值得肯定的良好模式。
限制与准则：反馈要具体，指向确切行并给出具体替代方案；解释原因而非只要求修改；将风格与实质分开，风格交给 linter 自动化，逻辑人工审查；限定范围，只审查变更内容而非整个文件（除非被要求）；至少给出一条正面观察；以建议而非命令的语气提出改进（Must Fix 除外）。