| name | ai-review |
| description | 使用 PaddlePaddle 仓库规则评审 Pull Request 和全仓库代码变更，覆盖正确性、兼容性、算子、分布式、数值、性能、安全、测试、构建和 PR 信息。当需要审查 Paddle 的代码、测试、算子 YAML、C++/CUDA/XPU kernel、Python API、分布式逻辑或 CI 配置时使用。 |
AI Review
评审 Paddle 代码的实际行为和跨模块影响。优先级、评论格式和发布策略由调用方决定；本 skill 只提供仓库级评审规则。
规则加载
开始评审前读取 .agents/skills/ai-review/references/ 下的全部 Markdown 文件，必须包含 基础规则。根据每个文件声明的适用路径和触发条件决定是否应用其他规则；不要仅因变更路径不同而跳过加载。
新增扩展规则时，在 references/ 下使用 kebab-case 文件名，并在文件开头写明适用路径、触发条件和可验证的规则来源。不要重复基础规则、评论格式或发布策略。
评审流程
- 阅读 PR 描述和完整 diff，确认变更目标、影响范围、兼容承诺和用户可见行为。
- 使用
rg 追踪定义、调用方、注册入口、配置入口、实现和测试；跨模块变更必须检查两端契约。
- 对照完整函数、相邻实现和现有测试验证候选问题，确认可复现或有明确代码证据后再报告。
- 评论指出具体位置、影响、触发条件和修改方向；不报告无依据的猜测、纯风格偏好或泛化建议。
- 按风险选择最接近变更的测试，并分别记录静态检查、CPU 验证和依赖 GPU/多卡/特定硬件的未完成验证。
更具体的扩展规则优先于基础规则；规则冲突且无法由代码或仓库约定判定时，向维护者确认。
适用的已有 Skill
涉及专门领域时同时读取对应 skill 的 references，并以实际源码为准：算子开发使用 paddle-op-dev，分布式设计使用 paddle-design-distributed，编译使用 paddle-build，调试使用 paddle-debug、paddle-design-compiler、paddle-eager-graph 或 paddle-phi-kernel。
基本原则
- 正确性、安全和兼容性优先于格式与命名。
- 分布式、算子和数值路径必须同时检查前向/反向、边界条件及回退路径。
- 行为变化必须有与风险匹配的单卡、多卡或设备覆盖；不能用 mock 掉被测逻辑的测试代替真实验证。
- 只依据源码、测试、文档和可复现的运行结果下结论；无法验证时明确说明环境限制。
