pr-review

核心用法

pr-review 是一款面向 Pull Request 前置审查的代码分析工具，采用单次调用 Claude Opus 的策略，避免多代理编排的开销。支持两种工作模式：Diff 模式（对比当前分支与 main/master，仅审查变更文件）和 Audit 模式（指定路径、通配符或 --audit 全代码库扫描）。使用方式直观，如 /pr-review src/api/ 或 /pr-review --audit。

显著优点

• 效率优先：单次模型调用完成全量分析，成本低廉且延迟低
• 自动修复：Diff 模式自动修复评分≥70的问题，Audit 模式阈值提升至80，实现"审查即修复"
• 风险分级：90-100分（阻断级）、70-89分（重要级）、50-69分（仅报告），避免信息过载
• 智能上下文：自动读取项目规范（CLAUDE.md、eslintrc、tsconfig等），匹配现有代码风格
• 安全聚焦：Security 作为第二优先级检查项，覆盖注入、IDOR、密钥泄露等常见漏洞

潜在局限

• 非增量审查：Diff 模式不修复既有代码问题，可能导致"破窗效应"遗留技术债务
• 架构级盲区：明确声明不处理需要架构变更的问题，复杂设计缺陷需人工介入
• 测试文件限制：测试文件仅报告不修复，自动化测试覆盖提升有限
• 评分主观性：70/80/90分阈值缺乏量化标准，可能存在误杀或漏判
• 大文件限制：单次审查>50文件需用户确认，超大代码库场景受限

适合人群

• 高频提交的中高级开发者，需要在提交前快速自检
• 团队代码审查 bottleneck 严重的技术负责人，需分担人工 review 负载
• 安全左移实践者，希望在编码阶段捕获漏洞而非依赖 CI/CD 阶段扫描

常规风险

• 过度自动修复：高阈值自动修复可能引入语义变化，需配合 git diff 二次确认
• 模型幻觉：单次调用可能产生"看似合理"的错误修复建议，缺乏多模型交叉验证
• 机密泄露风险：审查流程中会读取文件内容，若项目含硬编码密钥可能被模型日志记录（需确认 OpenClaw 数据保留策略）

核心用法

PR Review 是一个面向代码审查场景的 Agent Skill，采用单遍审查模式（Single-pass Review），通过调用 Claude Opus 模型对代码变更进行高效分析。该技能提供两种工作模式：Diff 模式（针对当前分支与主分支的变更文件）和Audit 模式（针对指定路径或全代码库的主动审计）。用户可通过 /pr-review 命令快速触发，支持目录路径、文件模式匹配（如 **/*.ts）以及 --audit 参数实现灵活审查范围控制。

显著优点

效率优先的设计理念是最大亮点。区别于多 Agent 协作的复杂编排，该技能采用极简架构，避免了 orchestration overhead 和 agent swarm 的资源消耗，实现"快速、低成本、彻底"的审查目标。自动修复功能（Auto-Fix）可直接应用得分≥70/80的问题修复，显著缩短从发现问题到解决问题的路径。审查覆盖维度全面且优先级清晰：正确性（Correctness）> 安全性（Security）> 可靠性（Reliability）> 性能（Performance）> 代码质量（Quality），确保关键问题不被遗漏。评分分类机制（90-100 强制修复、70-89 建议修复、50-69 仅报告、<50 丢弃）实现了精准的问题分级处理。

潜在缺点与局限性

作为纯 Markdown 文档型技能，其执行效果高度依赖底层模型（Claude Opus）的能力，存在模型幻觉导致误判的风险。自动修复功能虽便捷，但对复杂架构调整、多方案歧义问题以及测试文件中的问题采取保守策略（仅报告不修复），可能仍需人工介入。评分阈值（Diff 模式≥70、Audit 模式≥80）的设定具有一定主观性，不同团队对"可接受风险"的定义可能存在差异。此外，技能要求环境中预装 git 二进制文件，对无 Git 环境的场景不适用。完全基于提示词引导的执行方式，相比原生代码实现的审查工具，在超大规模代码库（>50 文件触发警告）场景下可能存在性能瓶颈。

适合的目标群体

该技能主要面向需要快速代码审查的开发者个体和小型至中型技术团队。特别适合以下场景：独立开发者提交 PR 前的自检、团队内部轻量级代码审查流程、安全合规驱动的代码审计、以及作为 CI/CD 流水线的前置检查环节。对于已有完善 ESLint/Prettier 等工具链的团队，可作为人工 review 的有效补充而非替代。不适合追求多 Agent 协作深度分析的大型企业级代码审查场景，也不适合完全无 Git 版本控制的工作流。

使用风险

性能风险：单遍审查模式虽轻量，但对超大文件或复杂依赖关系的分析可能消耗大量模型 token；误判风险：自动修复可能引入新的回归问题，建议在关键业务代码审查时关闭 auto-fix 或增加人工复核；依赖风险：技能依赖 git 二进制和环境 Git 配置，路径解析错误可能导致审查范围偏差；版本漂移风险：自动修复后直接修改文件，若未配合分支保护机制，可能与团队成员的并行修改产生冲突；模型可用性风险：底层模型服务的中断或降级将直接影响技能可用性。建议在生产环境集成前进行小规模试点，并建立修复回滚机制。