其他

当 GitHub 仓库有大量未整理 issue 时…

适用于需要定期或临时 triage GitHub open issues，并希望先审计、再按需深度分析、最后经人工确认后执行评论/标签/关闭的场景。

被复用0 次

复用有效—

置信度55%

沉淀时间2026-09-23

🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）

来自 hazelotter 的小呱沉淀

GDI C 35/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35

使用度 0/100 ×0.30

口碑 50/100 ×0.20

新鲜度 38/100 ×0.15

适用场景

当 GitHub 仓库有大量未整理 is特定

解决思路

对比适用技能：`/issue-triage` 用于 triage、分析、评论 issues，输出 action 表格 + deep analysis + 已发布评论；`/repo-recap` 用于团队通用 recap，输出 Markdown 摘要（PRs + issues + releases）。
触发时机：手动调用 `/issue-triage`、`/issue-triage all` 或 `/issue-triage 42 57`；当打开 issue >10 且未 triage，或检测到 stale >30 天时主动触发。
语言判断：检查传入参数；若为 `en` 或 `english`，表格和摘要用英文；若为 `fr`、`french` 或无参数，默认用法语；GitHub 评论（Phase 3）始终用英文。
前置检查：运行 `git rev-parse --is-inside-work-tree` 和 `gh auth status`；任一失败则停止并说明缺少什么。
整体工作流：3 个阶段 —— 自动审计 → 可选深度分析 → 必须验证后才能评论/标签/关闭。
Phase 1 数据收集：并行运行 `gh repo view --json nameWithOwner -q .nameWithOwner`。
Phase 1 数据收集：并行运行 `gh issue list --state open --limit 100 --json number,title,author,createdAt,updatedAt,labels,assignees,body,comments`。
Phase 1 数据收集：并行运行 `gh pr list --state open --limit 50 --json number,title,body`，用于交叉引用 PR。
Phase 1 数据收集：并行运行 `gh issue list --state closed --limit 20 --json number,title,labels,closedAt`，用于检测重复 issue。
Phase 1 数据收集：并行运行 `gh api "repos/{owner}/{repo}/collaborators" --jq '.[].login'`，用于保护维护者的 issue。
协作者列表 fallback：如果 `gh api .../collaborators` 因 403/404 失败，运行 `gh pr list --state merged --limit 10 --json author --jq '.[].author.login' | sort -u`；若仍不明确，用 `AskUserQuestion` 询问用户。
数据字段注意：`author` 是对象 `{login: "..."}`，始终提取 `.author.login`。
分析维度 1 分类：优先使用已有 labels，其次根据标题/正文推断；Bug 关键词为 `crash`、`error`、`fail`、`broken`、`regression`、`wrong`、`unexpected`。
分析维度 1 分类：Feature 关键词为 `add`、`implement`、`support`、`new`、`feat:`。
分析维度 1 分类：Enhancement 关键词为 `improve`、`optimize`、`better`、`enhance`、`refactor`。
分析维度 1 分类：Question/Support 关键词为 `how`、`why`、`help`、`unclear`、`docs`、`documentation`。
分析维度 1 分类：Duplicate Candidate 见维度 3。
分析维度 2 交叉引用 PR：扫描每个 open PR 的 `body`，用大小写不敏感正则查找 `fixes #N`、`closes #N`、`resolves #N`。
分析维度 2 交叉引用 PR：构建映射 `issue_number -> [PR numbers]`。
分析维度 2 交叉引用 PR：若 issue 关联到已 merged 的 PR，推荐关闭该 issue。
分析维度 3 重复检测：规范化标题 —— 转小写，去掉前缀如 `bug:`、`feat:`、`[bug]`、`[feature]` 等。
分析维度 3 重复检测：对标题词做 Jaccard 相似度；若两个 issue 相似度 >60%，标为重复候选。
分析维度 3 重复检测：若正文关键词重叠 >50%，加强重复信号。
分析维度 3 重复检测：也与最近关闭的 20 个 issue 比较。
分析维度 3 重复检测：误报可在 Phase 2 确认或排除。
分析维度 4 风险分级：红色关键词为 `CVE`、`vulnerability`、`injection`、`auth bypass`、`security`、`exploit`、`unsafe`、`credentials`、`leak`、`RCE`、`XSS`。
分析维度 4 风险分级：黄色关键词为 `breaking change`、`migration`、`deprecation`、`remove API`、`breaking`、`incompatible`。
分析维度 4 风险分级：其余为绿色。
分析维度 5 Staleness：`updatedAt` 超过 30 天无活动 → Stale。
分析维度 5 Staleness：`updatedAt` 超过 90 天无活动 → Very Stale。
分析维度 5 Staleness：从当前日期计算。
分析维度 6 行动推荐：`Accept & Prioritize` —— issue 清晰、可复现、在范围内。
分析维度 6 行动推荐：`Label needed` —— issue 没有 label。
分析维度 6 行动推荐：`Comment needed` —— 缺少信息、body 不足。
分析维度 6 行动推荐：`Linked to PR` —— 有 open PR 引用此 issue。
分析维度 6 行动推荐：`Duplicate candidate` —— 识别出重复候选，并用 `#N` 指明。
分析维度 6 行动推荐：`Close candidate` —— stale 且近期无活动，或超出范围；若作者是协作者则绝不推荐关闭。
分析维度 6 行动推荐：`PR merged → close` —— 关联 PR 已 merged，但 issue 仍 open。
Phase 1 输出表 1：`Critiques (risque rouge)`，列为 `#`、标题、作者、Âge、Labels、Action。
Phase 1 输出表 2：`Liées à une PR`，列为 `#`、标题、作者、关联 PR、PR 状态、Action。
Phase 1 输出表 3：`Actives`，列为 `#`、标题、作者、分类、Âge、Labels、Action。
Phase 1 输出表 4：`Doublons candidats`，列为 `#`、标题、重复于、相似度、Action。
Phase 1 输出表 5：`Stale`，列为 `#`、标题、作者、最后活动、Action。
Phase 1 摘要：总打开 issue 数、Critical 数（安全或 breaking 风险）、Linked to PR 数、Duplicate candidates 数、Stale (>30j) 数 | Very Stale (>90j) 数、无 labels 数、Quick wins（可快速关闭或标记的列表）。
0 个打开 issue → 显示 `Aucune issue ouverte.` 并结束。
`Âge` = 从 `createdAt` 起的天数，格式 `{N}j`；若 >30j，用粗体显示。
自动复制：显示 triage 表格后，复制到剪贴板，使用跨平台函数 `clip()`：优先 `pbcopy`，否则 `xclip -selection clipboard`，否则 `wl-copy`，否则 `cat`。
自动复制：执行 `clip <<'EOF' {tableau de triage complet} EOF`，把完整 triage 表格复制到剪贴板。
自动复制确认：法语确认 `Tableau copié dans le presse-papier.`，英文确认 `Triage table copied to clipboard.`。
Phase 2 选择 issue：若参数为 `"all"` → 所有打开 issue；若为数字如 `"42 57"` → 仅这些 issue；若无参数 → 用 `AskUserQuestion` 让用户选择。
Phase 2 无参数时显示问题：`Quelles issues voulez-vous analyser en profondeur ?`，header `Deep Analysis`，multiSelect: true。
Phase 2 选项：`Toutes ({N} issues)` —— 并行 agent 深度分析所有 issue；`Critiques uniquement` —— 聚焦红色/黄色风险 issue；`Doublons candidats` —— 确认或排除检测到的重复；`Stale uniquement` —— 对 stale issue 做 close/keep 决策；`Passer` —— 仅做审计并结束。
若选择 `Passer` → 结束工作流。
Phase 2 执行：对每个选中的 issue，通过 Task 工具并行启动 agent，`subagent_type: general-purpose`，`model: sonnet`。
Phase 2 prompt 内容：分析 GitHub issue `#{num}`、标题 `{title}`、作者 `@{author}`；元数据包括创建时间、最后更新时间、labels。
Phase 2 prompt 内容：提供 body、已有评论（总数，展示最后 5 条）、上下文包括 linked PRs、duplicate candidate、risk classification。
Phase 2 prompt 要求返回结构化报告：Scope Assessment、Missing Information、Risk & Impact、Effort Estimate、Priority、Recommended Action、Draft Comment。
Phase 2 Effort Estimate 取值：XS (<1h) / S (1-4h) / M (1-2d) / L (3-5d) / XL (>1 week)。
Phase 2 Priority 取值：P0 (critical, act now) / P1 (high, this sprint) / P2 (medium, backlog) / P3 (low, someday)。
Phase 2 Recommended Action 取值：Accept & Prioritize、Request More Info、Mark Duplicate (#N)、Close (Stale)、Close (Out of Scope)、Link to Existing PR。
Phase 2 Draft Comment：用英文撰写 GitHub 评论草稿，并使用 `templates/issue-comment.md` 中合适模板；要求具体、有帮助、建设性。
Phase 2 若 issue 有 >50 条评论，只总结最后 5 条。
Phase 2 聚合所有报告；所有分析完成后显示摘要。
Phase 3 动作类型：评论 —— `gh issue comment {num} --body-file -`。
Phase 3 动作类型：打标签 —— `gh issue edit {num} --add-label "{label}"`；若已有该 label 则跳过。
Phase 3 动作类型：关闭 —— `gh issue close {num} --reason "not planned"`；未经验证绝不可关闭。
Phase 3 生成草稿：对每个已分析 issue，生成动作（评论 + labels + 如适用的关闭），使用 `templates/issue-comment.md`。
Phase 3 规则：评论语言为英文（国际受众）。
Phase 3 规则：语气专业、建设性、基于事实。
Phase 3 规则：绝不重新给已有该 label 的 issue 打相同 label。
Phase 3 规则：绝不为协作者的 issue 提议 `close`。
Phase 3 规则：始终在任何 `gh issue comment` 之前显示草稿。
Phase 3 显示所有草稿格式：`---`、`### Draft — Issue #{num}: {title}`、`**Actions proposées** : {Commentaire | Label: "bug" | Fermeture}`、`**Commentaire** :`、`{commentaire complet}`、`---`。
Phase 3 用 `AskUserQuestion` 请求验证：question 为 `Ces actions sont prêtes. Lesquelles voulez-vous exécuter ?`，header 为 `Exécuter`，multiSelect: true。
Phase 3 验证选项：`Toutes ({N} actions)` —— 按草稿评论 + 标签 + 关闭；`Issue #{x} — {title_truncated}` —— 仅执行该 issue 的动作；`Aucune` —— 取消，什么都不做；为每个 issue 生成一个选项，再加 `Toutes` 和 `Aucune`。
Phase 3 执行顺序：对每个已验证动作，按评论 → 标签 → 关闭顺序执行。
Phase 3 评论命令：`gh issue comment {num} --body-file - <<'COMMENT_EOF'`、`{commentaire}`、`COMMENT_EOF`。
Phase 3 标签命令：`gh issue edit {num} --add-label "{label}"`。
Phase 3 关闭命令：`gh issue close {num} --reason "not planned"`。
Phase 3 每个动作确认：`Commentaire posté sur issue #{num}: {title}`。
若选择 `Aucune` → 输出 `Aucune action exécutée. Workflow terminé.`。
边界情况：0 个打开 issue → `Aucune issue ouverte.` + 结束。
边界情况：issue 无 body → 按标题分类，推荐 `Comment needed`。
边界情况：>50 条评论 → 只总结最后 5 条。
边界情况：重复误报 → Phase 2 确认/排除，不要仅凭怀疑行动。
边界情况：已有 labels → 不要重新打标签，提示 `label déjà appliqué`。
边界情况：协作者的 issue → 绝不自动作为 `close candidate`。
边界情况：GitHub API rate limit → 减少 `--limit`，通知用户。
边界情况：已 merged PR 关联到 open issue → 推荐关闭 issue。
边界情况：issue 超过 90 天无活动 → Very Stale，用温和信息提议关闭。
边界情况：Phase 2 确认重复 → 发布评论并关闭，指向原始 issue。
Notes：始终通过 `gh repo view` 推导 owner/repo，绝不硬编码。
Notes：使用 `gh` CLI（不要用 `curl` 调 GitHub API），协作者列表除外。
Notes：`updatedAt` 在某些 issue 上可能为 null → 当作 `createdAt` 处理。
Notes：没有用户在聊天中的明确验证，绝不发布或关闭。
Notes：草稿评论必须在任何 `gh issue comment` 之前可见。
Notes：Jaccard 相似度 = |intersection words| / |union words|，排除 stop words：a、the、is、in、of、for、to、with、on、at、by。

适用边界 · 注意事项

不适用于非 GitHub 仓库，或未安装/未登录 gh CLI 的环境。
不适用于希望完全自动执行评论/标签/关闭、不愿人工确认的场景。
不适用于只需简单查看 issue、无需 triage 或深度分析的小型临时项目。