# Analyze Github Issue

> 当用户要深度分析**单个** GitHub issue —— 判断它是不是真 bug、要不要修、优先级多高、或功能请求是否合理时使用。区别于全量 triage,这个聚焦一条 issue 做透:拉详情 → 判类型 → 是 bug 则结合代码库验证真实性/根因/影响面/复现/是否需修,是功能请求则评估合理性/呼声/可行性/工作量 → 给结构化结论(供决策或作评论草稿,不自动发)。触发关键词:"分析一下这个 issue"、"#123 是不是 bug"、"这个 issue 要不要修"、"这个需求合理吗"、"帮我看下 issue

- Skill: `tnt-likely/analyze-github-issue` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tnt-likely/analyze-github-issue`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tnt-likely/analyze-github-issue/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: TNT-Likely (https://skillmd.com/u/tnt-likely)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tnt-likely/analyze-github-issue

---


# 单 Issue 深度分析技能

## 做什么

对**一条** GitHub issue 做透彻分析,回答四个问题:

1. **是不是真问题?** —— bug 真实存在 / 使用误解 / 已被修复 / 无法复现
2. **要不要修 / 要不要做?**
3. **优先级多高?**
4.(功能请求)**合理吗?契合产品吗?**

和 `github-issue-triage` 技能互补:triage 是**宏观全量排序**,本技能是**单点深挖**。常见组合:triage 选出可疑/高价值的,再用本技能逐个做透。

## 流程

### 1. 拉取 issue 全文

```bash
env -u HTTPS_PROXY -u HTTP_PROXY -u https_proxy -u http_proxy -u ALL_PROXY -u all_proxy \
gh issue view N --repo OWNER/REPO \
  --json number,title,body,labels,comments,reactionGroups,state,author
```

读完整 body **加所有评论** —— 评论里常有复现补充、维护者回应、重复线索、版本信息。

### 2. 判类型

bug / 功能请求 / question(使用问题) / 重复 / 信息不足。先定性,再走对应分支。

### 3a. 如果是 Bug —— 必须用代码验证,别只信描述

- 在 codebase 定位相关代码,**确认 bug 真实存在**(找到会出错的那几行)
- 讲清:**根因**(哪行、为什么错)、**影响面**(谁会中招、多频繁)、**能否复现**(给最小路径)、**是否已被其它改动修掉**
- 区分:真 bug / 配置或使用问题 / 环境特定 / 描述不实
- 危害分级:**数据正确性错误、崩溃** 最高;偶发体验问题低
- 给**是否需要修**的明确结论 + 修复思路 + 工作量(S/M/L)

> 实战参照:有的 issue 报"AI 解析失败",定位到 `amount as num?` 强转字符串直接崩 —— 真 bug,可定位可修;有的报"自动记账没反应"实为通知权限没开 —— 使用问题,引导即可,不动代码。**结论必须落到代码或事实,不能凭描述拍脑袋。**

### 3b. 如果是功能请求 —— 评估合理性,而非照单全收

- **契合度**:符合产品定位与现有信息架构吗?会不会把 app 撑成四不像?
- **普遍 vs 小众**:看呼声(👍/💬)+ 是不是只有提出者一个人的特殊流程
- **已有替代**:现有功能能否绕过 / 组合实现?
- **可行性 / 成本**:技术工作量?有无平台 / 合规限制(如某些权限上架受限)
- **拆分**:大需求拆成"先做最痛的小核心"
- 结论:**建议做 / 可做但不急 / 不建议做(给理由)/ 需求方补充信息**

### 4. 输出结构

```
## #N <标题>
- 类型:bug / feature / question / …
- 结论:<真 bug 建议修 / 合理,P1 建议做 / 使用问题,引导即可 / 不建议做:…>
- 依据:<代码定位 file:line / 呼声 / 契合度分析>
- 优先级:🔴P0 / 🟡P1 / 🟢P2 / ⚪P3 + 一句理由
- 工作量:S / M / L
- 下一步:<修复思路 / 拆分方案 / 要追问的信息>
```

可直接作为 issue 评论草稿交给用户,但**不自动发评论、不改 issue 状态**。

## 红线

- bug 结论必须有**代码依据** —— 不能只凭 issue 描述断言"是 bug"
- 功能请求**诚实评估**,该说"不建议做"就说清理由 —— 不当老好人照单全收
- **只读**:不自动评论 / 关闭 / 改 label,产出供人决策