当用户要深度分析**单个** GitHub issue —— 判断它是不是真 bug、要不要修、优先级多高、或功能请求是否合理时使用。区别于全量 triage,这个聚焦一条 issue 做透:拉详情 → 判类型 → 是 bug 则结合代码库验证真实性/根因/影响面/复现/是否需修,是功能请求则评估合理性/呼声/可行性/工作量 → 给结构化结论(供决策或作评论草稿,不自动发)。触发关键词:"分析一下这个 issue"、"#123 是不是 bug"、"这个 issue 要不要修"、"这个需求合理吗"、"帮我看下 issue #N"、"analyze this issue"、"评估这个功能请求"。不适用于:一次性给所有 issue 排序(用同 plugin 的 github-issue-triage 技能)、实际写修复代码(那直接修)。
Scanned 9/5/2026
Install to Claude Code
npx -y skills add TNT-Likely/honeycomb --skill analyze-issue --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Analyze Issue?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/tnt-likely-analyze-issue)More formats (shields.io, HTML) on the badges page.
---
name: analyze-github-issue
description: 当用户要深度分析**单个** GitHub issue —— 判断它是不是真 bug、要不要修、优先级多高、或功能请求是否合理时使用。区别于全量 triage,这个聚焦一条 issue 做透:拉详情 → 判类型 → 是 bug 则结合代码库验证真实性/根因/影响面/复现/是否需修,是功能请求则评估合理性/呼声/可行性/工作量 → 给结构化结论(供决策或作评论草稿,不自动发)。触发关键词:"分析一下这个 issue"、"#123 是不是 bug"、"这个 issue 要不要修"、"这个需求合理吗"、"帮我看下 issue #N"、"analyze this issue"、"评估这个功能请求"。不适用于:一次性给所有 issue 排序(用同 plugin 的 github-issue-triage 技能)、实际写修复代码(那直接修)。
---
# 单 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,产出供人决策
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!