Claude Code 插件 pr-review 实战指南用安全审查、测试覆盖与性能分析自动化 PR 评审【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto导读pr-review 是当前仓库中内置的 Claude Code 插件之一它将一次人工 PR 评审拆解为「安全审查 测试覆盖验证 性能影响评估 文档核验 代码质量检查」五个自动化维度并通过斜杠命令、子代理Subagents、MCP 服务器与前置钩子组合成一个完整闭环。读完本文你将掌握该插件的安装配置、三个核心命令的用法、三个专用子代理的职责边界以及其工作流在底层源码中的真实执行链路可直接把整套评审流程复用到自己的团队仓库中。插件定位与核心功能在仓库的插件体系中pr-review 位于 07-plugins/pr-review与devops-automation部署自动化、documentation文档生成并列共同构成 Claude Code 的工程化能力矩阵07-plugins 总览。该插件面向「拉取请求合并前」这一高价值场景将评审工作拆成五个自动化检查项✅ 安全分析Security analysis✅ 测试覆盖率检查Test coverage check✅ 文档核验Documentation verification✅ 代码质量评估Code quality evaluation✅ 性能影响分析Performance impact analysis与通用 AI 审查工具不同pr-review 不是单一模型提示词而是一个分工协作的系统斜杠命令负责编排子代理负责各领域的深度分析MCP 服务器负责注入 PR 的真实数据钩子负责前置校验。这种结构让每次评审既有广度五项全覆盖又有深度每项由专职代理负责。安装与前置条件插件安装使用 Claude Code 的插件管理器/plugin install pr-review安装前需满足以下环境要求要求说明Claude Code 2.1插件依赖斜杠命令与子代理能力2.1 及以上版本才完整支持GitHub 访问权限通过 GitHub MCP 拉取 PR 数据、变更内容与评论Git 仓库评审对象必须位于 Git 仓库内且能被git命令访问安装完成后需配置 GitHub 访问令牌。插件通过环境变量GITHUB_TOKEN注入凭据export GITHUB_TOKENyour_github_token该令牌将透传给 GitHub MCP 服务器用于读取 PR 数据详见下文「GitHub MCP 集成」一节。建议在 CI 或本地 shell 配置文件中长期维护该变量避免每次会话重复导出。三个斜杠命令从全量评审到专项检查插件共提供三个斜杠命令覆盖「全量」与「专项」两种评审粒度。/review-pr — 综合评审入口这是插件的总入口一次触发完整评审流水线。根据 review-pr 命令定义该命令按顺序执行五项检查安全分析Security analysis测试覆盖率验证Test coverage verification文档更新核验Documentation update verification代码质量检查Code quality checks性能影响评估Performance impact assessment/review-pr/check-security — 专项安全审查当 PR 涉及认证、支付、权限等敏感改动时可直接跳过其他维度仅做安全专项分析。根据 check-security 命令定义审查清单包含认证/授权检查Authentication/authorization checks数据泄露风险Data leak risks注入类漏洞Injection vulnerabilities密码学弱点Cryptographic weaknesses日志中的敏感数据Sensitive data in logs/check-security/check-tests — 专项测试覆盖分析用于验证 PR 的测试完备性。根据 check-tests 命令定义分析内容包括测试覆盖率百分比核验Coverage percentage verification未测试代码路径识别Untested code path identification测试质量评估Test quality assessment缺失测试用例建议Missing test case suggestions边界情况覆盖检查Edge case coverage checks/check-tests三种命令的使用取舍很简单常规 PR 用/review-pr一次性搞定涉及安全敏感改动时先用/check-security快速把关测试薄弱的模块用/check-tests单独追踪覆盖缺口。后两个专项命令也常被开发者在/review-pr报出问题后作为「复查」工具重复调用验证修复效果。三个子代理专业化分工的评审大脑命令只是入口真正的分析由子代理执行。插件内置三个专职子代理均声明了tools: Read, Grep, Bash即具备读取文件、正则搜索与执行命令的能力足以独立完成代码级分析。security-reviewer — 安全审查代理定义见 security-reviewer.md聚焦四类安全风险认证/授权问题Authentication/authorization issues数据泄露Data leaks注入攻击Injection attacks不安全配置Unsafe configuration其分析与/check-security的清单一一对应命令定义清单auth、数据泄露、注入、密码学、日志敏感数据代理则负责把这些条目落到具体代码行上通过 Read/Grep 定位可疑调用、通过 Bash 运行静态检查命令佐证。test-checker — 测试覆盖代理定义见 test-checker.md职责包括覆盖率百分比核算Coverage percentage缺失测试用例识别Missing test cases测试质量评估Test quality assessment边界情况判定Edge case identification在实操中该代理会读取测试报告文件如覆盖率 XML/JSON用 Grep 找出if/else分支、异常路径与空值处理等未被覆盖的边界再用 Bash 运行pytest --cov或npm test --coverage复算数值最终给出可量化的覆盖率结论例如本文工作流示例中的「覆盖 65%建议 80%」。performance-analyzer — 性能影响代理定义见 performance-analyzer.md评估变更对性能的影响算法复杂度Algorithm complexity数据库查询效率Database query efficiency内存使用Memory usage缓存可能性Caching opportunities从源码结构看该代理的典型分析路径是定位 diff 中新增的循环与嵌套查询估算其时间复杂度是否从 O(n) 劣化到 O(n²)检查是否在循环内重复发起数据库查询、是否漏掉必要的索引识别可以引入缓存的热点路径并给出具体优化建议。从仓库结构可以推断三个子代理的 frontmatter 使用namedescriptiontools三段式声明这正是 Claude Code 子代理的标准加载协议——Claude 在收到/review-pr后会按描述匹配并动态加载对应代理把分析任务委派出去。GitHub MCP 集成让评审拿到真实 PR 数据评审的前提是「拿到 PR 本身」。插件通过 MCPModel Context Protocol接入 GitHub配置见 github-config.json{ mcpServers: { github: { command: npx, args: [modelcontextprotocol/server-github], env: { GITHUB_TOKEN: ${GITHUB_TOKEN} } } } }配置要点启动方式通过npx直接运行官方modelcontextprotocol/server-github无需额外安装全局包凭据注入GITHUB_TOKEN从环境变量${GITHUB_TOKEN}读取与上一节export GITHUB_TOKEN...的设置直接衔接令牌不会硬编码进配置文件数据能力MCP 服务器向 Claude 暴露 PR 的标题、描述、变更文件列表、diff 内容与评论上下文供子代理基于真实改动进行分析而不是凭空猜测。pre-review.js 前置钩子评审前的守门员评审开始前插件会先运行 pre-review.js 做环境自检。该钩子是 Node.js 脚本#!/usr/bin/env node核心逻辑如下// 检查当前目录是否为 Git 仓库 execSync(git rev-parse --git-dir, { stdio: pipe }); // 若失败则输出错误并退出码 1 // 检查是否存在未提交的改动 const status execSync(git status --porcelain, { encoding: utf-8 }); if (status.trim()) { console.warn(⚠️ Warning: Uncommitted changes detected); }两个检查点分别对应两种失败模式非 Git 仓库git rev-parse --git-dir抛错 → 打印❌ Not a git repository并以退出码1终止评审从源头拦截「评审对象不成立」的场景未提交的改动git status --porcelain有输出时仅打印⚠️警告而不中断——因为评审的是 PR 的暂存/已提交内容工作区脏数据不影响评审正确性但值得提醒开发者。主函数preReview()通过 Promise 链调用任何未捕获异常都会落入末尾的.catch()统一输出Pre-review hook failed并以退出码1结束保证钩子失败时不会静默通过。这一设计体现了插件「三层防御」的可靠性思路钩子先验环境 → MCP 注入数据 → 子代理分工分析任何一层出问题都会被显式暴露而非产生一份基于错误前提的虚假报告。完整工作流示例一次 /review-pr 的端到端执行插件在 README 中给出了完整的交互时序还原了从用户触发到报告产出的全过程User: /review-pr Claude: 1. 运行 pre-review 钩子验证 git 仓库 2. 通过 GitHub MCP 获取 PR 数据 3. 将安全审查委派给子代理 security-reviewer 4. 将测试验证委派给子代理 test-checker 5. 将性能分析委派给子代理 performance-analyzer 6. 综合所有发现 7. 输出综合评审报告 结果 ✅ 安全未发现关键问题 ⚠️ 测试覆盖率 65%建议 80% ✅ 性能无显著影响 建议补充边界情况测试该时序展示了本插件的核心价值——编排而非单点分析7 个步骤中只有第 1、2 步是 Claude 本体串行执行第 35 步是并行委派给三个专职子代理第 6、7 步再由本体汇总。这种「并行委派 集中合成」的模式让一份 PR 评审在保持深度的同时不被单次分析的长度所限。报告中每个结论都带状态标识✅ / ⚠️ / 便于开发者快速扫描阻塞项示例中的「覆盖率 65% vs 建议 80%」也提示了插件的量化判定风格——子代理会给出数字与阈值对比而非含糊的「覆盖还行」。适用前提与局限版本前提插件要求 Claude Code 2.1低于该版本的 CLI 可能缺少子代理加载或插件管理能力权限前提GitHub 令牌的权限范围需覆盖目标仓库的读取PR、diff、评论否则 MCP 拉取数据会失败评审边界钩子只做环境自检不做内容分析子代理的分析质量依赖其被授予的 Read/Grep/Bash 工具在仓库内可读到的信息受限的 Bash 环境会影响覆盖率复算等需要执行命令的环节报告非人工替代插件产出的是可执行的评审清单合并决策仍需人工基于上下文确认尤其在高风险改动上。快速上手清单升级 Claude Code 至 2.1在目标 Git 仓库执行/plugin install pr-review配置export GITHUB_TOKENyour_github_token确保令牌有仓库读取权限日常评审直接触发/review-pr安全敏感改动优先/check-security测试薄弱模块用/check-tests若需深度理解实现可继续阅读插件的命令定义、子代理声明、钩子源码 与 MCP 配置。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
