8.2 KiB
| name | description |
|---|---|
| gitlink-maintainer-radar | 维护者雷达：面向 GitLink 仓库维护者，联合扫描 open Pull Request、open Issue、消息提醒、review 分配和等待时长，识别响应超时、review 负载失衡、负责人长期停滞等协作瓶颈，生成按优先级排序的处置清单、催办建议和责任调整建议。用于用户需要值班巡检待办、判断哪些事项被晾着了、找出 reviewer 瓶颈、发现有负责人但无进展的条目，或生成维护者今日工作面板时。 |
gitlink-maintainer-radar
CRITICAL - 先阅读 ../gitlink-shared/SKILL.md，按其中的认证、全局参数和安全规则执行。
CRITICAL - 所有 GitLink 操作只使用 gitlink-cli，不要改用 gh、glab 或网页猜测数据。
CRITICAL - 默认只读分析。只有在用户明确要求时才回写评论、标签或成员分配。
这个 skill 不再做“把通知列表抄一遍”的弱摘要，而是把三类真正影响维护者效率的治理信号合在一起：
- 响应时效雷达：找出超出响应 SLA 的 Issue 和 PR。
- Review 负载雷达：判断 reviewer 是否失衡，以及哪些 PR 因分配不均而卡住。
- 责任停滞雷达：识别已经有 assignee / reviewer，但长期没有推进动作的条目。
把它当作“维护者值班面板”来用，而不是通知中心。
核心能力
1. 响应时效雷达
优先识别这些最有用的 SLA 违约场景：
- 超过 24 小时无人首次响应的 Issue
- 超过 3 天无人 review 的 PR
- 已经
approve但 2 天内没有推进合并或进一步处理的 PR requested changes之后作者长期未更新的 PR- 作者已经更新、但维护者超过 48 小时未复看的 PR
这些信号最适合直接形成“今天先处理什么”的清单。
2. Review 负载雷达
从多人协作角度，重点看：
- 哪些 reviewer 手上挂了太多待处理 PR
- 哪些 reviewer 长期没有被分配，存在空闲容量
- 哪些 PR 因 reviewer 单点瓶颈停滞
- 哪些 PR 一直在同一个 reviewer 身上来回等待
- 哪些高优先级 PR 值得建议重新分配 reviewer
这个模块的目标不是简单统计数量，而是指出“哪里需要重新分配”。
3. 责任停滞雷达
重点识别这些“看起来有人负责，实际上没人推进”的场景：
- 有 assignee 的 Issue 长期无新评论、无状态更新
- 有 reviewer / assignee 的 PR 长期无 review、无结论、无合并动作
- 同一个责任人名下积压了过多停滞事项
- 条目虽然被分配，但最近一次动作仍然停留在发起人一侧
- 责任关系已经失效，应该提醒、转派或收口
这个模块比单纯的 stale 检查更实用，因为它关心的是“责任失效”。
4. 统一处置建议
把前面三类信号收敛成维护者真正能执行的动作：
- 先回复哪些条目，快速消除首响超时
- 哪些 PR 需要重新分配 reviewer
- 哪些 assignee / reviewer 需要提醒
- 哪些长期停滞条目应该收口、降级或重新明确责任人
- 哪些条目虽然 noisy，但本轮值班可以忽略
判断规则
HOT
- 超过 SLA 且当前明显在等维护者动作
- 已
approve但无人推进合并，且影响版本节奏 - 高优先级 PR 因 reviewer 负载失衡卡住
- 有负责人但超过阈值完全无动作
- 首次贡献者的高质量提交长期无人回应
WATCH
- 尚未超 SLA，但已经接近阈值
- 责任人存在，但推进节奏明显偏慢
- reviewer 负载有失衡趋势，但还未造成明确阻塞
- 讨论在继续，但一直没有收敛到下一步动作
BACKGROUND
- 普通消息提醒和不会改变维护节奏的系统通知
- 已明确有人处理且最近有进展的条目
- 短期不影响主线和协作节奏的低优先级事项
详细矩阵和建议阈值见 references/triage-matrix.md。
工作流
Step 1：确认仓库与维护者视角
先确认当前登录用户和仓库范围：
gitlink-cli auth status
gitlink-cli repo +info --owner <owner> --repo <repo> --format json
如果用户没有显式提供仓库，且当前目录就是目标仓库，可以使用自动解析。
Step 2：抓取基础队列数据
至少获取这几组数据：
# 未读消息，用于捕捉 @ 提醒和人工催办信号
gitlink-cli api GET "users/<login>/messages.json" --query "status=1&limit=40" --format json
# open PR
gitlink-cli pr +list --owner <owner> --repo <repo> --state open --format json
# open Issue
gitlink-cli issue +list --owner <owner> --repo <repo> --state open --format json
如果队列很大，先拉最近 40 条，再聚焦高风险对象。
Step 3：为高风险 PR 补拉 review 与等待链路
对命中 SLA、负载失衡或停滞信号的 PR，继续获取：
gitlink-cli pr +view --owner <owner> --repo <repo> -i <number> --format json
gitlink-cli pr +reviews --owner <owner> --repo <repo> -i <number> --format json
gitlink-cli pr +version-diff --owner <owner> --repo <repo> -i <number> --format json
要明确判断：
- 当前在等作者、等 reviewer，还是等 maintainer 决策
- 最近一次有效推进动作是谁完成的
- review 结论是否已经形成，但没有后续动作
- 是否存在 reviewer 过载导致的人工瓶颈
如果用户需要深入判断代码可行性，切换到 gitlink-pr-assessor。如果用户要判断是否适合集成主线，切换到 gitlink-pr-integrator。
Step 4：为停滞 Issue 建立责任视图
对 Issue 至少判断：
- 是否已有 assignee
- 最近一次评论或状态更新距离现在多久
- 当前是在等提问方补信息，还是在等维护者接手
- 是否值得补标签、转派或收口
Step 5：构建统一处置面板
输出不止要说明“发生了什么”，还要告诉维护者下一步怎么做：
- 哪些条目要先回复，修复 SLA 超时
- 哪些 PR 应该重新分配 reviewer
- 哪些条目需要提醒当前责任人
- 哪些条目应该转派、收口或延后
- 如果用户要求，生成适合直接发布的中文提醒评论草稿
评论草稿模板见 references/comment-templates.md。
Step 6：输出维护者报告
报告应至少包含：
- SLA 超时条目
- reviewer 负载失衡情况
- 有负责人但停滞的条目
- 今天建议先做的动作
- 可延后的背景项
推荐输出模板：
# 维护者雷达报告
## SLA 超时
- Issue #87：超过 24 小时无人首次响应，当前仍无明确责任人。
- PR #123：作者 2 天前已按 review 修改，当前等待维护者复看。
## Review 负载
- reviewer A 当前挂着 5 个待 review PR，是主要瓶颈。
- reviewer B 最近没有分配到待处理条目，存在可释放容量。
## 责任停滞
- Issue #91 已分配给 maintainer C，但 6 天没有新动作。
- PR #118 有 reviewer，但上一轮意见后一直无人推进结论。
## 今日建议动作
- 先回复 Issue #87，避免继续首响超时。
- 把 PR #126 从 reviewer A 转给 reviewer B。
- 对 PR #118 发送一次责任确认提醒。
## 可延后
- 项目关注、点赞、普通系统通知可忽略。
评论与写操作规则
只有用户明确要求时，才执行这些动作：
- 给 PR / Issue 发表评论
- 调整标签
- 变更成员或分配关系
- 标记消息已读
在回写之前，先把拟执行动作和目标对象列清楚，再执行。
处理边界
- 这个 skill 的重点是“维护治理与协作分流”，不是完整代码审查。
- 它比
gitlink-issue-triage更偏责任推进，而不是 Issue 语义分类。 - 它比
gitlink-health、gitlink-insight更偏当下值班，而不是全局健康分析。 - 如果仓库没有启用 GitLink 平台 CI，不影响这个 skill 的核心价值。
典型触发语句
- “帮我看下这个仓库哪些 Issue 和 PR 被晾着了。”
- “扫描一下 open PR 和 open Issue，给我一个维护者值班清单。”
- “哪些 PR 因 reviewer 负载不均卡住了？”
- “找出有负责人但没进展的条目。”
- “把今天必须回复、必须转派、必须催办的事项挑出来。”