feat(skills): 新增 gitlink-maintainer-radar skill
This commit is contained in:
parent
71ca2bb683
commit
57b65d88ce
|
|
@ -0,0 +1,223 @@
|
|||
---
|
||||
name: gitlink-maintainer-radar
|
||||
description: "维护者雷达：面向 GitLink 仓库维护者，联合扫描 open Pull Request、open Issue、消息提醒、review 分配和等待时长，识别响应超时、review 负载失衡、负责人长期停滞等协作瓶颈，生成按优先级排序的处置清单、催办建议和责任调整建议。用于用户需要值班巡检待办、判断哪些事项被晾着了、找出 reviewer 瓶颈、发现有负责人但无进展的条目，或生成维护者今日工作面板时。"
|
||||
---
|
||||
|
||||
# gitlink-maintainer-radar
|
||||
|
||||
**CRITICAL - 先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)，按其中的认证、全局参数和安全规则执行。**
|
||||
**CRITICAL - 所有 GitLink 操作只使用 `gitlink-cli`，不要改用 `gh`、`glab` 或网页猜测数据。**
|
||||
**CRITICAL - 默认只读分析。只有在用户明确要求时才回写评论、标签或成员分配。**
|
||||
|
||||
这个 skill 不再做“把通知列表抄一遍”的弱摘要，而是把三类真正影响维护者效率的治理信号合在一起：
|
||||
|
||||
1. **响应时效雷达**：找出超出响应 SLA 的 Issue 和 PR。
|
||||
2. **Review 负载雷达**：判断 reviewer 是否失衡，以及哪些 PR 因分配不均而卡住。
|
||||
3. **责任停滞雷达**：识别已经有 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`](references/triage-matrix.md)。
|
||||
|
||||
## 工作流
|
||||
|
||||
### Step 1：确认仓库与维护者视角
|
||||
|
||||
先确认当前登录用户和仓库范围：
|
||||
|
||||
```bash
|
||||
gitlink-cli auth status
|
||||
gitlink-cli repo +info --owner <owner> --repo <repo> --format json
|
||||
```
|
||||
|
||||
如果用户没有显式提供仓库，且当前目录就是目标仓库，可以使用自动解析。
|
||||
|
||||
### Step 2：抓取基础队列数据
|
||||
|
||||
至少获取这几组数据：
|
||||
|
||||
```bash
|
||||
# 未读消息，用于捕捉 @ 提醒和人工催办信号
|
||||
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，继续获取：
|
||||
|
||||
```bash
|
||||
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`](references/comment-templates.md)。
|
||||
|
||||
### Step 6：输出维护者报告
|
||||
|
||||
报告应至少包含：
|
||||
|
||||
1. SLA 超时条目
|
||||
2. reviewer 负载失衡情况
|
||||
3. 有负责人但停滞的条目
|
||||
4. 今天建议先做的动作
|
||||
5. 可延后的背景项
|
||||
|
||||
推荐输出模板：
|
||||
|
||||
```markdown
|
||||
# 维护者雷达报告
|
||||
|
||||
## 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 负载不均卡住了？”
|
||||
- “找出有负责人但没进展的条目。”
|
||||
- “把今天必须回复、必须转派、必须催办的事项挑出来。”
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
interface:
|
||||
display_name: "维护者雷达"
|
||||
short_description: "识别响应超时、review 失衡和责任停滞，生成维护者处置面板。"
|
||||
default_prompt: "Use $gitlink-maintainer-radar 扫描这个 GitLink 仓库当前的响应 SLA、review 负载和责任停滞情况，输出按优先级排序的处置清单和建议动作。"
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 164 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 93 KiB |
|
|
@ -0,0 +1,91 @@
|
|||
# Codex 验证记录（2026-06-26）
|
||||
|
||||
Agent 平台：Codex
|
||||
|
||||
验证目标：确认 `gitlink-maintainer-radar` 能针对 GitLink 仓库的 open PR 与 open Issue 队列输出维护者可直接执行的值班报告，识别响应超时、review 分配缺失、责任停滞和今日优先动作。
|
||||
|
||||
验证结果如下：
|
||||
|
||||
# GitLink/gitlink-cli 维护者雷达报告
|
||||
|
||||
扫描时间：2026-06-26 11:46 +08:00
|
||||
|
||||
open PR：156 条
|
||||
|
||||
open Issue：按客户端过滤 `status_name != 关闭` 后为 9 条
|
||||
|
||||
数据说明：GitLink 的 `--state open` 返回中混入了关闭 Issue，已按状态二次过滤。
|
||||
|
||||
### 今日最优先处理
|
||||
|
||||
1. **PR #225 `feat(repo): add scaffold creation options`**
|
||||
- 状态：已 `approved`，但 open 已约 10.2 天，review 后仍未推进。
|
||||
- 建议：今天优先做合并前确认或说明阻塞原因。这是最短动作、收益最高的一项。
|
||||
|
||||
2. **Issue #17 `API是否支持自动读取仓库内文件（README等）？`**
|
||||
- 状态：创建约 36.1 天，0 评论，无负责人。
|
||||
- 建议：补首响，判断是 API 能力咨询、文档补充，还是转为需求。
|
||||
|
||||
3. **Issue #18 `giklink-cli issue +update后issue状态框变红色`**
|
||||
- 状态：创建约 35.0 天，0 评论，无负责人。
|
||||
- 建议：补首响并要求复现步骤；这是明确 bug 信号。
|
||||
|
||||
4. **Issue #20 `bug: api 命令单次调用不替换 :owner/:repo 占位符（0.2.0）`**
|
||||
- 状态：约 13.6 天无新动作，无负责人。
|
||||
- 建议：关联/核对 PR #281，若 #281 覆盖该问题，优先推进 #281 并在 Issue 中同步状态。
|
||||
|
||||
5. **PR #281 `fix(api): 补齐单次请求模板变量与请求头支持`**
|
||||
- 状态：新近 PR，但对应已有长期 Issue #20。
|
||||
- 建议：作为“解堵型 PR”优先 review，减少 Issue 队列停滞。
|
||||
|
||||
### SLA 超时
|
||||
|
||||
**PR 侧：**
|
||||
|
||||
- 156 条 open PR 中，139 条超过 3 天没有 review 记录。
|
||||
- 其中 53 条几乎没有有效讨论，`journals_count <= 1`，属于首响/初审明显不足。
|
||||
- 只有 4 条 open PR 有 review 记录，review 覆盖率非常低。
|
||||
|
||||
高优先级超时 PR：
|
||||
|
||||
- #225：已 approved 但未推进。
|
||||
- #228-#232：Ct201314 提交的一组 skill PR，约 13.8 天无 review、无讨论。
|
||||
- #254/#258：luwanzhou 的 API/output 修复类 PR，约 11 天无 review，且属于基础能力修复。
|
||||
- #139/#242：wiki 相关 PR，约 11.5 天无 review，功能重叠，建议一起处理。
|
||||
|
||||
**Issue 侧：**
|
||||
|
||||
- #17、#18：0 评论，超过 24 小时首响 SLA 很久。
|
||||
- #5、#14、#15、#20、#21：均无负责人且长期无新进展。
|
||||
- #2：状态未知，约 68.8 天未更新，建议收口或重新定性。
|
||||
|
||||
### Review 负载失衡
|
||||
|
||||
没有发现“某个 reviewer 明确挂载过多 PR”的证据，因为当前 PR 列表里的 `reviewers` 基本为空，review API 也只有 4 条记录。
|
||||
|
||||
真正的问题是：**review 分配缺失，而不是某个人过载。**
|
||||
|
||||
建议今天做一次分配重整：
|
||||
|
||||
- 给基础修复类 PR 指定 reviewer：#281、#254、#258。
|
||||
- 给命令族 PR 按模块分配：PR 列表组 #283/#284/#285，branch 组 #282/#268，template 组 #274/#263/#72。
|
||||
- 对超大 PR #276/#259 不直接分配普通 review，先要求拆分。
|
||||
|
||||
### 有负责人但长期无进展
|
||||
|
||||
未在当前 open PR / open Issue 的结构化字段中发现明确 assignee 或 reviewer 负责人挂载后长期停滞的 open 条目。
|
||||
|
||||
但存在“责任缺失型停滞”：
|
||||
|
||||
- PR：大量条目无 reviewer。
|
||||
- Issue：9 条 open-ish Issue 均无明确负责人。
|
||||
- 维护建议：先补负责人，再谈 SLA；否则队列会继续堆积。
|
||||
|
||||
### 今日行动清单
|
||||
|
||||
1. 推进 #225：合并前确认或说明不合并原因。
|
||||
2. 回复 Issue #17/#18：补首响并要求必要上下文。
|
||||
3. 把 #20 与 #281 绑定处理：先 review #281。
|
||||
4. 建立 reviewer 分配批次：基础修复、PR 命令、branch、template、repo、user/account 分组处理。
|
||||
5. 对 #276/#259 发出拆分要求，避免它们继续阻塞大量小 PR。
|
||||
6. 对 #228-#232 这组 skill PR 给一次批量初审或收口说明。
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
# 示例：日常值班扫描
|
||||
|
||||
用户请求：
|
||||
|
||||
```text
|
||||
Use $gitlink-maintainer-radar 扫描 Gitlink/gitlink-cli 当前 open PR 和 open Issue，告诉我今天维护者先处理什么。
|
||||
```
|
||||
|
||||
期望动作：
|
||||
|
||||
1. 读取 `../gitlink-shared/SKILL.md`。
|
||||
2. 获取当前登录用户、仓库信息、未读消息、open PR、open Issue。
|
||||
3. 对命中的高风险 PR 补拉详情和 review。
|
||||
4. 输出一份中文报告，至少包含“SLA 超时”“Review 负载”“责任停滞”“今日建议动作”。
|
||||
|
||||
输出要点：
|
||||
|
||||
- 不要把所有通知原样抄出来。
|
||||
- 优先指出卡在维护者侧的条目。
|
||||
- 优先发现超时未响应、review 失衡和责任失效。
|
||||
- 给出 3 到 5 条能直接执行的建议。
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
# 示例：版本窗口前的维护者巡检
|
||||
|
||||
用户请求：
|
||||
|
||||
```text
|
||||
Use $gitlink-maintainer-radar 看一下这个仓库在发版前有哪些 open PR / Issue 需要维护者优先清理，并帮我起草两条提醒评论。
|
||||
```
|
||||
|
||||
期望动作：
|
||||
|
||||
1. 先做常规队列扫描。
|
||||
2. 特别关注会影响发布节奏、分支稳定性、review 负载和责任停滞的条目。
|
||||
3. 从 `references/comment-templates.md` 取合适模版，结合上下文改写两条中文评论草稿。
|
||||
|
||||
输出要点：
|
||||
|
||||
- 明确区分“今天必须处理”和“可以发版后再看”。
|
||||
- 如果没有足够证据，不要武断下结论。
|
||||
- 默认给评论草稿，不要直接回写远端。
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# 示例：review 负载与责任停滞巡检
|
||||
|
||||
用户请求：
|
||||
|
||||
```text
|
||||
Use $gitlink-maintainer-radar 看一下这个仓库最近哪些 PR 因 reviewer 负载失衡或责任人停滞而卡住，给我一个转派和提醒建议清单。
|
||||
```
|
||||
|
||||
期望动作：
|
||||
|
||||
1. 读取 `../gitlink-shared/SKILL.md`。
|
||||
2. 获取 open PR、相关 review 和未读提醒。
|
||||
3. 识别 reviewer 高负载、低负载和停滞责任条目。
|
||||
4. 输出按优先级排序的“转派建议”“提醒建议”“可继续观察”三部分结果。
|
||||
|
||||
输出要点：
|
||||
|
||||
- 不只统计 reviewer 数量，要指出具体的阻塞链路。
|
||||
- 如果没有明确 reviewer 字段，也要基于 review 历史和等待关系做近似判断。
|
||||
- 默认给建议，不直接修改分配关系。
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
# 维护者常用评论模板
|
||||
|
||||
根据实际语境改写，不要机械复制。
|
||||
|
||||
## 首响超时回复
|
||||
|
||||
```text
|
||||
感谢反馈，这条事项已经进入维护者待处理队列。我先补一个响应，接下来会按优先级继续跟进；如果你这边还有复现信息、影响范围或预期行为，也可以继续补充，这会帮助更快推进。
|
||||
```
|
||||
|
||||
## 请求作者补充上下文
|
||||
|
||||
```text
|
||||
感谢提交。当前描述还不足以支持快速决策，请补充一下：
|
||||
1. 这个改动具体要解决什么问题；
|
||||
2. 你是如何验证结果的；
|
||||
3. 是否影响现有命令输出、兼容性或默认行为。
|
||||
补齐后我们继续跟进。
|
||||
```
|
||||
|
||||
## 提醒维护者侧待复看
|
||||
|
||||
```text
|
||||
这条 PR 作者已经根据前一轮意见更新，当前主要等待维护者复看。建议优先确认：
|
||||
1. 阻塞问题是否已经解决；
|
||||
2. 是否还需要补测试或补文档；
|
||||
3. 是否适合进入下一步合并评估。
|
||||
```
|
||||
|
||||
## 建议重新分配 reviewer
|
||||
|
||||
```text
|
||||
这条 PR 当前已经等待了一段时间。考虑到现有 reviewer 队列负载较高，建议补充或调整 reviewer，避免继续在同一环节排队。
|
||||
```
|
||||
|
||||
## 责任停滞提醒
|
||||
|
||||
```text
|
||||
这条事项已经分配责任人，但最近一段时间没有新的推进动作。请当前责任人确认一下后续计划；如果短期内无法继续推进，建议明确是否需要转派、补充上下文或先收口。
|
||||
```
|
||||
|
||||
## 提醒作者缩小改动范围
|
||||
|
||||
```text
|
||||
这个提交想解决的问题有价值，但当前改动面偏大，已经同时触及多个主题。建议先收敛成一个更小、边界更清晰的版本，这样更容易评审和合并。
|
||||
```
|
||||
|
||||
## 长期无响应条目收口
|
||||
|
||||
```text
|
||||
这条讨论已经停留一段时间。为了避免队列持续堆积，请作者确认是否还会继续推进；如果短期内没有计划，我们会先按当前状态收口，后续需要时可以再重新开启。
|
||||
```
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
# 维护者雷达优先级矩阵
|
||||
|
||||
这个矩阵同时覆盖三类判断：
|
||||
|
||||
1. 响应是否超出 SLA
|
||||
2. reviewer 负载是否失衡
|
||||
3. 责任关系是否失效或停滞
|
||||
|
||||
按下面的规则把条目分到 `HOT`、`WATCH`、`BACKGROUND`。多个信号同时命中时，取更高优先级。
|
||||
|
||||
## HOT
|
||||
|
||||
- Issue 超过 24 小时无人首次响应，且当前明显需要维护者接手。
|
||||
- PR 超过 3 天无人 review，或作者更新后超过 48 小时无人复看。
|
||||
- PR 已 `approve` 超过 2 天仍无人推进合并或后续处理。
|
||||
- 同一 reviewer 挂着多个高优先级 PR，已经形成明显瓶颈。
|
||||
- 条目已有 assignee / reviewer，但在阈值内完全无新动作。
|
||||
- 新贡献者提交或高影响条目因无人响应而持续停滞。
|
||||
|
||||
## WATCH
|
||||
|
||||
- 条目还未超 SLA，但已经接近阈值。
|
||||
- reviewer 分配不均已经出现趋势，但还没形成硬阻塞。
|
||||
- Issue 有责任人，但更新频率明显偏低。
|
||||
- PR 讨论在继续，但没有明确下一步负责人。
|
||||
- requested changes 后长时间无更新，需要维护者决定提醒还是收口。
|
||||
|
||||
## BACKGROUND
|
||||
|
||||
- 普通系统消息、点赞、关注、加入退出项目。
|
||||
- 已经明确归属、暂时不需要维护者处理的条目。
|
||||
- 与当前值班轮次无关的历史性提醒。
|
||||
|
||||
## 额外判断维度
|
||||
|
||||
在同优先级内，再按这些维度排序：
|
||||
|
||||
1. 是否在等待维护者，而不是等待作者。
|
||||
2. 是否影响新贡献者体验或版本节奏。
|
||||
3. 是否能通过一次短动作明显降低队列风险。
|
||||
4. 是否会牵连多个 PR、Issue 或模块。
|
||||
5. 是否存在明显的 reviewer 负载再平衡空间。
|
||||
6. 是否属于“已分配但无人推进”的责任失效。
|
||||
|
||||
## 建议阈值
|
||||
|
||||
如果仓库没有自定义规则，默认使用下面的启发式阈值：
|
||||
|
||||
- Issue 首响超时：24 小时
|
||||
- PR 首次 review 超时：72 小时
|
||||
- `approve` 后无人推进：48 小时
|
||||
- 作者按 review 更新后无人复看：48 小时
|
||||
- assignee / reviewer 名下条目长期停滞：5 到 7 天
|
||||
- reviewer 高负载预警：同一时间挂 4 个以上待处理 PR
|
||||
|
|
@ -1,306 +0,0 @@
|
|||
# gitlink-notification-digest 使用样例
|
||||
|
||||
## 样例 1：手动执行通知摘要
|
||||
|
||||
**日期**：2026-06-03
|
||||
**用户**：lindiwen23
|
||||
**CLI 版本**：gitlink-cli 0.1.18
|
||||
|
||||
### 执行流程
|
||||
|
||||
```bash
|
||||
# Step 1: 获取用户名
|
||||
gitlink-cli auth status
|
||||
# → Logged in as lindiwen23
|
||||
|
||||
# Step 2: 获取未读通知（status=1）
|
||||
gitlink-cli api GET "users/lindiwen23/messages.json" --query "status=1&limit=20" --format json
|
||||
# → 7 条未读，unread_notification=7, unread_atme=0
|
||||
|
||||
# Step 3: 获取已读通知（用于趋势分析和回顾）
|
||||
gitlink-cli api GET "users/lindiwen23/messages.json" --query "status=2&limit=20" --format json
|
||||
# → 21 条已读
|
||||
|
||||
# Step 4: 分类统计、生成摘要报告
|
||||
```
|
||||
|
||||
### 关键发现
|
||||
|
||||
| 项目 | 值 |
|
||||
|------|-----|
|
||||
| 未读通知 | 7 条 |
|
||||
| @我未读 | 0 条 |
|
||||
| 总通知 | 28 条（7 未读 + 21 已读） |
|
||||
| 不存在命令 | `gitlink-cli notification`（整个子命令不存在） |
|
||||
| 实际 API | `GET /api/users/{owner}/messages.json` |
|
||||
| CLI Bug | `api` 路径以 `/` 开头会被解析为本地文件路径 |
|
||||
|
||||
### 原始 API 返回（未读 7 条）
|
||||
|
||||
```json
|
||||
{
|
||||
"total_count": 7,
|
||||
"type": "",
|
||||
"unread_notification": 7,
|
||||
"unread_atme": 0,
|
||||
"messages": [
|
||||
{
|
||||
"id": 740214, "status": 1,
|
||||
"content": "jiangtx在 <b>jiangtx/gitlink-cli</b> 提交了一个合并请求：<b>label 模块新建</b>",
|
||||
"notification_url": "https://www.gitlink.org.cn/jiangtx/gitlink-cli/pulls/15347",
|
||||
"source": "ProjectPullRequest",
|
||||
"created_at": "2026-06-03 00:27:37", "time_ago": "10小时前",
|
||||
"type": "notification"
|
||||
},
|
||||
{
|
||||
"id": 740213, "status": 1,
|
||||
"content": "jiangtx在 <b>jiangtx/gitlink-cli</b> 提交了一个合并请求：<b>pr 域补全</b>",
|
||||
"notification_url": "https://www.gitlink.org.cn/jiangtx/gitlink-cli/pulls/15346",
|
||||
"source": "ProjectPullRequest",
|
||||
"created_at": "2026-06-03 00:11:48", "time_ago": "10小时前",
|
||||
"type": "notification"
|
||||
},
|
||||
{
|
||||
"id": 740178, "status": 1,
|
||||
"content": "jiangtx在 <b>jiangtx/gitlink-cli</b> 提交了一个合并请求：<b>repo 域补全</b>",
|
||||
"notification_url": "https://www.gitlink.org.cn/jiangtx/gitlink-cli/pulls/15343",
|
||||
"source": "ProjectPullRequest",
|
||||
"created_at": "2026-06-02 23:29:52", "time_ago": "11小时前",
|
||||
"type": "notification"
|
||||
},
|
||||
{
|
||||
"id": 740076, "status": 1,
|
||||
"content": "jiangtx在 <b>jiangtx/gitlink-cli</b> 提交了一个合并请求：<b>基础设施修复</b>",
|
||||
"notification_url": "https://www.gitlink.org.cn/jiangtx/gitlink-cli/pulls/15336",
|
||||
"source": "ProjectPullRequest",
|
||||
"created_at": "2026-06-02 16:56:47", "time_ago": "17小时前",
|
||||
"type": "notification"
|
||||
},
|
||||
{
|
||||
"id": 740002, "status": 1,
|
||||
"content": "<b>CWQ</b> 点赞了你管理的仓库 <b>CWQ/Aether_Lens_System-v0.0.1</b>",
|
||||
"notification_url": "https://www.gitlink.org.cn/caoweiqiong",
|
||||
"source": "ProjectPraised",
|
||||
"created_at": "2026-06-02 15:12:55", "time_ago": "19小时前",
|
||||
"type": "notification"
|
||||
},
|
||||
{
|
||||
"id": 738181, "status": 1,
|
||||
"content": "<b>Somebird</b> 已加入项目 <b>CWQ/Aether_Lens_System-v0.0.1</b>",
|
||||
"notification_url": "https://www.gitlink.org.cn/caoweiqiong/Aether",
|
||||
"source": "ProjectMemberJoined",
|
||||
"created_at": "2026-06-01 22:22:07", "time_ago": "1天前",
|
||||
"type": "notification"
|
||||
},
|
||||
{
|
||||
"id": 738136, "status": 1,
|
||||
"content": "<b>Somebird</b> 点赞了你管理的仓库 <b>CWQ/Aether_Lens_System-v0.0.1</b>",
|
||||
"notification_url": "https://www.gitlink.org.cn/Somebird",
|
||||
"source": "ProjectPraised",
|
||||
"created_at": "2026-06-01 20:18:28", "time_ago": "2天前",
|
||||
"type": "notification"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 分类处理
|
||||
|
||||
按 `source` 字段分类：
|
||||
|
||||
| source | 含义 | 数量 | 优先级 |
|
||||
|--------|------|------|--------|
|
||||
| `ProjectPullRequest` | 项目新 PR（jiangtx/gitlink-cli） | 4 | P2 |
|
||||
| `ProjectPraised` | 项目被点赞（CWQ/Aether_Lens_System） | 2 | P3 |
|
||||
| `ProjectMemberJoined` | 新成员加入 | 1 | P3 |
|
||||
|
||||
### 生成的报告
|
||||
|
||||
```markdown
|
||||
# 🔔 通知摘要
|
||||
|
||||
> 生成时间：2026-06-03 10:18
|
||||
> 未读通知：7 条 / 总计：28 条
|
||||
|
||||
---
|
||||
|
||||
## 一、概要
|
||||
|
||||
| 类型 | 未读 | 总计 |
|
||||
|------|------|------|
|
||||
| 🔴 @提及 | 0 | 0 |
|
||||
| 🟡 Issue 更新 | 0 | 0 |
|
||||
| 🟢 PR 更新 | 4 | ~8 |
|
||||
| 🔵 系统通知 | 3 | ~19 |
|
||||
|
||||
---
|
||||
|
||||
## 二、需要立即处理（P0）
|
||||
|
||||
🎉 无紧急通知。
|
||||
|
||||
## 三、今天处理（P1）
|
||||
|
||||
无待处理通知。
|
||||
|
||||
## 四、本周关注（P2）
|
||||
|
||||
| # | 类型 | 仓库 | 内容摘要 | 时间 |
|
||||
|---|------|------|----------|------|
|
||||
| 1 | 🟢 PR | jiangtx/gitlink-cli | label 模块新建 (#15347) | 6/3 00:27 |
|
||||
| 2 | 🟢 PR | jiangtx/gitlink-cli | pr 域补全 (#15346) | 6/3 00:11 |
|
||||
| 3 | 🟢 PR | jiangtx/gitlink-cli | repo 域补全 (#15343) | 6/2 23:29 |
|
||||
| 4 | 🟢 PR | jiangtx/gitlink-cli | 基础设施修复 (#15336) | 6/2 16:56 |
|
||||
|
||||
## 五、可忽略（P3）
|
||||
|
||||
| # | 类型 | 仓库 | 内容摘要 | 时间 |
|
||||
|---|------|------|----------|------|
|
||||
| 1 | 🔵 点赞 | CWQ/Aether_Lens_System-v0.0.1 | CWQ 点赞了仓库 | 6/2 15:12 |
|
||||
| 2 | 🔵 成员 | CWQ/Aether_Lens_System-v0.0.1 | Somebird 加入项目 | 6/1 22:22 |
|
||||
| 3 | 🔵 点赞 | CWQ/Aether_Lens_System-v0.0.1 | Somebird 点赞了仓库 | 6/1 20:18 |
|
||||
|
||||
## 六、通知趋势
|
||||
|
||||
| 时间段 | 通知数 |
|
||||
|--------|--------|
|
||||
| 今日（6/3） | 2 |
|
||||
| 昨日（6/2） | 3 |
|
||||
| 本周（6/1-6/3） | 8 |
|
||||
|
||||
## 操作建议
|
||||
|
||||
- 建议标记已读：3 条 P3 通知
|
||||
- 需要回复/处理：0 条 P0/P1 通知
|
||||
```
|
||||
|
||||
### 经验总结
|
||||
|
||||
1. **`gitlink-cli notification` 命令不存在**：GitLink CLI 没有内置 notification 子命令，所有操作需通过 `gitlink-cli api` 调用 Raw API
|
||||
2. **API 端点是 `messages` 不是 `notifications`**：GitLink 用「消息」术语
|
||||
3. **CLI 路径 Bug**：`gitlink-cli api` 的 PATH 参数以 `/` 开头会被解析为本地文件路径，必须去掉前导 `/`
|
||||
4. **响应字段 `unread_notification` 和 `unread_atme`**：顶层统计字段可直接用于分类计数，无需遍历全部消息
|
||||
5. **没有批量已读 API**：标记已读需逐条调用 `POST users/{owner}/messages/{id}/read`
|
||||
6. **`source` 字段 `PullReuqestAtme`**：官方 API 存在拼写错误（应为 PullRequestAtme），匹配时注意
|
||||
|
||||
---
|
||||
|
||||
## 样例 2：通过 Agent 调用 Skill（自动摘要）
|
||||
|
||||
**日期**：2026-06-03
|
||||
**调用方式**：`Agent(subagent_type="general-purpose", prompt="请调用 gitlink-notification-digest skill，帮我整理通知。")`
|
||||
|
||||
### Agent 自主执行的命令序列
|
||||
|
||||
```
|
||||
工具调用 1: Read → ../gitlink-shared/SKILL.md ← 遵循 Skill 前置条件
|
||||
工具调用 2: Bash → gitlink-cli auth status ← 获取用户名
|
||||
工具调用 3: Bash → gitlink-cli api GET "users/lindiwen23/messages.json"
|
||||
--query "status=1&limit=20" --format json ← 获取未读
|
||||
工具调用 4: Bash → gitlink-cli api GET "users/lindiwen23/messages.json"
|
||||
--query "status=2&limit=20" --format json ← 获取已读（趋势分析）
|
||||
工具调用 5: Bash → gitlink-cli api GET "users/lindiwen23/messages.json"
|
||||
--query "limit=20" --format json ← 获取全部（总计统计）
|
||||
```
|
||||
|
||||
### Agent 决策过程
|
||||
|
||||
Agent **正确遵循了 skill v2.0.0 的工作流**：
|
||||
|
||||
1. 先读取 `gitlink-shared/SKILL.md` 了解认证和全局参数
|
||||
2. 用 `auth status` 获取当前用户 `lindiwen23`
|
||||
3. 使用 Raw API（路径无前导 `/`）获取未读、已读、全部三类数据
|
||||
4. 按 `source` 字段分类：`ProjectPullRequest` → P2，`ProjectPraised`/`ProjectMemberJoined` → P3
|
||||
5. 按输出模板生成结构化报告，含所有七个章节
|
||||
6. 主动询问是否需要标记 P3 通知为已读
|
||||
|
||||
共消耗 **35,601 tokens**，**6 次工具调用**，耗时 **51.7 秒**。
|
||||
|
||||
### Agent 生成的报告
|
||||
|
||||
```markdown
|
||||
# 通知摘要
|
||||
|
||||
> 生成时间：2026-06-03 10:30
|
||||
> 未读通知：7 条 / 总计：28 条（含已读 21 条）
|
||||
> @我未读：0 条
|
||||
|
||||
## 一、概要
|
||||
|
||||
| 类型 | 未读 | 总计 |
|
||||
|------|------|------|
|
||||
| @提及 | 0 | 0 |
|
||||
| Issue 更新 | 0 | 0 |
|
||||
| PR 更新 | 4 | 7 |
|
||||
| 系统通知 | 3 | 21 |
|
||||
|
||||
## 二、需要立即处理（P0）
|
||||
无紧急通知。
|
||||
|
||||
## 三、今天处理（P1）
|
||||
无待处理通知。
|
||||
|
||||
## 四、本周关注（P2）
|
||||
4 条 jiangtx/gitlink-cli 的 PR 需关注
|
||||
|
||||
## 五、可忽略（P3）
|
||||
3 条 CWQ/Aether_Lens_System-v0.0.1 的点赞和成员通知
|
||||
|
||||
## 六、通知趋势
|
||||
| 时间段 | 通知数 |
|
||||
|--------|--------|
|
||||
| 今日 | 2 |
|
||||
| 昨日 | 3 |
|
||||
| 本周 | 7 |
|
||||
|
||||
## 七、近期已读回顾
|
||||
| 类型 | 内容 | 时间 |
|
||||
|------|------|------|
|
||||
| 加入项目 | 加入 jiangtx/gitlink-cli | 06-01 |
|
||||
| 成员加入 | wyxttn 加入 yetja/灵枢 | 05-29 |
|
||||
| PR 合并 | 帮助中心 PR 已通过 | 05-13 |
|
||||
| 角色变更 | 帮助中心角色改为管理员 | 05-13 |
|
||||
|
||||
## 操作建议
|
||||
- 建议标记已读：3 条 P3 通知
|
||||
- 需要关注：4 条 P2 通知
|
||||
```
|
||||
|
||||
### 验证结论
|
||||
|
||||
✅ skill v2.0.0 验证通过：
|
||||
- Agent 正确使用了 `gitlink-cli api` 而非不存在的 `gitlink-cli notification`
|
||||
- Agent 路径没有以 `/` 开头，避开了 CLI 路径解析 Bug
|
||||
- Agent 按 `source` 枚举值正确分类，识别出 `PullReuqestAtme` 拼写异常
|
||||
- Agent 正确区分了 P0/P1/P2/P3 优先级
|
||||
- Agent 使用 `unread_notification`/`unread_atme` 顶层字段快速统计
|
||||
- Agent 生成了趋势章节和已读回顾章节
|
||||
- 报告结构完整，七个章节覆盖全部模板要求
|
||||
|
||||
---
|
||||
|
||||
## 异常场景速查
|
||||
|
||||
| 场景 | 检测方式 | 处理 |
|
||||
|------|----------|------|
|
||||
| `notification +list` 命令不存在 | 运行 `gitlink-cli notification` 报错 | 改用 `gitlink-cli api GET "users/{owner}/messages.json"` |
|
||||
| API 返回 HTML 而非 JSON | 响应以 `<!doctype html>` 开头 | 去掉路径前导 `/` 重试 |
|
||||
| 未读通知 > 返回条数 | `total_count` > `messages.length` | 追加 `--query "page=2"` |
|
||||
| 用户名不确定 | `auth status` 输出 | 从输出中提取 login 字段 |
|
||||
| 无未读通知 | `unread_notification == 0` | 输出 "🎉 所有通知已处理完毕" |
|
||||
|
||||
---
|
||||
|
||||
## 版本兼容性说明
|
||||
|
||||
本 skill v2.0.0 基于 `gitlink-cli 0.1.18` 编写。关键变更：
|
||||
|
||||
| 版本 | `notification` 子命令 | 实际 API | 标记已读 |
|
||||
|------|----------------------|----------|----------|
|
||||
| v1.0.0 | `notification +list`（虚构） | 不存在 | `notification +read-all`（虚构） |
|
||||
| v2.0.0 | 无此子命令 | `GET /api/users/{owner}/messages.json` | `POST /api/users/{owner}/messages/{id}/read` |
|
||||
|
||||
当 CLI 版本更新后，重新验证可用命令：
|
||||
```bash
|
||||
gitlink-cli --help
|
||||
```
|
||||
|
|
@ -1,311 +0,0 @@
|
|||
---
|
||||
name: gitlink-notification-digest
|
||||
version: 2.0.0
|
||||
description: "通知摘要：汇总 GitLink 通知并按类型分类，生成通知摘要报告，支持批量标记已读。当用户需要查看通知摘要、整理通知、清理未读通知时触发。"
|
||||
metadata:
|
||||
requires:
|
||||
bins: ["gitlink-cli"]
|
||||
---
|
||||
|
||||
# gitlink-notification-digest（通知摘要）
|
||||
|
||||
**CRITICAL — 开始前必须先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)，其中包含认证、权限处理和 API 注意事项。**
|
||||
**CRITICAL — 标记已读为写操作，执行前需确认用户意图。**
|
||||
**CRITICAL — GitLink 操作只能用 `gitlink-cli`。禁止用 `gh`（GitHub CLI）操作 GitLink 资源。**
|
||||
|
||||
> **前置条件：** 先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md) 了解认证和全局参数。
|
||||
> **执行样例：** 参见 [`EXAMPLES.md`](EXAMPLES.md)
|
||||
|
||||
---
|
||||
|
||||
## 功能概述
|
||||
|
||||
帮助用户高效管理 GitLink 通知（GitLink 平台称为「消息」）：
|
||||
|
||||
1. **通知列表** — 获取所有未读通知
|
||||
2. **自动分类** — 按 `source` 字段分类（Issue/PR/系统等）
|
||||
3. **优先级判断** — 识别需要立即处理的通知
|
||||
4. **批量操作** — 支持标记已读（需确认）
|
||||
5. **摘要报告** — 生成结构化通知摘要
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 关键注意事项
|
||||
|
||||
### CLI 路径处理 Bug
|
||||
|
||||
**`gitlink-cli api` 的路径参数不要以 `/` 开头**，否则会被错误解析为本地文件路径。
|
||||
|
||||
```bash
|
||||
# ❌ 错误 — 路径以 / 开头会被解析为 D:/Applications/Git/...
|
||||
gitlink-cli api GET /users/me
|
||||
|
||||
# ✅ 正确 — 去掉前导 /
|
||||
gitlink-cli api GET "users/{owner}/messages.json"
|
||||
```
|
||||
|
||||
### 术语对照
|
||||
|
||||
GitLink 平台用「**消息**」（messages）而不是「通知」（notifications）。API 端点和字段均使用 `messages`。
|
||||
|
||||
---
|
||||
|
||||
## 工作流：通知摘要
|
||||
|
||||
### Step 1：获取通知列表
|
||||
|
||||
使用 Raw API 调用 `/api/users/{owner}/messages.json`：
|
||||
|
||||
```bash
|
||||
# 获取未读通知（status=1 表示未读，2 表示已读）
|
||||
gitlink-cli api GET "users/{owner}/messages.json" --query "status=1&limit=20" --format json
|
||||
|
||||
# 获取全部通知（含已读）
|
||||
gitlink-cli api GET "users/{owner}/messages.json" --query "limit=20" --format json
|
||||
|
||||
# 分页获取
|
||||
gitlink-cli api GET "users/{owner}/messages.json" --query "status=1&page=2&limit=20" --format json
|
||||
|
||||
# 按类型过滤
|
||||
# type=notification 系统消息（仓库动态、PR、Issue 等）
|
||||
# type=atme @我消息
|
||||
gitlink-cli api GET "users/{owner}/messages.json" --query "type=atme&status=1&limit=20" --format json
|
||||
```
|
||||
|
||||
**参数说明：**
|
||||
|
||||
| 参数 | 位置 | 说明 |
|
||||
|------|------|------|
|
||||
| `{owner}` | Path | 当前用户名（从 `gitlink-cli auth status` 获取） |
|
||||
| `status` | Query | 1=未读，2=已读，不传=全部 |
|
||||
| `type` | Query | `notification`=系统消息，`atme`=@我消息，不传=全部 |
|
||||
| `page` | Query | 页码（默认 1） |
|
||||
| `limit` | Query | 每页条数（默认 20） |
|
||||
|
||||
**响应结构：**
|
||||
|
||||
```json
|
||||
{
|
||||
"total_count": 28,
|
||||
"type": "",
|
||||
"unread_notification": 7,
|
||||
"unread_atme": 0,
|
||||
"messages": [
|
||||
{
|
||||
"id": 740214,
|
||||
"status": 1,
|
||||
"content": "jiangtx在 <b>jiangtx/gitlink-cli</b> 提交了一个合并请求：<b>label 模块新建</b>",
|
||||
"notification_url": "https://www.gitlink.org.cn/jiangtx/gitlink-cli/pulls/15347",
|
||||
"source": "ProjectPullRequest",
|
||||
"created_at": "2026-06-03 00:27:37",
|
||||
"time_ago": "10小时前",
|
||||
"type": "notification",
|
||||
"sender": {
|
||||
"id": 113,
|
||||
"type": "User",
|
||||
"name": "jiangtx",
|
||||
"login": "jiangtx",
|
||||
"image_url": "..."
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**提取字段：**
|
||||
- `id` — 消息 ID（用于标记已读）
|
||||
- `content` — HTML 格式的通知内容
|
||||
- `source` — 通知来源类型（枚举值，见下方分类表）
|
||||
- `notification_url` — 跳转链接，可从中解析仓库（提取 URL 中的 `/owner/repo/` 段）
|
||||
- `created_at` — 通知时间（格式 `YYYY-MM-DD HH:mm:ss`）
|
||||
- `status` — 1=未读，2=已读
|
||||
- `type` — `notification` 或 `atme`
|
||||
- `sender` — 发送者信息（login, name, image_url）
|
||||
|
||||
### Step 2：分类与优先级
|
||||
|
||||
#### 2.1 按 `source` 字段分类
|
||||
|
||||
| 类型 | `source` 枚举值 | 处理建议 |
|
||||
|------|-----------------|----------|
|
||||
| 🔴 **@提及** | `IssueAtme`, `PullReuqestAtme`（注意官方 API 拼写如此） | 立即查看回复 |
|
||||
| 🟡 **Issue 更新** | `IssueAssigned`, `IssueExpire`, `IssueChanged`, `IssueDeleted`, `IssueJournal`, `ProjectIssue` | 当天处理 |
|
||||
| 🟢 **PR 更新** | `PullRequestAssigned`, `PullRequestChanged`, `PullRequestClosed`, `PullRequestJournal`, `PullRequestMerged`, `ProjectPullRequest` | 跟进代码 |
|
||||
| 🔵 **系统通知** | `ProjectJoined`, `ProjectLeft`, `ProjectMemberJoined`, `ProjectMemberLeft`, `ProjectForked`, `ProjectPraised`, `ProjectRole`, `ProjectFollowed`, `ProjectDeleted`, `ProjectTransfer`, `ProjectSettingChanged`, `ProjectMilestone`, `ProjectMilestoneCompleted`, `ProjectVersion`, `OrganizationJoined`, `OrganizationLeft`, `OrganizationRole`, `ProjectOpenDevOps` | 知悉即可 |
|
||||
| ⚪ **其他** | `LoginIpTip` 及未列出的值 | 按需查看 |
|
||||
|
||||
**完整 `source` 枚举参考：**
|
||||
|
||||
<details>
|
||||
<summary>展开查看全部 source 枚举值</summary>
|
||||
|
||||
| 枚举值 | 含义 |
|
||||
|--------|------|
|
||||
| `IssueAssigned` | 有新指派给我的疑修 |
|
||||
| `IssueExpire` | 我创建或负责的疑修截止日期到达最后一天 |
|
||||
| `IssueAtme` | 在疑修中@我 |
|
||||
| `IssueChanged` | 我创建或负责的疑修状态变更 |
|
||||
| `IssueDeleted` | 我创建或负责的疑修删除 |
|
||||
| `IssueJournal` | 我创建或负责的疑修有新的评论 |
|
||||
| `LoginIpTip` | 登录 IP 提示 |
|
||||
| `OrganizationJoined` | 加入组织 |
|
||||
| `OrganizationLeft` | 离开组织 |
|
||||
| `OrganizationRole` | 组织角色变更 |
|
||||
| `ProjectDeleted` | 项目被删除 |
|
||||
| `ProjectFollowed` | 有人关注了项目 |
|
||||
| `ProjectForked` | 项目被 Fork |
|
||||
| `ProjectIssue` | 项目新 Issue |
|
||||
| `ProjectJoined` | 加入项目 |
|
||||
| `ProjectLeft` | 离开项目 |
|
||||
| `ProjectMemberJoined` | 新成员加入项目 |
|
||||
| `ProjectMemberLeft` | 成员离开项目 |
|
||||
| `ProjectMilestoneCompleted` | 里程碑完成 |
|
||||
| `ProjectMilestone` | 新里程碑 |
|
||||
| `ProjectOpenDevOps` | DevOps 引擎开通 |
|
||||
| `ProjectPraised` | 项目被点赞 |
|
||||
| `ProjectPullRequest` | 项目新 PR |
|
||||
| `ProjectRole` | 项目角色变更 |
|
||||
| `ProjectSettingChanged` | 项目设置变更 |
|
||||
| `ProjectTransfer` | 项目转让 |
|
||||
| `ProjectVersion` | 新版本发布 |
|
||||
| `PullRequestAssigned` | 有指派给我的 PR |
|
||||
| `PullReuqestAtme` | 在 PR 中@我（**官方拼写如此**） |
|
||||
| `PullRequestChanged` | PR 状态变更 |
|
||||
| `PullRequestClosed` | PR 被关闭 |
|
||||
| `PullRequestJournal` | PR 有新评论 |
|
||||
| `PullRequestMerged` | PR 已合并 |
|
||||
|
||||
</details>
|
||||
|
||||
#### 2.2 优先级排序
|
||||
|
||||
| 优先级 | 判定 |
|
||||
|--------|------|
|
||||
| **P0 - 立即** | 含 `Atme` 的消息（IssueAtme, PullReuqestAtme） |
|
||||
| **P1 - 今天** | 自己管理的仓库有 PR 合并/关闭，或被分配的 Issue/PR 有更新 |
|
||||
| **P2 - 本周** | 关注的仓库有新 PR、新 Issue |
|
||||
| **P3 - 可忽略** | 点赞（ProjectPraised）、成员加入/离开、Fork 等系统通知 |
|
||||
|
||||
### Step 3：生成通知摘要
|
||||
|
||||
按下方输出模板生成报告。
|
||||
|
||||
### Step 4：标记已读（可选，需确认）
|
||||
|
||||
```bash
|
||||
# 标记单条已读
|
||||
gitlink-cli api POST "users/{owner}/messages/{id}/read" --format json
|
||||
|
||||
# 批量标记已读 — 逐条调用，GitLink 暂无批量已读 API
|
||||
for id in <id1> <id2> <id3>; do
|
||||
gitlink-cli api POST "users/{owner}/messages/$id/read" --format json
|
||||
done
|
||||
```
|
||||
|
||||
> ⚠️ **执行前必须确认用户意图** — 标记已读为写操作。
|
||||
> ⚠️ **GitLink 没有批量已读 API**，需要逐条标记。
|
||||
|
||||
---
|
||||
|
||||
## 输出模板
|
||||
|
||||
```markdown
|
||||
# 🔔 通知摘要
|
||||
|
||||
> 生成时间：{{当前时间}}
|
||||
> 未读通知：{{unread_count}} 条 / 总计：{{total_count}} 条
|
||||
|
||||
---
|
||||
|
||||
## 一、概要
|
||||
|
||||
| 类型 | 未读 | 总计 |
|
||||
|------|------|------|
|
||||
| @提及 | {{mention_unread}} | {{mention_total}} |
|
||||
| Issue 更新 | {{issue_unread}} | {{issue_total}} |
|
||||
| PR 更新 | {{pr_unread}} | {{pr_total}} |
|
||||
| 系统通知 | {{system_unread}} | {{system_total}} |
|
||||
| 其他 | {{other_unread}} | {{other_total}} |
|
||||
|
||||
---
|
||||
|
||||
## 二、需要立即处理（P0）
|
||||
|
||||
> 如无，输出：*🎉 无紧急通知。*
|
||||
|
||||
| # | 类型 | 仓库 | 内容摘要 | 时间 |
|
||||
|---|------|------|----------|------|
|
||||
| 1 | 🔴@提及 | {{repo}} | {{summary}} | {{time}} |
|
||||
|
||||
---
|
||||
|
||||
## 三、今天处理（P1）
|
||||
|
||||
> 如无，输出：*无待处理通知。*
|
||||
|
||||
| # | 类型 | 仓库 | 内容摘要 | 时间 |
|
||||
|---|------|------|----------|------|
|
||||
|
||||
---
|
||||
|
||||
## 四、本周关注（P2）
|
||||
|
||||
> 如无，输出：*无需要本周关注的通知。*
|
||||
|
||||
---
|
||||
|
||||
## 五、可忽略（P3）
|
||||
|
||||
> 如本段被折叠，输出：*{{p3_count}} 条低优先级通知，已折叠。*
|
||||
|
||||
---
|
||||
|
||||
## 六、通知趋势
|
||||
|
||||
| 时间段 | 通知数 |
|
||||
|--------|--------|
|
||||
| 今日 | {{today_count}} |
|
||||
| 昨日 | {{yesterday_count}} |
|
||||
| 本周 | {{week_count}} |
|
||||
| 上周 | {{last_week_count}} |
|
||||
|
||||
---
|
||||
|
||||
## 七、近期已读回顾
|
||||
|
||||
> 列出最近 3-5 条已读但值得回顾的通知（如角色变更、PR 合并等）。
|
||||
|
||||
---
|
||||
|
||||
## 操作建议
|
||||
|
||||
- 建议标记已读：{{suggest_read_count}} 条 P3 通知
|
||||
- 需要回复/处理：{{need_action_count}} 条 P0/P1 通知
|
||||
|
||||
如需标记 P3 通知为已读，我可以逐条执行：
|
||||
`gitlink-cli api POST "users/{owner}/messages/{id}/read"`
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 异常场景处理
|
||||
|
||||
| 场景 | 处理方式 |
|
||||
|------|----------|
|
||||
| 无未读通知 | 输出"🎉 所有通知已处理完毕" |
|
||||
| 通知数量 > 50 | 分页获取（page 1/2/3），优先分析最近 50 条 |
|
||||
| API 返回 HTML 而非 JSON | 路径可能以 `/` 开头导致解析错误，去掉前导 `/` 重试 |
|
||||
| `unread_notification` > messages 数组长度 | 存在多页数据，追加 `--query "page=2"` 获取 |
|
||||
| 用户名不确定 | 先执行 `gitlink-cli auth status` 获取当前登录用户 |
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
- ✅ **所有命令使用 `--format json`**，确保可解析
|
||||
- ✅ **标记已读为写操作**，执行前必须确认用户意图
|
||||
- ✅ **本 Skill 默认只读分析**，仅在用户明确要求时标记已读
|
||||
- ⚠️ **`gitlink-cli api` 路径不要以 `/` 开头**（CLI Bug）
|
||||
- ⚠️ **GitLink 用「消息（messages）」而非「通知（notifications）」**
|
||||
- ⚠️ **`source` 字段 `PullReuqestAtme` 是官方拼写错误**，实际使用注意匹配
|
||||
- ⚠️ **通知可能分页**，数量 >20 时需追加 `--query "page=2"`
|
||||
Loading…
Reference in New Issue