TNT-Likely GitHub Issue Triage 技能
做什么
把一个 GitHub repo 的全部 open issue 拉下来,按统一维度分级排序,产出一份可维护的优先级文档(.docs/issue-triage.md),并可配合 /schedule 定期增量更新。目标:把"几十个 issue 的噪声"压成"先做哪几个"的清晰判断。
核心信念:triage 是只读的决策支持,不是替用户做决定 —— 产出文档,排好序,讲清理由,把"做不做、先做谁"留给人。
何时触发
- 用户问"还有哪些有价值的需求 / 急需修的 bug"
- 要给 backlog 排优先级 / 出 roadmap
- 要定期(周/双周)自动巡检新 issue
流程
1. 拉取(注意网络兜底)
gh 已认证即可。坑:某些网络环境(如公司 Zscaler 代理)下 gh 走 HTTPS GraphQL API 会 TLS 握手超时;失败就 unset 代理重试(git push 走 SSH 不受影响,只有 gh API 需要):
env -u HTTPS_PROXY -u HTTP_PROXY -u https_proxy -u http_proxy -u ALL_PROXY -u all_proxy \
gh issue list --repo OWNER/REPO --state open --limit 100 \
--json number,title,labels,body,comments,reactionGroups,createdAt
repo 从用户给的、或当前目录 git remote 推断。
2. 读呼声信号
- 👍 =
reactionGroups里THUMBS_UP的users.totalCount - 💬 =
comments数组长度 - 先扫一眼这个 repo 用哪个信号为主:很多 repo 用户根本不点 👍(全 0),呼声只能看评论数。别只按 👍 排序得出"全都不重要"的错误结论。
用 jq 一把梭出按呼声排序的总览:
... gh issue list ... --json number,title,labels,comments,reactionGroups \
| jq -r 'map({n:.number, up:([.reactionGroups[]?|select(.content=="THUMBS_UP")|.users.totalCount]|add // 0), c:(.comments|length), l:(.labels|map(.name)|join(",")), t:.title}) | sort_by(-.up,-.c) | .[] | "#\(.n)\t👍\(.up)\t💬\(.c)\t[\(.l)]\t\(.t)"'
3. 四级分流(核心维度)
| 级 | 判据 |
|---|---|
| 🔴 P0 | 数据正确性错误 / 崩溃卡死 / 核心功能首用即失效。最优先:用户数据被悄悄记错那种(总额对、方向/归类错,用户自己发现不了) |
| 🟡 P1 | 高呼声需求、明显性能问题、与产品核心卖点强相关的体验缺陷 |
| 🟢 P2 | 局部体验改善、有用但非紧急的功能 |
| ⚪ P3 | 锦上添花、长尾、小众、含义模糊待澄清 |
排序权重:数据正确性/崩溃 > 呼声 > 与核心卖点相关度。一个安静(0💬)但会记错账的 bug,排在热闹(5💬)的外观需求前面。
4.(深入时)用代码验证 bug
对 P0/P1 的 bug,别只信描述 —— 在 codebase 里定位相关代码,确认 bug 真实存在、找到根因行号。把"疑似 bug"升级成"已定位、可修",triage 的含金量主要来自这一步。能顺手判断工作量(S <1天 / M 1–3天 / L >3天建议拆)。
5. 主题聚类(epic 视角)
把同主题的 issue 归成 epic(例:「自动记账可靠性」「平账/余额修正」「特殊交易类型(退款/报销/红包)」「CSV 导入」)。很多 issue 一次设计能解决一串 —— 这个视角往往比逐条排序更有决策价值。
6. 产出文档
写 / 更新 .docs/issue-triage.md:
# <Repo> Issue 优先级 Triage
> 生成于 <日期> · 共 N 个 open issue
> 排序依据 + 呼声说明 + 工作量图例
## 🔴 P0 … (表格:# / 标题 / 一句判断 / 呼声 / 工作量)
## 🟡 P1 …
## 🟢 P2 …
## ⚪ P3 …
## 🧩 主题聚类(epic)
## 🗺️ 推荐 Roadmap(分波次:先数据正确性+核心功能,再高呼声功能,再体验打磨)
仅凭标题初判的标「待细看」,提示动手前需读 body / 代码。
定期运行(配合 /schedule)
让用户用 /schedule 起一个 cron(如每周一 09:00),prompt 引用本技能。增量模式:
- 读
.docs/issue-triage.md顶部的上次生成日期 gh issue list --search "created:>YYYY-MM-DD"只拉新增 issue,归入已有分级- 有新 P0 时在摘要里显著提示,别埋在文档里
红线
- 只读:不自动关闭 / 不自动评论 / 不改 issue 状态或 label —— 一切供人决策
- 不臆断价值:含义模糊的 issue 标「待澄清」,不强行归级、不编造重要性
- 诚实呼声:👍/💬 如实呈现,不夸大;repo 没人互动就说明"呼声数据弱,主要靠内容判断"