claude-skills Code Reviewer 清单从 PR 上下文到分级报告的完整代码评审方法论【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills本篇指南围绕 claude-skills 仓库中code-reviewer技能的参考清单 review-checklist.md 展开系统讲解其八维评审清单、五阶段评审流程、分类深挖问题库与时间分配模型。读者读完可掌握一套可直接套用在任何 PR 评审场景的检查框架并能结合本仓库的配套资料常见问题模式、反馈话术、报告模板、规格符合性评审输出一份分级清晰、可执行的代码评审报告。一、清单在设计评审体系中的位置code-reviewer是 claude-skills 项目 67 个全栈开发技能之一定位为高级工程师执行的全面且建设性的代码评审。它的元信息见 skills/code-reviewer/SKILL.md表明这是一个通用范围评审技能domain: qualityscope: review与security-reviewer安全专项、test-master测试专项、architecture-designer架构专项形成互补——它在一轮评审中同时覆盖正确性、性能、可维护性与测试覆盖度。该技能通过引用表Reference Guide按需加载不同参考文档review-checklist.md 是其中开始评审、确定类别时加载的核心清单文件。它给出了评审的顶层框架而common-issues.md提供具体反模式、feedback-examples.md提供反馈写作方法、report-template.md提供报告输出结构、spec-compliance-review.md提供规格符合性前置评审、receiving-feedback.md提供被评审者的响应指南。在 SKILLS_GUIDE.md 的Code Review Process工作流中其典型用法是Code Reviewer通用评审→ Security Reviewer安全聚焦→ Architecture Designer架构评审即本清单服务于流程的第一环。二、八维综合评审清单清单的核心是一张八类别 × 关键问题的速查表评审者可以把它当作覆盖全部维度的心智模型防止在细节中遗漏某类问题类别关键问题设计 Design是否符合现有模式抽象层级是否恰当逻辑 Logic边界情况是否处理竞态条件空值检查安全 Security输入是否校验认证是否检查密钥是否安全性能 Performance是否存在 N1 查询内存泄漏是否需要缓存测试 Tests覆盖是否充分边界情况是否被测Mock 是否恰当命名 Naming是否清晰、一致、能表达意图错误处理 Error Handling错误是否被捕获消息是否有意义是否记录日志文档 Documentation公共 API 是否文档化复杂逻辑是否解释清楚这八个维度对应 SKILL.md 中 Core Workflow 第 3 步提到的检查范围——是否有 N1 查询、硬编码密钥或注入风险。三、五阶段评审流程与时间分配清单把一次完整评审拆成 5 个阶段每阶段有明确的检查点checkbox和预估耗时阶段 1Context 理解约 5 分钟阅读 PR 描述理解要解决的问题检查关联的 issue / ticket记录预期的变更范围这一阶段对应 SKILL.md 工作流第 1 步的强制检查点在继续之前必须用一句话概括 PR 的意图如果无法概括就要求作者澄清。阶段 2Structure 结构审查约 10 分钟审查文件组织方式检查架构适配性验证使用的设计模式记录任何破坏性变更阶段 3Code Details 代码细节约 20 分钟审查逻辑正确性检查边界情况验证错误处理查找安全问题检查性能隐患审查命名清晰度阶段 4Tests 测试审查约 10 分钟验证测试覆盖率检查测试质量查找边界情况测试确保 Mock 使用恰当阶段 5Final Pass 收尾约 5 分钟记录值得肯定的正面模式对反馈进行优先级排序撰写总结四、四类核心问题深挖清单提供了四类问题的详细提问清单供评审者在阶段 3 深入使用设计类问题这个变更是否属于这个文件 / 模块抽象层级是否恰当能否更简单是否遵循现有模式是否无需修改即可扩展逻辑类问题遇到 null / undefined 输入会发生什么边界条件是否已处理是否存在竞态条件操作顺序是否正确所有代码路径是否都被测试覆盖安全类问题所有用户输入是否都经过校验SQL 查询是否参数化输出是否正确编码密钥是否安全处理认证authentication是否已检查授权authorization是否被强制性能类问题是否存在 N1 查询模式数据获取是否高效昂贵操作是否已缓存会不会导致内存泄漏是否实现分页五、时间分配模型清单最后给出一个按评审焦点划分的时间百分比模型可作为阶段 15 预算的宏观参照评审焦点时间占比Context 与 PR 描述10%架构与设计20%代码逻辑与细节40%测试与覆盖率20%终审与总结10%六、清单在实际评审中的纵深运用仅凭八维清单还不够实际落地需要把每个维度落到具体的反模式识别与输出格式上这正是配套参考文档的职责6.1 用常见问题库落地点名对应 Logic / Performance / Error Handling 维度common-issues.md 把清单中的性能 / 逻辑 / 可维护性问题具体化为 8 个高频反模式并给出每条的影响 → 修复对照。其中与清单维度直接挂钩的有N1 查询Performance 维度循环内逐条查询关联数据应在循环外批量加载或使用 join。缺失错误处理Error Handling 维度未处理response.ok与异常捕获应 try/catch 结构化日志 抛出语义化错误。魔法数字 / 字符串Naming 维度if (user.age 18)应提取为命名常量。深层嵌套可读性用 early return 守卫子句替代多层 if 嵌套。上帝函数Design 维度一个函数同时做校验、库存检查、支付、发邮件、更新数据库、记录分析应拆分为单一职责函数。可变共享状态逻辑可靠性用Object.freeze等不可变模式替代可被随意改写的全局配置。缺失空值检查Logic 维度用可选链?.与空值合并??替代不安全访问。同步文件操作Performance 维度readFileSync阻塞事件循环应改用异步版本。这些反模式与清单第 4 节的四类深挖问题一一对应评审者可以先按八维清单扫描再对照常见问题库确认具体实例。6.2 用分级报告模板固化输出Final Pass 维度report-template.md 给出了清单阶段 5 总结输出的标准结构Summary 摘要、Verdict 结论、Critical / Major / Minor 三级问题、Positive Feedback、Questions for Author、测试覆盖评估与最终检查清单。它同时定义了三种结论的使用时机与严重度分级结论使用时机Approve无阻塞问题仅有次要建议Request Changes存在必须修复的 Critical 或 Major 问题Comment有问题需要回答但无阻塞项严重度定义示例Critical安全风险、数据丢失、崩溃SQL 注入、认证绕过Major显著的性能 / 可维护性问题N1 查询、上帝函数Minor风格、命名、小改进变量名、格式化其提交前快速检查还包括所有 Critical 问题都有明确修复方案、Major 问题说明了影响、至少包含一条正面评价、问题具体可回答、结论与发现的问题一致。6.3 用反馈话术模板落实具体、可执行要求feedback-examples.md 对应清单中命名 / 错误处理类反馈的表达质量要求强调反馈必须具体、可执行、建设性并用问题替代断言。它同时按严重度给出标准话术模板[CRITICAL] / [MAJOR] / [MINOR] / [QUESTION]每条都要求标注Location: path:line、现状、建议与影响。这与 SKILL.md 的 MUST DO 约束提供具体可执行反馈、建议中带代码示例、肯定好的模式、按 critical → minor 排序完全对齐。6.4 规格符合性评审清单维度之外的前置关卡对于评审实现 / PR / 规格验证场景清单本身不涉及代码是否做对了事需要加载 spec-compliance-review.md。它定义了两阶段评审架构Stage 1 规格符合性评审有没有做对的事→ Stage 2 代码质量评审有没有把事做好并强调顺序不可颠倒——对不符合规格的功能做代码质量评审没有意义。Stage 1 从三个类别验证实现缺失需求将 PR 与原始需求逐行比对检查边界情况、错误路径与主流程。多余添加识别范围蔓延与过度设计如未要求的缓存层、一次性的辅助函数。理解偏差识别对需求的误解与未澄清的假设。其输出格式区分✅ PASS可进入代码质量评审与❌ ISSUES FOUND先修复缺失需求。6.5 被评审者的视角反馈接收的六步流程评审闭环的另一半是receiving-feedback.md它与清单共同构成完整评审文化完整阅读评论 → 用自己的话复述需求 → 对照代码核实 → 评估技术合理性 → 用实质内容回应或给出技术依据的异议→ 逐条实现并验证。其核心理念是代码评审是技术讨论而非社交场合要求用行动代码修改而非奉承证明理解同时给出了合规的异议格式——这与 [X] 冲突。[证据]。这是有意为之还是我们应该 [替代方案]七、在 claude-skills 生态中的组合用法按 SKILLS_GUIDE.md 的定义该清单所在的技能通常按以下方式组合新功能开发流水线Feature Forge定义需求→ Architecture Designer设计架构→ Fullstack Guardian 框架技能实现→ Test Master Playwright Expert测试→Code Reviewer本清单所属技能→ Security Reviewer安全评审→ DevOps Engineer部署。Bug 修复流水线Debugging Wizard定位根因→ Fullstack Guardian 框架技能修复→ Test Master补回归测试→Code Reviewer评审修复。代码评审流程Code Reviewer通用评审→ Security Reviewer安全聚焦评审→ Architecture Designer架构评审按需。从仓库文档看docs/ideas/audit-skill-consistency.md该技能曾经历参考文档增强与触发验证审计ROADMAP 也记录了 code-reviewer 参考文档的增强工作ROADMAP.md当前清单正是这套方法论沉淀后的稳定形态。八、实践小结把 review-checklist.md 落地到自己的评审习惯中可以按四步执行建立基线用八维清单 五阶段流程 时间模型先扫描再深入确保每一轮评审维度不遗漏。确认做对了事对规格实现类 PR先跑规格符合性评审Stage 1再进入质量评审Stage 2。对照反模式点名在代码细节阶段用 common-issues.md 的 8 类反模式逐一核对并在反馈中给出文件行号、现状、建议与影响。按模板输出以 report-template.md 的分级结构产出报告确保结论Approve / Request Changes / Comment与问题严重度一致并保留至少一条正面反馈。这套以清单为骨架的方法论的价值在于它把代码评审从凭经验的口头反馈变成了一个维度完整、流程可控、输出可复现的工程活动。无论被评审代码属于哪种语言或框架这份清单都可以作为评审的起点骨架配合仓库内其他参考文档做纵深扩展从而在 50 分钟内产出一份有分级、有依据、可执行的评审报告。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考