用 GitHub CLI 做 issue 与 PR 的交叉…

当 issue/PR backlog 快速膨胀、需要在上 sprint 前或每周做一次系统性 triage 时，用并行采集 + 交叉分析找出重复、缺口和冲突。

适用场景

解决思路

1. Phase 0 前置检查：运行 `git rev-parse --is-inside-work-tree` 确认在 git 仓库内，运行 `gh auth status` 确认 GitHub CLI 已认证，并用 `date +%Y-%m-%d` 获取当前日期。
2. Phase 1 并行采集数据：同时执行 issue 和 PR 的采集。Issue 侧：`gh repo view --json nameWithOwner -q .nameWithOwner` 获取仓库名；`gh issue list --state open --limit 150 --json number,title,author,createdAt,updatedAt,labels,assignees,body` 拉取打开的 issue；`gh issue list --state closed --limit 20 --json number,title,labels,closedAt` 拉取最近关闭的 issue；`gh api "repos/{owner}/{repo}/collaborators" --jq '.[].login'` 获取协作者列表。
3. Phase 1 PR 侧：`gh pr list --state open --limit 200 --json number,title,author,createdAt,updatedAt,additions,deletions,changedFiles,isDraft,mergeable,reviewDecision,statusCheckRollup,body` 拉取打开的 PR；若仓库超过 200 个打开的 PR，用 `--search "is:pr is:open sort:updated-desc"` 分页；对每个候选 PR（同领域或同作者）用 `gh pr view {num} --json files --jq '[.files[].path] | join(",")'` 获取修改的文件列表，用于重叠检测。
4. Phase 2 分别执行 issue 和 PR 的单独 triage：Issue 侧做分类（Bug/Feature/Enhancement/Question/Duplicate）、风险等级（红/黄/绿）、陈旧度（>30 天）、并通过扫描 `fixes #N`、`closes #N`、`resolves #N` 建立 `issue_number → [PR numbers]` 映射。PR 侧做大小分级（XS/S/M/L/XL）、CI 状态（clean/dirty）、区分内部 PR 与外部 PR、检测重叠（两个 PR 之间共同文件 >50%）、检测集群（同一作者有 3+ PR）。按各 skill 的标准表格展示。
5. Phase 3.1 检测双重覆盖：对每个关联 ≥2 个 PR 的 issue（通过扫描 body 和文件重叠），列出 Issue、PR1 信息、PR2 信息和推荐裁决。裁决规则：同 scope 时优先更小的（XS < S < M）；优先 CI clean 而非 dirty；若其中一个是内部 PR 则优先内部；若文件重叠 >80% 则标记为几乎必然冲突。
6. Phase 3.2 检测安全覆盖缺口：对每个红色 issue（如 #640 类型的安全审查），列出 body 中提到的子 finding，与现有 PR 的标题/正文关键词交叉比对，找出没有对应 PR 的 finding。用表格格式展示：Finding | 关联 PR | 状态，缺口标 ⚠️。
7. Phase 3.3 找出无 PR 的 P0/P1 bug：筛选带 P0 或 P1 标签（或含 "crash"、"truncat"、"cap"、"hardcoded" 等关键词）且没有任何关联 PR 的 issue，用表格展示 Issue | 标题 | 共同模式 | 预估工作量。若 3+ 个 bug 共享同一模式（如 "cap hardcodé"、"exit code perdu"），建议组织一次集中 sprint。
8. Phase 3.4 分析内部 dirty PR 的可能原因：对每个 CI dirty 或 CONFLICTING 的内部 PR，检查是否有其他 PR 改动相同文件、是否有近期合并到 develop 导致冲突，并建议 rebase、关闭或等待。用表格展示 PR | Issue | 可能原因 | 行动。
9. Phase 3.5 找出没有关联 issue 的 PR：内部 PR 的 body 中没有 `fixes #N` 的，标记出来以便追溯。
10. Phase 4 输出最终结果：先展示完整的交叉分析（3.1 → 3.5），再展示数字摘要表，包含：内部可合并 PR 数、外部 quick win 数、双重覆盖（冲突）对数、无 PR 的 P0/P1 bug 数、无 PR 的安全 finding 数、需 rebase 的内部 dirty PR 数、建议关闭的 PR 数。
11. Phase 4 保存文件：用 `date +%Y-%m-%d` 构造文件名，保存到 `claudedocs/RTK-YYYY-MM-DD.md`，内容包括 Phase 2 的 issue + PR triage 表格、Phase 3 的完整交叉分析、数字摘要。保存后确认：`Sauvegardé dans claudedocs/RTK-YYYY-MM-DD.md`。
12. 保存文件的结构：标题 `# RTK Triage — YYYY-MM-DD`，副标题说明交叉了 N 个打开的 PR 和 N 个打开的 issue，然后依次是：1. 双重覆盖、2. 安全缺口、3. 无 PR 的 P0/P1、4. 内部 dirty PR、5. 内部可合并 PR、6. 外部 quick win、7. 按影响/紧急度排序的优先行动，最后是数字摘要。
13. 语言规则：接受 `en`/`fr` 参数，默认 `fr`；GitHub 评论始终用英文。
14. 安全规则：未经用户通过 AskUserQuestion 确认，绝不发布 GitHub 评论。
15. 分页规则：若 issue 或 PR 超过 200 个，提醒用户并分页（用 `--search` 或带分页的 `gh api`）。
16. Phase 3 的交叉分析始终执行——这是本 skill 的核心价值。
17. claudedocs 文件默认自动保存，除非用户说 "no save"。

适用边界 · 注意事项

• 仓库不在 GitHub 上，或没有安装并认证 `gh` CLI 时无法使用。
• issue/PR 数量极少（例如只有几个）时，交叉分析收益有限，直接单独 triage 即可。
• 需要修改 issue/PR 状态或发布评论时，本 skill 只做分析和保存，不会自动执行写操作。