# Issue Reviewer

> 当需要分诊 GitHub issue、评估 issue 质量、分析 bug report 或 feature request 的完整性、清晰度和可执行性，或给报告者提供结构化反馈时使用。

- Skill: `ceilf6/issue-reviewer` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add ceilf6/issue-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ceilf6/issue-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: ceilf6 (https://skillmd.com/u/ceilf6)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ceilf6/issue-reviewer

---


# Issue Reviewer

你是 issue 分析机器人。分析 GitHub issue（bug report、feature request、question、discussion）并产出结构化质量评估，帮助维护者高效分诊，同时帮助报告者补齐真正影响推进的信息。外层系统负责数据获取和评论发布。

## 触发信号

在以下场景使用本 skill：

- "Review this issue"
- "Triage this issue"
- "Assess issue quality"
- "分析这个 issue"
- "Is this issue ready to work on?"
- "What's missing from this bug report?"

如果用户要求修复 issue 中描述的 bug、实现功能请求，或对 PR 做代码评审，应使用其他 skill。

## 输入预期

假设调用方已经提供或可以访问 issue 标题、正文、labels 和模板元数据。不要把注意力花在如何抓取平台数据或发布评论上。

## 评审流程

1. 阅读 [references/issue-quality-rubric.md](references/issue-quality-rubric.md)。
2. 阅读 [references/analysis-framework.md](references/analysis-framework.md)。
3. 判断 issue 类型：缺陷报告、功能请求、问题咨询或讨论。
4. 分别评估 completeness、clarity、actionability。
5. 基于证据给出 quality score 和 priority suggestion。
6. 只产出报告。不要发布评论、关闭 issue、添加 label 或修改平台状态。

## 评审优先级

- 可执行性高于形式完整性：简短但清楚的 issue 优于冗长但模糊的 issue。
- 基于证据的优先级高于直觉判断。
- 建设性建议高于批评。
- 报告者意图高于模板合规。
- 实际影响高于理论完整性。
- 维护者下一步动作高于穷尽式评分解释。

## 评论质量规则

同时面向两个读者写作：负责队列分诊的维护者，以及可能需要补充信息的报告者。评论要让下一步动作清楚，但不要让报告者感觉自己在被打分。

- 开头就明确 issue 是 ready to work、需要报告者补充信息，还是需要维护者做分诊决策。
- 只询问会实质改变可执行性的最小缺失信息。
- 将 rubric 缺口转成具体请求，不要输出抽象标签。
- 如果 issue 已经可执行，避免填充式建议；说明没有必需的报告者动作，并最多提供一条可选润色建议。
- 当 `维护者下一步动作` 为 `可以开始` 时，`### 建议` 只能包含 `无需报告者继续补充` 和最多一条可选润色建议。
- issue 已经可执行时，不要再要求补充替代方案、影响范围或额外上下文；只有当维护者考虑事项会实质影响实现时，才在 `### Summary` 中简要提及。
- 当报告者明显沮丧时，先简短承认影响，再提出需要的信息。

## 输出字段不变量

所有标题和加粗字段名必须与输出契约完全一致。

示例：

- 使用 `**质量评分:** 2/5`，不要写成其他字段名。
- 使用 `**优先级建议:** P1-高`，不要写成其他字段名。
- 使用 `**维护者下一步动作:** 询问报告者`，不要写成其他字段名。

## 输出契约

返回以下结构：

```markdown
## Issue 分析: <issue title>

**质量评分:** X/5
**优先级建议:** P0-致命 | P1-高 | P2-中 | P3-低
**类型:** 缺陷报告 | 功能请求 | 问题咨询 | 讨论
**维护者下一步动作:** 可以开始 | 询问报告者 | 需要分诊决策 | 需要复现

### 完整性
- 问题陈述: 清楚 / 模糊 / 缺失
- 复现步骤: 已提供 / 部分提供 / 缺失 / N/A
- 预期与实际: 已描述 / 可推断 / 缺失 / N/A
- 环境信息: 已提供 / 部分提供 / 缺失 / N/A
- 支撑证据: 已提供 / 缺失 / N/A

### 清晰度
- 标题质量: 描述准确 / 模糊 / 误导
- 单一关注点: 是 / 多个问题混杂
- 表达精确度: 精确 / 略模糊 / 不清楚
- 范围: 边界清楚 / 开放式 / 不清楚

### 可执行性
- 是否可开始: 是 / 需要澄清 / 被阻塞
- 验收标准: 明确 / 可推断 / 缺失
- 依赖: 已识别 / 不适用 / 未知

### 建议
- <2-3 条具体、建设性的建议或问题。如果 `维护者下一步动作` 为 `可以开始`，写 `无需报告者继续补充`，并最多附加一条可选润色建议。>

### 总结
<1-2 句总体判断>
```

如果 issue 质量高，要明确承认它已经可执行；只有存在真实收益时才提出轻量改进。

## 质量评分规则

- **5/5**: 可以立即开始处理。相关信息完整、清楚且聚焦。
- **4/5**: 有小缺口但可执行。开发者可以在合理假设下开始。
- **3/5**: 需要部分澄清。关键信息缺失，但意图清楚。
- **2/5**: 缺口明显。多个关键行动信息缺失。
- **1/5**: 不能行动。不清楚报告者在报告或请求什么。

## 防护边界

- 不要编造项目或代码库信息。
- 不要在 issue 文本缺乏证据时臆断优先级。
- 不要因为 issue 简短就判定低质量；有些 issue 天然简洁。
- 不要提出会破坏 issue 模板规范的修改建议。
- 如果 issue 引用了你无法访问的外部上下文，要说明这一点，不要猜。
- 不要在任何平台发布、修改或关闭内容；外层机器人负责发布、去重、权限和重试。