审查反馈实施计划生成Skill plan-from-review

---

name: plan-from-review description: 从PR代码审查反馈创建实施计划 allowed-tools: Bash, Read, Grep, Glob, Write

从审查生成计划技能

基于PR代码审查反馈生成实施计划。从审查评论中提取操作项、问题和建议，并创建结构化计划来处理它们。

参数

/plan-from-review <pr-number> [--dry-run]

• <pr-number>: 必需。要提取审查反馈的pull request编号。
• --dry-run: 可选。将计划输出到控制台而不写入文件。

执行流程

1. 检测仓库

# 从git remote获取仓库
REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')

2. 获取PR信息

# 获取PR详细信息，包括当前HEAD提交
gh pr view $PR_NUMBER --json title,body,headRefName,baseRefName,number,headRefOid

# 获取最新审查（优先选择REQUEST_CHANGES或有内容的COMMENT）
gh api repos/$REPO/pulls/$PR_NUMBER/reviews --jq '
  [.[] | select(.body != "" and .body != null)] |
  sort_by(.submitted_at) |
  last'

# 获取内联审查评论
gh api repos/$REPO/pulls/$PR_NUMBER/comments --paginate

3. 分析审查反馈

不要机械地解析格式化部分。 相反，阅读并理解整个审查对话：

1. 阅读审查正文 - 理解整体评估
2. 阅读所有内联评论 - 理解每个位置的具体关注点
3. 阅读任何回复线程 - 上下文可能澄清或解决问题
4. 检查审查裁决 - APPROVE, REQUEST_CHANGES, 或 COMMENT

智能确定可操作项：

• 识别了哪些问题？(漏洞、缺少测试、安全问题、风格)
• 建议了什么但不是必需的？
• 哪些只是信息性或已在讨论中解决？
• 有隐含问题吗？(例如，“这看起来很复杂”可能意味着需要重构)

根据严重性评估分类：

• 必须修复: 漏洞、安全问题、缺少关键测试、架构问题
• 应该修复: 缺少边缘情况测试、文档空白、代码清晰度问题
• 细节: 风格偏好、可选改进、可有可无的改进

跳过以下项目：

• 在后续评论中已解决的
• 明确标记为非阻塞的（“细节:”、“可选:”、“次要:”)
• 问题已得到回答且无需更改的
• 赞扬或批准声明

4. 阅读项目指南

在生成计划之前：

• 审查 CODING_GUIDELINES.md 了解实施标准
• 审查 TESTING_GUIDELINES.md 了解测试要求
• 审查 COMMIT_GUIDELINES.md 了解提交结构

5. 确定输出位置

计划以修订前缀（短提交SHA）存储，以支持多个审查周期：

# 获取当前HEAD提交（短SHA）
HEAD_SHA=$(gh pr view $PR_NUMBER --json headRefOid --jq '.headRefOid' | cut -c1-7)

# 从分支名中提取问题编号（如果存在）
BRANCH=$(gh pr view $PR_NUMBER --json headRefName --jq '.headRefName')
# feature/42-something -> 42
ISSUE_NUM=$(echo "$BRANCH" | grep -oE '[0-9]+' | head -1)

# 确定 .ai 文件夹
if [ -n "$ISSUE_NUM" ]; then
  AI_FOLDER=$(ls -d .ai/issue-${ISSUE_NUM}-* 2>/dev/null | head -1)
fi
if [ -z "$AI_FOLDER" ]; then
  # 从PR编号创建文件夹
  AI_FOLDER=".ai/pr-${PR_NUMBER}"
fi

# 输出文件包括修订
OUTPUT_FILE="$AI_FOLDER/review-plan-${HEAD_SHA}.md"

文件命名: review-plan-<commit-sha>.md

• 示例: review-plan-c9625f7.md
• 允许跟踪多个审查周期
• 易于将计划与特定PR修订关联

6. 生成实施计划

写入 $AI_FOLDER/review-plan-<sha>.md，遵循创建计划模板结构：

# 实施计划：针对PR #<number>的审查反馈

## 来源
- PR: #<number> - <title> (<link>)
- 审查: <reviewer> on <date>
- 修订: `<full-commit-sha>`
- 分支: `<branch-name>`

## 概述
<审查反馈的简要总结 - 需要解决的问题>

## 前提条件
- [ ] PR分支已检出: `<branch-name>`
- [ ] 审查反馈已理解
- [ ] 没有阻塞性问题

## 实施任务

### 任务 1: <从审查评论派生的标题>
**文件**: `<path/to/file.go>`

**更改**:
- [ ] <来自审查反馈的具体更改>
- [ ] <如果需要，额外更改>

**详细信息**:
<修复提示内容（如果可用）或更改的详细描述>

**严重性**: 必须修复 | 应该修复 | 细节

### 任务 2: <下一个问题>
**文件**: `<path/to/file1.go>`, `<path/to/file2.go>`

**更改**:
- [ ] <具体更改>

**详细信息**:
<来自审查评论的上下文>

**依赖**: 任务 1（如果适用）

**严重性**: 应该修复

### 任务 N: 添加/更新测试
**文件**: `test/cmd/<file>_test.go`

**更改**:
- [ ] 添加 `Test<FunctionName>` - <测试内容>
- [ ] 更新现有测试以处理 <场景>

**测试要求**: 根据 TESTING_GUIDELINES.md

## 测试计划

### 要添加/修改的测试
| 测试名称 | 目的 | 文件 |
|-----------|---------|------|
| `TestXxx` | <来自审查反馈> | `test/...` |

### 验证
- [ ] 所有新测试通过
- [ ] 现有测试仍然通过
- [ ] 覆盖边缘情况

## 文档更新
- [ ] `docs/<command>.1.md` - <如果在审查中提及>
- [ ] `docs/gitflow-config.5.md` - <如果需要配置更改>
- [ ] 代码注释 - <如果提出清晰度问题>

## 检查点

在每个检查点之后，验证：
1. `go build ./...` 成功
2. `go test ./...` 通过
3. 审查问题已解决

| 检查点 | 任务后 | 验证 |
|------------|------------|--------------|
| 1 | 任务 1 | <必须修复问题已解决> |
| 2 | 任务 2 | <应该修复项已处理> |
| 3 | 任务 N | 所有测试通过 |

## 提交策略

计划提交遵循 COMMIT_GUIDELINES.md：
1. 首先修复必须修复问题（分组相关修复）
2. 处理应该修复项（不同关注点的独立提交）
3. 实施细节（可选，可以单独PR）

示例提交消息：
- `fix(<scope>): <必须修复问题总结>`
- `test(<scope>): <添加缺失测试>`
- `refactor(<scope>): <处理应该修复项>`

## 估计范围
- 要修改的文件: <count>
- 新文件: <count>
- 要添加/修改的测试: <count>
- 必须修复: <count>
- 应该修复: <count>
- 细节: <count>

7. 处理空审查

如果未找到可操作反馈：

# 实施计划：针对PR #<number>的审查反馈

## 来源
- PR: #<number> - <title>
- 修订: `<commit-sha>`

## 概述
在审查中未找到操作项。

## 状态
审查可能是：
- 批准且未请求更改
- 评论没有具体操作项

**后续步骤**:
- 直接检查PR评论以获取上下文
- 如果需要，向审查者请求澄清
- 如果批准，继续合并

---

试运行模式

当传递 --dry-run 时：

• 正常获取和解析审查数据
• 将生成的计划输出到控制台
• 不写入任何文件

试运行 - 从PR #123审查生成计划

将写入: .ai/issue-42-feature-name/review-plan-c9625f7.md

```markdown
# 实施计划：针对PR #123的审查反馈
...
```

---

示例输出

对于修订 c9625f7 的PR审查反馈：

# 实施计划：针对PR #60的审查反馈

## 来源
- PR: #60 - 添加 --no-verify 选项到完成命令
- 审查: claude-bot on 2024-02-05
- 修订: `c9625f7a481f09e246e13f5f4307dd3487d0327d`
- 分支: `feature/59-add-no-verify-option-to-finish-command`

## 概述
实施稳健，测试覆盖良好。识别出一个缺少的测试用例用于压缩合并策略。

## 前提条件
- [ ] PR分支已检出: `feature/59-add-no-verify-option-to-finish-command`
- [ ] 审查反馈已理解
- [ ] 没有阻塞性问题

## 实施任务

### 任务 1: 添加使用 --no-verify 的压缩合并测试
**文件**: `test/cmd/finish_noverify_test.go`

**更改**:
- [ ] 添加 `TestFinishFeatureSquashWithNoVerify` 测试函数
- [ ] 遵循 TESTING_GUIDELINES.md 注释格式

**详细信息**:
添加一个测试：
1. 设置一个带有提交的特性分支
2. 通过git配置配置压缩合并策略
3. 安装拒绝的预提交钩子
4. 使用 --no-verify 标志完成
5. 验证压缩提交成功（钩子被绕过）

**严重性**: 应该修复

## 测试计划

### 要添加/修改的测试
| 测试名称 | 目的 | 文件 |
|-----------|---------|------|
| `TestFinishFeatureSquashWithNoVerify` | 验证 --no-verify 与压缩策略配合使用 | `test/cmd/finish_noverify_test.go` |

### 验证
- [ ] 新测试通过
- [ ] 现有7个测试仍然通过
- [ ] 覆盖压缩合并后的 `Commit` 调用

## 文档更新
- [ ] 无需要求（功能已记录）

## 检查点

| 检查点 | 任务后 | 验证 |
|------------|------------|--------------|
| 1 | 任务 1 | 测试通过，`go test ./...` 成功 |

## 提交策略

test(finish): 为 --no-verify 标志添加压缩合并测试

添加 TestFinishFeatureSquashWithNoVerify 以验证 --no-verify 标志在压缩合并提交操作中正确绕过钩子。

## 估计范围
- 要修改的文件: 1
- 新文件: 0
- 要添加的测试: 1
- 必须修复: 0
- 应该修复: 1
- 细节: 0

---

多个审查周期

当PR经历多个审查周期时：

.ai/issue-59-add-no-verify/
├── analysis.md
├── plan.md                    # 原始实施计划
├── review-plan-c9625f7.md     # 第一次审查（修订 c9625f7）
├── review-plan-a1b2c3d.md     # 修复后的第二次审查
└── pr_summary.md

每个审查计划捕获该修订的状态，允许：

• 审查反馈的历史跟踪
• 理解修订之间修复的内容
• 类似未来问题的参考

---

与其他技能的集成

创建计划后：

• 使用 /implement .ai/<folder>/review-plan-<sha>.md 执行修复
• 使用 /code-review 实施后验证更改
• 使用 /commit 创建正确格式的提交