用途：当用户分享代码（文件、片段或 diff）并请求反馈，或粘贴 pull request、询问代码是否可上线、做合并前质量门禁或排查缺陷时使用。也可用于审查 PR 中的架构决策。
主要能力：按五步法逐级推进。第一步理解并复述 PR 目的，不清楚先提问；第二步评估架构与设计模式，判断代码是否放在正确模块、抽象是否适度、是否与现有代码库模式一致；第三步检查细节，包括正确性（逻辑错误、边界、空值、竞态）、安全（OWASP Top 10 基线）、性能（N+1 查询、多余重渲染、大数据集 O(n^2)、缓存缺失、内存泄漏）、命名与清晰度；第四步以同等严格度审查测试，关注行为断言、边界与错误路径、测试是否脆弱、缺失用例；第五步输出按优先级分类的报告，并明确肯定良好实践。
输出格式：包含 Summary、Findings（Critical/Major/Minor/Positive 四级，每条标注文件与行号、原因、具体修复建议）、Questions、Suggested Tests。严重度定义中，Critical 为安全漏洞、数据丢失、生产崩溃或核心功能损坏，应阻止合并；Major 为显著缺陷、性能回退、关键路径缺错误处理或架构违规，应在合并前修复；Minor 为风格、命名、小优化或文档缺口；Positive 用于肯定优秀代码。
使用方式：需提供待审查代码或 diff、代码预期用途、具体关注点（性能、安全、正确性），以及语言与框架（若不明显）。
限制与原则：反馈必须落到具体文件、行号与可执行改进；明确肯定良好工作；对非显然的设计选择先询问作者理由再提替代方案；风格问题交给 CI 自动化工具，不阻塞合并；测试审查与代码审查同等重要。可关联 security-review 做深度安全审计，或关联 architecture-design 处理结构性重构。具体安装命令与收费方式暂未提供。