用途：为代码审查提供固定的操作顺序与输出格式。当用户要求审查 pull request、diff 或补丁，或需要评估变更能否合并、部署，或需要对审查意见分级排序、为团队定义审查标准时使用。判断标准本身可参考 code-review-expert 技能，本技能侧重流程与输出形态。
主要能力：按顺序审查，避免把全部精力花在命名上而漏掉并发缺陷；正确性与安全性优先，风格最后。每条意见标注严重程度：Blocking（错误、不安全或丢数据，不可合并）、Important（应改但非正确性风险，由作者决定）、Minor（改进或带理由的偏好，可选）、Question（审查者尚未理解，待回答后可能重新分类）。提出问题时须给出导致失败的输入、状态或序列，而非仅凭感觉断言。只审查本次变更，不把既有问题当作合并条件，可另记为后续事项。
使用方式：先建立上下文，例如 gh pr view 482、gh pr diff 482 --name-only、git log --oneline main..HEAD、gh pr checks 482；再评估影响范围，如 gh pr diff 482 --stat、git diff main...HEAD -- '.sql' '.d.ts' 'openapi.'、grep -rn "functionYouChanged" --include='.ts' src/；随后依次检查正确性（边界值、并发与重试、错误处理、失败中途的状态一致性、测试是否覆盖行为）、安全性（按对象鉴权、服务端正向校验、参数化查询、密钥不入代码与日志、错误失败关闭、新依赖是否必要且锁定）、设计与可维护性、测试，并在成本低时验证声明，如 gh pr checkout 482、npm test、npm run typecheck && npm run lint、git diff main --stat。最后先给结论，再列排序后的发现，最后指出做得好的地方。
适用场景与限制：适合团队统一审查流程、审查 PR 与补丁、对反馈分级。建议审查小变更（约 400 行以上缺陷检出率下降），一个工作日内响应，风格交给 CI 的格式化与 lint 工具，两轮后升级为对话。资料未提供具体安装方式、收费与平台支持信息。