Analyze issue

Skill TNT-Likely/honeycomb/plugins/github-issue-triage/skills/analyze-issue

🍯 AI 开发能力沉淀仓 — 跨工具可复用的 skills 集合(Claude Code plugin marketplace 分发,SKILL.md 跨工具可用)

Install

npx -y skills add TNT-Likely/honeycomb --skill analyze-issue

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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

SKILL.md

3.9 KB, as published. Nobody here has run it

单 Issue 深度分析技能

做什么

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

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

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

流程

1. 拉取 issue 全文

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,产出供人决策