| name | triage |
| description | 盘点当前仓库的 open issue，按 priority × scope 打出一张排序表并给一条下一轮开发建议。只读、无副作用、不写任何本地文件 |
| disable-model-invocation | false |
盘点当前仓库的 open issue，按 priority × scope 打一张表，末尾给一条明确推荐 + 理由。
为什么存在
「未关闭项速览」原本由 saved query 承担（按 priority label 过滤 open issues），但它只做过滤、不做判断 —— priority 是唯一维度，scope（多大、有没有前置依赖）完全不体现，要知道一条贵不贵得逐个点进 issue 读正文。
而挑下一轮时的真实决策是 priority × scope 的二维权衡：一条 P0 但 XL 的，未必该排在一条 P2 但 S 的前面。这个权衡每轮都要人重做一遍。
本 skill 不取代 saved query —— saved query 是随时扫一眼的常驻入口，本 skill 是「要挑下一轮了」时跑一次的决策辅助。
三条硬约束
- 只读、无副作用：不改 issue、不打 label、不写任何本地文件、不自动
/start。决定权留给人。
- 跨平台：一律走
python3 $HOME/.claude/scripts/platform_issue.py，不直调 gh / glab（宪法明令，且 GitLab 端与云端 sandbox 都没有 gh）。
- 不新增本地索引：与「issue 是单一真源」一致，本 skill 不落任何缓存 / 清单文件。
Step 1 · 拉 open issue
python3 $HOME/.claude/scripts/platform_issue.py issue-list
按 git remote get-url origin 自动判定 GitHub / GitLab，stdout 是归一 json 数组（number / title / body / url / labels，与 issue-view 同 schema；另带 state，本子命令只列 open 故恒为 open）。
拿不到数据就把原因照实说出来并停在这里，不要凭印象手写一张表。 本子命令实际会出现的退出码只有三种：2 平台未知（无 origin / 自托管 URL 不含 gitlab 字样）、4 gh / glab 没装、1 其余一切失败（含 auth 过期 —— 那是底层 CLI 的非零退出，helper 原样透传它的 stderr，不会变成 scripts/platform_issue.md 降级表里的 3；exit 3 只有 auth-status 子命令才产生）。所以判 auth 问题要看 stderr 内容，别按数值分支。
云端 sandbox 跑不了这条（gh / glab 均未安装），那边要走 GitHub MCP。本 skill 当前只面向本机；真要上云端时换的是 Step 1 这一步的取数方式，后面的判断逻辑不用动。
Step 2 · 逐条定档
每条 issue 取四样：
- priority：直接读
labels 里的 priority:*。没有就标 未标。
- area：读
labels 里的 area:*。
- 自动化状态：读
labels 里有没有 auto:take（owner 已背书 routine 自动做）或 auto:skip（/routine-dev 已判定不自动做，下次不再读它的正文）。两者都没有就留空。
- scope：优先读
body 里现成的 scope 字段（feat / spike 两个 issue 模板本来就有这栏），归一到 S / M / L / XL。
scope 的两条来源必须在表里区分开：
| 来源 | 标记 | 说明 |
|---|
| issue 正文的 scope 字段 | S / M / L / XL | 确定性高、可追溯 |
| 正文没写、由模型现估 | S? / M? / L? / XL? | 同一条 issue 两次跑可能给不同档 |
| 正文没写且估不出 | 未填 | 如实标，不许猜一个填进去 |
本仓早期 issue 的正文没有 scope 字段，覆盖率天然不齐 —— 表里出现一片 未填 是数据的实况，不是本 skill 没跑好。
Step 3 · 出表 + 给一条推荐
按 priority 升序（P0 在前）、同 priority 内 scope 小的在前，打一张表：
| # | priority | scope | area | 自动化 | 一句话 |
|---|
| #98 | P0 | S | skill | | …… |
| #39 | P0 | XL | skill | skip | …… |
然后给一条推荐，附理由。理由里必须把依据摊开：
- priority 来自哪个 label；
- scope 来自正文字段还是模型现估（后者明说）；
- 为什么它排在别的 P0 前面。
「自动化」列怎么用：take 是「routine 下次会做，人多半不用管」；skip 恰恰相反 —— routine 已经放弃它了，它只可能由人来做，所以同等条件下它比一条 take 更该排前面。这一列不参与排序计算，但推荐理由里要提一句。
防权威性错觉：推荐结论是 LLM 判断，不是计算结果。把依据摊开的目的就是让人一眼能推翻它 —— 给一个看起来很确定、却没法核对的结论，比不给更坏。
明确不做
- 不改任何 issue 状态、不打 label、不发评论。
- 不自动开轮 —— 人看完表自己决定跑不跑
/start <issue#>。
- 不写本地索引 / 缓存文件。
- 不列 closed issue —— 本 skill 只回答「下一轮挑什么」。
