mcpField
R
requesting-code-review

requesting-code-review

github.com/izyanrajwani测试与质量469 次安装2 周前更新
代码仓库

关于 requesting-code-review

requesting-code-review 是指导开发者调用 code-reviewer 子 Agent 的技能,可依据需求和提交 SHA 检查代码变更。它说明如何在分任务开发、合并前或遇到阻碍时请求审查,并按优先级处理反馈。

主要功能

  1. 01调用 code-reviewer 子 Agent 的指南
  2. 02选择 base 与 head SHA
  3. 03审查提示模板占位符
  4. 04按严重程度处理反馈
  5. 05针对工作流安排审查时机

适用场景

  1. 01合并前审查分支
  2. 02每项开发任务后检查代码
  3. 03遇到阻碍时评估变更

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/izyanrajwani/agent-skills-library --skill requesting-code-review

安装后在 Claude Code 中输入/requesting-code-review确认已加载。

附带文件templates/code-reviewer.md

详细介绍

请求代码审查

派遣代码审查子 Agent,在问题扩大之前发现问题。

核心原则: 尽早审查,频繁审查。

如何请求

1. 获取 git SHA:

# For PR/branch review (recommended):
BASE_SHA=$(git merge-base origin/main HEAD)
HEAD_SHA=$(git rev-parse HEAD)

# For single commit only:
# BASE_SHA=$(git rev-parse HEAD~1)

2. 派遣代码审查子 Agent:

使用 Task 工具,并采用 templates/code-reviewer.md 中的模板。

占位符:

  • {WHAT_WAS_IMPLEMENTED} - 你刚刚构建的内容
  • {PLAN_OR_REQUIREMENTS} - 应实现的功能
  • {BASE_SHA} - 起始提交
  • {HEAD_SHA} - 结束提交
  • {DESCRIPTION} - 简要摘要

3. 根据反馈采取行动:

  • 立即修复严重问题
  • 继续之前先修复重要问题
  • 将次要问题记录下来,稍后处理
  • 如果审查者有误,请提出异议并说明理由

示例

[Just completed Task 2: Add verification function]

BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)

[Dispatch code-reviewer subagent with references/code-reviewer.md]
  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types

[Subagent returns]:
  Strengths: Clean architecture, real tests
  Issues:
    Important: Missing progress indicators
    Minor: Magic number (100) for reporting interval
  Assessment: Ready to proceed

[Fix progress indicators, continue to Task 3]

与工作流集成

子 Agent 驱动的开发:

  • 每项任务完成后都进行审查
  • 在问题叠加之前发现问题
  • 修复后再开始下一项任务

执行计划:

  • 每批任务(3 项)完成后进行审查
  • 获取反馈,采纳后继续

临时开发:

  • 合并前进行审查
  • 遇到阻碍时进行审查

危险信号

切勿:

  • 因为“很简单”就跳过审查
  • 忽略严重问题
  • 带着未修复的重要问题继续
  • 反驳合理的技术反馈

如果审查者有误:

  • 提出异议并说明技术理由
  • 展示能够证明其有效的代码或测试
  • 请求对方澄清

评论

支持 Markdown