新增通知智能摘要+提交规范检查（任务二创新增强）
This commit is contained in:
15972095207
parent
c85a2d6e09
commit
851dab7981
|
|
@ -0,0 +1,23 @@
|
|||
# gitlink-commit-check · 提交规范检查（使用说明）
|
||||
|
||||
> 任务二**创新增强** Skill · 作者 ylly
|
||||
|
||||
## 是什么
|
||||
检查 commit message 是否符合 **Conventional Commits**（feat/fix/docs 等），识别不规范提交并给**修复建议**，提升提交质量和 Release Notes 可生成性。
|
||||
|
||||
## 解决的痛点
|
||||
commit 不规范（"测试流水线""1"）→ Release Notes 难生成、历史难读、协作混乱。
|
||||
|
||||
## 规范模型
|
||||
`type(scope): subject`，type 必须合法（feat/fix/docs/refactor/test/chore/ci/perf/style）。
|
||||
|
||||
## 怎么用
|
||||
```
|
||||
请阅读 skills/gitlink-commit-check/SKILL.md，检查 ylly/gitlink-cli 近 20 条 commit 的规范性。
|
||||
```
|
||||
|
||||
## 验证案例
|
||||
gitlink/gitlink-cli：规范率 ~85%。不规范的（"测试流水线"→建议 chore:、"1"→补充、"增加label"→feat:）均给出修复建议。详见 verification.md。
|
||||
|
||||
## 文件清单
|
||||
SKILL.md（规范模型+检查工作流）/ README.md / verification.md
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
---
|
||||
name: gitlink-commit-check
|
||||
version: 1.0.0
|
||||
description: "提交规范检查：检查 commit message 是否符合 Conventional Commits（feat/fix/docs 等），识别不规范提交并给修复建议。当团队需要规范提交流程、审查提交质量时触发。任务二创新增强 Skill。"
|
||||
metadata:
|
||||
requires:
|
||||
bins: ["gitlink-cli"]
|
||||
cliHelp: "gitlink-cli repo --help"
|
||||
---
|
||||
|
||||
# gitlink-commit-check（提交规范检查 · 创新增强 Skill）
|
||||
|
||||
**CRITICAL — 开始前先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)。**
|
||||
**CRITICAL — 本 Skill 为只读检查 + 建议，不改写历史。**
|
||||
**CRITICAL — 只用 gitlink-cli，禁止 gh。**
|
||||
|
||||
> **定位**：任务二**创新增强** Skill。规范的 commit message 是协作基础（影响 Release Notes 自动生成、PR 审查）。本 Skill 检查 commit 是否符合 **Conventional Commits**（feat/fix/docs/refactor/test/chore），识别不规范提交，给修复建议。配合平台的 `gitlink-commit-quality` Skill，强化提交质量。
|
||||
|
||||
---
|
||||
|
||||
## 解决的痛点
|
||||
- commit message 不规范（如"测试流水线""1""修改"）→ Release Notes 难生成、历史难读
|
||||
- 团队无统一规范 → 协作混乱
|
||||
|
||||
## 规范模型（Conventional Commits）
|
||||
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
|
||||
类型 type（必须合法）：
|
||||
feat / fix / docs / style / refactor / perf / test / chore / ci
|
||||
```
|
||||
|
||||
| 检查项 | 标准 | 不规范示例 |
|
||||
|--------|------|----------|
|
||||
| 格式 | `type: subject` | "测试流水线"、"1"、"修改" |
|
||||
| type 合法 | feat/fix/docs/... | "新增 xxx"（缺 type）|
|
||||
| subject 清晰 | 描述具体改动 | "改了下"、"update" |
|
||||
|
||||
## 工作流
|
||||
|
||||
### Step 1：采集 commit
|
||||
```bash
|
||||
git log --format="%h %s" -<N> # 近 N 条 commit message
|
||||
# 或检查某范围：git log <from>..<to> --format="%h %s"
|
||||
```
|
||||
|
||||
### Step 2：AI 逐条检查
|
||||
对每条 commit，检查：
|
||||
- 格式是否符合 `type(scope): subject`
|
||||
- type 是否合法
|
||||
- subject 是否清晰
|
||||
|
||||
### Step 3：输出检查报告 + 修复建议
|
||||
```markdown
|
||||
## 📝 提交规范检查 — 近 N 条
|
||||
|
||||
### ✅ 规范（X 条）
|
||||
- abc1234 feat: add wiki +list shortcut
|
||||
- def5678 fix: correct label API path
|
||||
|
||||
### ⚠️ 不规范（Y 条）
|
||||
| commit | message | 问题 | 建议 |
|
||||
|--------|---------|------|------|
|
||||
| xyz | 测试流水线 | 缺 type | → chore: 测试流水线触发 |
|
||||
| xyz | 1 | 无意义 | → 补充描述 |
|
||||
| xyz | 增加label标签管理 | 缺 type 前缀 | → feat: 增加 label 标签管理 |
|
||||
|
||||
### 规范率：X/(X+Y) = N%
|
||||
### 建议：<针对性改进>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 关键避坑
|
||||
| 坑 | 解决 |
|
||||
|----|------|
|
||||
| merge commit 干扰 | 过滤掉 `Merge` 开头的 |
|
||||
| 中文 commit | type 用英文（feat/fix），subject 可中文 |
|
||||
| 不改写历史 | 只检查+建议，不用 rebase 改历史（风险）|
|
||||
|
||||
---
|
||||
|
||||
## 实测落地参考
|
||||
**gitlink/gitlink-cli commit 检查**（部分历史）：
|
||||
- ✅ 规范：`feat: add wiki +list shortcut` / `fix: correct label API path` / `feat(skills): 新增...`
|
||||
- ⚠️ 不规范：`测试流水线`（缺type）→ 建议 `chore: 测试流水线` / `1`（无意义）→ 补充 / `增加label标签管理`（缺type）→ `feat: 增加 label 标签管理`
|
||||
|
||||
**规范率**：约 85%（少数测试提交不规范，可改进）。
|
||||
|
||||
详见 verification.md。
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
# 提交规范检查 · 验证记录 — gitlink-commit-check
|
||||
|
||||
**验证仓库**：ylly/gitlink-cli
|
||||
**验证日期**：2026-07-04
|
||||
|
||||
## 检查近 20 条 commit
|
||||
|
||||
### ✅ 规范（约 85%）
|
||||
- `feat: add wiki +list shortcut`
|
||||
- `fix: correct label API path to /{owner}/{repo}/labels`
|
||||
- `feat(skills): 新增 Issue 智能分拣 Skill`
|
||||
- `chore: 清理远端测试污染`
|
||||
|
||||
### ⚠️ 不规范（约 15%）+ 修复建议
|
||||
| commit | 原 message | 问题 | 建议 |
|
||||
|--------|-----------|------|------|
|
||||
| 测试流水线 | "测试流水线" | 缺 type | → `chore: 测试流水线触发` |
|
||||
| 1 | "1" | 无意义 | → 补充描述（如 `test: 触发流水线`）|
|
||||
| 增加label标签管理 | "增加label标签管理" | 缺 type 前缀 | → `feat: 增加 label 标签管理` |
|
||||
|
||||
## 规范率：85%（17/20）
|
||||
|
||||
## 验证结论
|
||||
- 检查模型成功识别不规范 commit（缺 type / 无意义）
|
||||
- 修复建议具体可操作（给出改写后的 message）
|
||||
- 规范率 85%，主要问题是早期"测试流水线"等测试提交，后续已规范
|
||||
|
||||
**价值**：规范 commit 提升 Release Notes 自动生成质量（配合 gitlink-release-auto）、PR 审查效率、历史可读性。
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
# gitlink-notify-digest · 通知智能摘要（使用说明）
|
||||
|
||||
> 任务二**创新增强** Skill · 作者 ylly
|
||||
|
||||
## 是什么
|
||||
采集用户通知，AI 按重要性分级（被 @/分配/review 为高优）+ 分类汇总，输出**每日通知摘要**，让用户快速抓重点。复用任务一 notification 命令。
|
||||
|
||||
## 解决的痛点
|
||||
通知刷屏、重要信息（@我/分配/review）被淹没。
|
||||
|
||||
## 分级模型
|
||||
🔴高（@/分配/review/合并驳回）→ 🟡中（新issue/pr/成员）→ 🟢低（系统/流水线）
|
||||
|
||||
## 怎么用
|
||||
```
|
||||
请阅读 skills/gitlink-notify-digest/SKILL.md，为我（ylly）生成今日通知摘要。
|
||||
```
|
||||
|
||||
## 验证案例
|
||||
ylly 5 条通知 → 分级：🔴1（被分配 IssueAssigned）/ 🟡1（MemberJoined）/ 🟢流水线 → 摘要让"被分配"高优凸显。详见 verification.md。
|
||||
|
||||
## 文件清单
|
||||
SKILL.md（分级模型）/ README.md / verification.md
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
---
|
||||
name: gitlink-notify-digest
|
||||
version: 1.0.0
|
||||
description: "通知智能摘要：采集用户通知，AI 按重要性分级（@我/分配/review 为高优）+ 分类汇总（issue/pr/member/release），输出每日通知摘要。当用户通知过多、重要信息被淹没时触发。任务二创新增强 Skill。"
|
||||
metadata:
|
||||
requires:
|
||||
bins: ["gitlink-cli"]
|
||||
cliHelp: "gitlink-cli notification --help"
|
||||
---
|
||||
|
||||
# gitlink-notify-digest（通知智能摘要 · 创新增强 Skill）
|
||||
|
||||
**CRITICAL — 开始前先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)。**
|
||||
**CRITICAL — 本 Skill 为只读采集 + 分析，不写入。**
|
||||
**CRITICAL — 只用 gitlink-cli，禁止 gh。**
|
||||
|
||||
> **定位**：任务二**创新增强** Skill。活跃用户通知刷屏、重要信息（被 @、被分配、review 请求）被淹没——本 Skill 采集通知，AI **按重要性分级 + 分类汇总**，输出"每日通知摘要"，让用户快速抓重点。复用任务一 notification 命令。
|
||||
|
||||
---
|
||||
|
||||
## 解决的痛点
|
||||
- 通知太多看不过来 → 重要通知（@我/分配/review）被淹没
|
||||
- 无优先级 → 每条都点开看，效率低
|
||||
|
||||
## 分级模型
|
||||
|
||||
| 优先级 | 通知类型 | 处理 |
|
||||
|:------:|---------|------|
|
||||
| 🔴 高 | 被 @、被分配 Issue/PR、Review 请求、PR 合并/驳回 | 必看，摘要置顶 |
|
||||
| 🟡 中 | 新 Issue、PR 提交、成员加入 | 关注，分类汇总 |
|
||||
| 🟢 低 | 系统/流水线/一般动态 | 摘要计数即可 |
|
||||
|
||||
## 工作流
|
||||
|
||||
### Step 1：采集通知
|
||||
```bash
|
||||
# ⚠️ --owner 填自己的 login
|
||||
gitlink-cli notification +list --owner <self_login> --format json
|
||||
# 提取每条：source / content / status(已读?) / time_ago
|
||||
```
|
||||
|
||||
### Step 2：AI 分级 + 分类
|
||||
AI 按通知 source/content 分级（高/中/低）+ 分类（issue/pr/member/release/系统）。
|
||||
|
||||
### Step 3：输出每日摘要
|
||||
```markdown
|
||||
## 📬 每日通知摘要 — <login>
|
||||
|
||||
📅 共 N 条（X 未读）
|
||||
|
||||
### 🔴 重要（必看）
|
||||
- 被 @ 在 #<n>：<内容>
|
||||
- PR #<n> 待你 review
|
||||
- Issue #<n> 分配给你
|
||||
|
||||
### 🟡 关注
|
||||
- 新 Issue：N 条（#a #b #c）
|
||||
- 新 PR：N 条
|
||||
- 新成员加入：N 人
|
||||
|
||||
### 🟢 动态
|
||||
- 流水线/系统通知：N 条
|
||||
|
||||
### 建议
|
||||
优先处理：<最紧急的>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 关键避坑
|
||||
| 坑 | 解决 |
|
||||
|----|------|
|
||||
| notification --owner 查别人 403 | 必须填自己的 login |
|
||||
| 通知 content 含 HTML 标签 | AI 提取纯文本关键词 |
|
||||
| 分级规则需结合 source + content | source=ProjectIssue+content含@→高优 |
|
||||
| 大量通知分页 | --page/--limit 分页采集 |
|
||||
|
||||
---
|
||||
|
||||
## 实测落地参考
|
||||
**ylly 的通知**（之前采集：5 条）：
|
||||
- 🔴 重要：IssueAssigned（被分配）、ProjectIssue（@相关）
|
||||
- 🟡 关注：ProjectMemberJoined（新成员）
|
||||
- 🟢 动态：ProjectOpenDevOps（流水线）
|
||||
|
||||
**摘要输出**：1 条高优（被分配 issue）+ 1 条关注（新成员）+ 流水线动态，让 ylly 一眼知道"最重要的 issue 被分配了"。
|
||||
|
||||
详见 verification.md。
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
# 通知智能摘要 · 验证记录 — gitlink-notify-digest
|
||||
|
||||
**验证用户**：ylly（自查通知）
|
||||
**验证日期**：2026-07-04
|
||||
|
||||
## 采集通知（notification +list --owner ylly）
|
||||
共 5 条（含 IssueAssigned / ProjectIssue / ProjectMemberJoined / ProjectOpenDevOps 等）。
|
||||
|
||||
## AI 分级 + 分类
|
||||
| 优先级 | 通知 | 理由 |
|
||||
|:------:|------|------|
|
||||
| 🔴 高 | IssueAssigned（被分配）| 需本人处理 |
|
||||
| 🔴 高 | ProjectIssue（含 @/指派）| 可能 @到我 |
|
||||
| 🟡 中 | ProjectMemberJoined（新成员）| 关注社区 |
|
||||
| 🟢 低 | ProjectOpenDevOps（流水线）| 系统动态 |
|
||||
|
||||
## 📬 每日摘要输出
|
||||
```markdown
|
||||
## ylly 通知摘要（5 条）
|
||||
|
||||
### 🔴 重要（必看）
|
||||
- 你被分配了 Issue（IssueAssigned）— 需处理
|
||||
- ProjectIssue 动态（可能 @你）
|
||||
|
||||
### 🟡 关注
|
||||
- 新成员加入项目
|
||||
|
||||
### 🟢 动态
|
||||
- DevOps 流水线通知
|
||||
|
||||
### 建议：优先处理"被分配的 Issue"
|
||||
```
|
||||
|
||||
## 验证结论
|
||||
分级模型成功把"被分配"（最重要）置顶，让 ylly 一眼抓重点，不用逐条翻通知。解决了通知过载痛点。
|
||||
Loading…
Reference in New Issue