pr-review-analysis skill

---
name: pr-review-analysis
description: PR Code Review 评论分析知识库，包含置信度评估、优先级分类、技术栈识别和常见评论模式
---

# PR Review 分析 Skill

本 Skill 提供 PR Code Review 评论分析的知识库，用于支持 `/fix-pr-review` 工作流。

## 1. 置信度评估体系

### 1.1 评分因素

置信度表示评论的"可操作性"，分数范围 0-100。

| 因素 | 权重 | 说明 |
|------|------|------|
| 明确性 (clarity) | 40% | 评论是否清晰指出问题和位置 |
| 具体性 (specificity) | 30% | 是否有具体示例或测试场景 |
| 上下文 (context) | 20% | 是否理解代码上下文和影响 |
| 可复现 (reproducibility) | 10% | 是否有复现步骤 |

### 1.2 评分指标

#### 明确性 (Clarity) - 权重 40%

| 指标 | 分值 | 示例 |
|------|------|------|
| 有具体文件位置 | +30 | "src/auth.py:42" |
| 有行号 | +10 | "第 42 行" |
| 有期望行为描述 | +30 | "应该返回 401" |
| 有代码示例 | +20 | ``` `if token.expired:` ``` |
| 评论长度 > 50 字 | +10 | 详细描述 |

#### 具体性 (Specificity) - 权重 30%

| 指标 | 分值 | 示例 |
|------|------|------|
| 有测试建议 | +40 | "添加测试用例验证..." |
| 有具体值/示例 | +30 | "返回 `{"error": "expired"}`" |
| 有对比说明 | +30 | "应该用 X 而不是 Y" |

#### 上下文 (Context) - 权重 20%

| 指标 | 分值 | 示例 |
|------|------|------|
| 引用其他代码位置 | +25 | "这会影响 `UserService`" |
| 讨论影响范围 | +25 | "可能导致数据不一致" |
| 基础分 | 50 | - |

#### 可复现 (Reproducibility) - 权重 10%

| 指标 | 分值 | 示例 |
|------|------|------|
| 有步骤描述 | +30 | "1. 登录 2. 访问 /api" |
| 有输入输出描述 | +20 | "当 token 过期时..." |
| 基础分 | 50 | - |

### 1.3 置信度等级

| 分数范围 | 等级 | 处理方式 |
|---------|------|---------|
| 80-100 | 高 (high) | 自动处理 |
| 60-79 | 中 (medium) | 询问用户后处理 |
| 40-59 | 低 (low) | 标记需澄清 |
| 0-39 | 极低 (very_low) | 跳过，回复 reviewer |

---

## 2. 优先级分类体系

### 2.1 优先级定义

| 优先级 | 名称 | 描述 | 处理要求 |
|--------|------|------|---------|
| P0 | Blocker | 阻塞上线的安全/数据问题 | 必须立即处理 |
| P1 | Critical | 核心功能缺陷 | 当前 PR 必须修复 |
| P2 | Major | 重要改进 | 建议本 PR 修复 |
| P3 | Minor | 建议/风格问题 | 可选处理 |

### 2.2 分类关键词

#### P0 (Blocker) 关键词

**安全相关**（自动升级 2 个优先级）：

- `security`, `vulnerability`, `injection`
- `XSS`, `CSRF`, `leak`, `exposed`
- `sensitive`, `password`, `token`, `secret`
- `安全`, `漏洞`, `泄露`, `暴露`

**关键缺陷**：

- `crash`, `data loss`, `downtime`
- `blocker`, `production`, `urgent`
- `崩溃`, `数据丢失`, `紧急`, `阻塞`

#### P1 (Critical) 关键词

- `bug`, `broken`, `fail`, `error`
- `incorrect`, `doesn't work`, `not working`
- `wrong`, `invalid`, `missing`
- `错误`, `失败`, `不正确`, `缺失`

#### P2 (Major) 关键词

- `should`, `better`, `improve`
- `optimize`, `refactor`, `performance`
- `cleanup`, `simplify`
- `应该`, `改进`, `优化`, `重构`

#### P3 (Minor) 关键词

- `consider`, `maybe`, `could`
- `nit`, `style`, `minor`, `typo`
- `nitpick`, `suggestion`
- `建议`, `风格`, `小问题`

### 2.3 优先级提升规则

| 条件 | 提升 |
|------|------|
| 包含安全关键词 | +2 级 |
| 包含数据相关关键词 | +1 级 |
| 文件在核心路径 (auth, payment) | +1 级 |

---

## 3. 技术栈识别

### 3.1 路径模式匹配

#### Backend

```yaml
patterns:
  - "src/api/**"
  - "src/models/**"
  - "src/services/**"
  - "app/**"
  - "tests/backend/**"
  - "tests/unit/**"
  - "**/*.py"
```

#### Frontend

```yaml
patterns:
  - "src/components/**"
  - "src/pages/**"
  - "src/hooks/**"
  - "src/stores/**"
  - "tests/frontend/**"
  - "**/*.tsx"
  - "**/*.jsx"
```

#### E2E

```yaml
patterns:
  - "tests/e2e/**"
  - "e2e/**"
  - "playwright/**"
  - "cypress/**"
```

### 3.2 文件扩展名推断

| 扩展名 | 技术栈 |
|--------|--------|
| `.py` | Backend |
| `.tsx`, `.ts`, `.jsx`, `.js` | Frontend |
| `.spec.ts`, `.test.ts` (在 e2e 目录) | E2E |

---

## 4. 常见评论模式

### 4.1 Backend 常见评论

#### 数据库相关

| 模式 | 置信度加成 | 优先级 |
|------|-----------|--------|
| "事务/transaction" | +15 | P1 |
| "N+1 查询" | +20 | P1 |
| "索引/index" | +10 | P2 |
| "死锁/deadlock" | +20 | P0 |

#### API 相关

| 模式 | 置信度加成 | 优先级 |
|------|-----------|--------|
| "状态码错误" | +15 | P1 |
| "响应格式" | +10 | P2 |
| "参数验证" | +15 | P1 |
| "错误处理" | +15 | P1 |

#### 认证相关

| 模式 | 置信度加成 | 优先级 |
|------|-----------|--------|
| "token 过期" | +20 | P0 |
| "权限检查" | +20 | P0 |
| "会话管理" | +15 | P1 |

### 4.2 Frontend 常见评论

#### React 相关

| 模式 | 置信度加成 | 优先级 |
|------|-----------|--------|
| "useEffect 依赖" | +15 | P1 |
| "状态管理" | +10 | P2 |
| "memo/useMemo" | +10 | P2 |
| "key 属性" | +15 | P1 |

#### 测试相关

| 模式 | 置信度加成 | 优先级 |
|------|-----------|--------|
| "mock 冲突" | +20 | P1 |
| "异步测试" | +15 | P1 |
| "测试覆盖" | +10 | P2 |

### 4.3 E2E 常见评论

| 模式 | 置信度加成 | 优先级 |
|------|-----------|--------|
| "选择器不稳定" | +15 | P1 |
| "超时问题" | +15 | P1 |
| "等待条件" | +15 | P1 |
| "断言不准确" | +10 | P2 |

---

## 5. 回复最佳实践

### 5.1 回复原则

1. **感谢 Reviewer**：始终表示感谢
2. **说明行动**：清楚描述做了什么
3. **提供证据**：链接到修复代码/测试
4. **开放沟通**：邀请进一步讨论

### 5.2 回复模板

#### 已修复

```markdown
✅ 已修复

感谢指出！已在 `{commit}` 中完成修复。

**变更**：
- {变更描述}

**测试**：
- ✅ {测试名称} 通过
```

#### 需要澄清

```markdown
⏸️ 需要更多信息

感谢建议！为了更好地理解，能否提供：
1. {问题 1}
2. {问题 2}
```

#### 不采纳（有理由）

```markdown
ℹ️ 暂不修改

感谢建议！经过分析，当前实现是预期行为，原因：
- {原因}

如果您有不同看法，欢迎继续讨论。
```

### 5.3 避免的回复

- ❌ "你的建议不对"
- ❌ "代码已经这样写了"
- ❌ 不提供任何解释的 "已修复"
- ❌ 防御性语气

---

## 6. 时间窗口过滤

### 6.1 过滤规则

**有效评论条件**：

- 评论创建时间 > 最后 commit 时间
- 或评论更新时间 > 最后 commit 时间（有新回复）

### 6.2 时区处理

- 所有时间使用 UTC
- GitHub API 返回的时间已是 UTC
- 比较前确保时区一致

### 6.3 边界情况

| 情况 | 处理 |
|------|------|
| 评论与 commit 同时 | 保守保留 |
| 更新时间 > 创建时间 | 检查更新内容 |
| 评论在 commit 前但有新回复 | 保留 |

---

## 7. TDD 集成

### 7.1 修复流程

所有 PR Review 修复必须遵循 TDD：

1. **RED**：编写能复现评论问题的测试
2. **GREEN**：最小实现使测试通过
3. **REFACTOR**：优化代码

### 7.2 测试命名

```python
# 格式: test_{功能}_{评论描述}
def test_token_validation_returns_401_when_expired():
    """
    PR Review: rc_123456
    Reviewer: @alice_dev
    """
    pass
```

### 7.3 覆盖率要求

- 新增代码：100% 覆盖
- 修改代码：不低于原覆盖率
- 总体覆盖：>= 90%

---

## 8. 知识沉淀

### 8.1 何时沉淀

- P0/P1 评论的修复
- 置信度 >= 85 的评论
- 新发现的问题模式

### 8.2 沉淀内容

```markdown
## {问题模式名称}

**频率**: ★★★☆☆
**技术栈**: Backend/Frontend/E2E
**关键词**: token, expire, validation

### 问题描述
{描述}

### 解决方案
{TDD 修复代码示例}

### 检查清单
- [ ] 检查项 1
- [ ] 检查项 2
```

### 8.3 沉淀位置

- 通用模式：`docs/best-practices/pr-review-patterns.md`
- 技术栈特定：`docs/best-practices/{stack}/*.md`