Gitlink
/
gitlink-cli
0
0
Fork 49
Code Issues Pull Requests 11 Packages Projects Releases 10 Wiki Activity

Merge pull request 'feat(contributor-insight): 更新至 v1.1.0，新增执行样例与命令可用性适配' (#10) from dw into master

This commit is contained in:
lindiwen23 2026-06-03 10:30:23 +08:00
parent 431545c633 7c293f9b5a
commit dd82cf4d3f
8 changed files with 1390 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

178
skills/gitlink-ci-health/EXAMPLES.md Normal file
View File

@ -0,0 +1,178 @@
# gitlink-ci-health 使用样例
## 样例 1：CI 未激活的仓库
**日期**：2026-06-03
**仓库**：jiangtx/gitlink-cli（Fork from Gitlink/gitlink-cli）
**CLI 版本**：gitlink-cli 0.1.18
### 执行流程
```bash
# Step 1: 检查 CI 状态（方法 1 — repo +info）
gitlink-cli repo +info --owner jiangtx --repo gitlink-cli --format json
# → "open_devops": false ← CI 未激活
# Step 1 补充（方法 2 — ci +builds）
gitlink-cli ci +builds --owner jiangtx --repo gitlink-cli --format json
# → {"status":-1,"message":"接口数据异常"} ← 确认 CI 未激活
# 此时终止后续步骤，生成"CI 未激活"报告
```
### 关键发现
| 项目 | 值 |
|------|-----|
| `open_devops` | `false` |
| `ci +builds` 返回 | `{"status": -1, "message": "接口数据异常"}` |
| 可用 CI 命令 | `+builds`、`+logs`、`+restart`、`+stop` |
| 不存在的命令 | `ci +authorize`、`ci +activate`、`ci +deactivate` |
### 诊断结论
CI 完全未启用，需通过 GitLink Web 界面开启（仓库设置 → DevOps）。用户拥有 Manager 权限，可以操作。
### 生成的报告
```markdown
# 🔧 CI 健康巡检报告：jiangtx/gitlink-cli
> 巡检时间：2026-06-03
> 仓库：jiangtx/gitlink-cli（Fork from Gitlink/gitlink-cli）
> CI 状态：❌ 未激活
## 一、健康度总览
| 指标 | 数值 | 评分 |
|------|------|------|
| CI 激活状态 | ❌ 未激活（open_devops: false） | 0/4 |
| 整体成功率 | N/A | —/5 |
| 近期稳定性 | N/A | —/5 |
| 构建频率 | N/A | —/3 |
| 修复速度 | N/A | —/3 |
| **总分** | | **0/20** |
## 二、诊断详情
API 调用 ci +builds 返回：
{"status": -1, "message": "接口数据异常"}
仓库元数据显示 open_devops: false，确认该仓库尚未启用 GitLink 平台的 CI/CD（DevOps）服务。
## 三、改进建议
- 🔴 立即激活 CI：前往 GitLink Web 界面 → 仓库设置 → DevOps 开启 CI/CD 服务
- 🟡 配置 CI Pipeline：建议添加 .gitlink-ci.yml 配置编译和测试流水线
## 四、仓库基本信息
| 项目 | 值 |
|------|-----|
| 默认分支 | master |
| 仓库大小 | 13.4 MB |
| 贡献者 | 2 |
| PR 数量 | 9 |
| 权限 | Manager |
```
---
## 异常场景速查
| 场景 | 检测方式 | `ci +builds` 返回值 | 处理 |
|------|----------|---------------------|------|
| CI 未激活 | `repo +info` 的 `open_devops: false` | `{"status":-1,"message":"接口数据异常"}` | 建议 Web 界面激活，终止巡检 |
| CI 已激活但无构建 | `repo +info` 的 `open_devops: true` + builds 为空 | `[]` 或空列表 | 标注"暂无构建记录" |
| 构建样本不足（<5） | builds 列表长度 < 5 | 正常 JSON 数组 | 标注"数据有限，不具代表性" |
---
## 版本兼容性说明
本 skill 基于 `gitlink-cli 0.1.18` 编写。不同版本的 CI 子命令可能有差异：
| CLI 版本 | 可用 CI 命令 |
|----------|-------------|
| 0.1.18 | `+builds`、`+logs`、`+restart`、`+stop` |
| 未来版本 | 可能新增 `+activate`、`+deactivate` 等 |
当 CLI 版本更新后，重新验证可用命令：
```bash
gitlink-cli ci --help
```
---
## 样例 2：通过 Agent 调用 Skill（自动巡检）
**日期**：2026-06-03
**仓库**：jiangtx/gitlink-cli
**调用方式**：`Agent(subagent_type="general-purpose", prompt="调用 gitlink-ci-health skill，检查 jiangtx/gitlink-cli 的 CI 状态。严格按照 skill 的工作流步骤执行。")`
### Agent 自主执行的命令序列
```
工具调用 1: gitlink-cli repo +info --owner jiangtx --repo gitlink-cli --format json
→ open_devops: false ← 发现 CI 未激活
工具调用 2: gitlink-cli ci +builds --owner jiangtx --repo gitlink-cli --format json
→ {"status": -1, "message": "接口数据异常"} ← 二次确认
```
### Agent 决策过程
Agent 读取到 `open_devops: false` 后，**正确遵循了 skill 的异常场景处理规则**：
> "CI 未激活 → 报告 CI 状态为'未激活'，建议通过 Web 界面开启，**不再继续后续步骤**"
Agent 没有继续尝试 `ci +logs` 或统计分析，直接生成了完整报告。共消耗 **5 次工具调用**，**32,113 tokens**，耗时 **35.8 秒**。
### Agent 生成的报告
```markdown
# CI 健康巡检报告：gitlink-cli
> 巡检时间：2026-06-03
> 仓库：jiangtx/gitlink-cli
> CI 状态：未激活
## 一、健康度总览
| 指标 | 数值 | 评分 |
|------|------|------|
| CI 激活状态 | 未激活 | 0/4 |
| 整体成功率 | N/A | -/5 |
| 近期稳定性 | N/A | -/5 |
| 构建频率 | N/A | -/3 |
| 修复速度 | N/A | -/3 |
| **总分** | | **0/20** |
## 二、构建趋势
无构建记录。仓库 CI 未启用。
## 三、故障分析
CI 未激活，无构建数据可供分析。
## 四、改进建议
- **立即激活 CI**：前往 GitLink Web 界面 → 仓库设置 → DevOps，开启 CI/CD 服务。
（CLI 暂不支持 ci +activate 命令，需要通过 Web 界面操作。）
---
总结：仓库 jiangtx/gitlink-cli（项目 ID: 1547588，默认分支: master，权限: Manager）
当前 open_devops 字段为 false，CI/CD 服务未开启。其他仓库信息：2 位贡献者、
9 个 PR、0 个 Issue，Fork 自 Gitlink/gitlink-cli。
```
### 验证结论
✅ skill v1.1.0 修复验证通过：
- Agent 正确使用了 `repo +info` 的 `open_devops` 字段判断 CI 状态
- Agent 在 CI 未激活时正确终止，没有执行后续无效步骤
- Agent 没有尝试调用不存在的 `ci +authorize` 或 `ci +activate`
- Agent 正确建议通过 Web 界面激活
- 报告结构完整，包含了仓库基本信息

189
skills/gitlink-ci-health/SKILL.md Normal file
View File

@ -0,0 +1,189 @@
---
name: gitlink-ci-health
version: 1.1.0
description: "CI 健康巡检：检查仓库 CI/CD 授权状态、构建历史和成功率，生成 CI 健康度报告。当用户需要检查 CI 状态、分析构建成功率、排查 CI 故障时触发。"
metadata:
requires:
bins: ["gitlink-cli"]
cliHelp: "gitlink-cli ci --help"
---
# gitlink-ci-health（CI 健康巡检）
**CRITICAL — 开始前必须先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)，其中包含认证、权限处理和 API 注意事项。**
**CRITICAL — 本 Skill 为只读操作。CI 激活/关闭需通过 GitLink Web 界面操作，CLI 不提供对应命令。**
**CRITICAL — GitLink 操作只能用 `gitlink-cli`。禁止用 `gh`（GitHub CLI）操作 GitLink 资源。**
> **前置条件：** 先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md) 了解认证和全局参数。
---
## 功能概述
面向维护者的 CI/CD 健康度巡检工具：
1. **授权检查** — 确认仓库 CI 是否已激活
2. **构建历史** — 获取近期构建列表
3. **成功率统计** — 计算构建成功率和平均耗时
4. **故障分析** — 识别频繁失败的构建及其原因
5. **健康报告** — 生成 CI 健康度评分和改进建议
---
## 工作流：CI 健康巡检
### Step 1：检查 CI 授权状态
**方法 1（推荐）**：通过 `repo +info` 查看 `open_devops` 字段：
```bash
gitlink-cli repo +info --owner <owner> --repo <repo> --format json
```
- `"open_devops": true` → CI 已激活
- `"open_devops": false` → CI 未激活
**方法 2**：直接调用 `ci +builds`，CI 未激活时返回：
```json
{"status": -1, "message": "接口数据异常"}
```
> ⚠️ `ci +authorize` 命令在当前 CLI 版本（v0.1.18）中**不存在**。可用 CI 命令仅：`+builds`、`+logs`、`+restart`、`+stop`。
若 CI 未激活，报告中说明"CI 未启用"，建议通过 GitLink Web 界面（仓库设置 → DevOps）开启，随后不再继续后续步骤。
### Step 2：获取构建历史
```bash
gitlink-cli ci +builds --owner <owner> --repo <repo> --format json
```
提取每次构建的：
- `status` — 构建状态（success/failed/running/pending）
- `created_at` / `finished_at` — 时间信息
- `duration` — 耗时（如有）
- `branch` — 触发分支
如构建数量 >30，取最近 30 次分析。
### Step 3：构建日志（失败构建）
对状态为 failed 的构建获取日志：
```bash
gitlink-cli ci +logs --owner <owner> --repo <repo> --build <build_id> --format json
```
> ⚠️ **控制调用量**：仅对最近 5 次失败构建获取日志，避免过多 API 调用。日志可能过大，提取关键错误行（最后 20 行）。
### Step 4：统计分析
#### 4.1 成功率计算
| 指标 | 计算方式 |
|------|----------|
| 整体成功率 | 成功构建数 / 总构建数 × 100% |
| 近 10 次成功率 | 最近 10 次中成功占比 |
| 平均修复时间 | 从失败到下次成功的平均间隔 |
#### 4.2 健康度评分（满分 20）
| 维度 | 权重 | 评分标准 |
|------|------|----------|
| CI 激活 | 4 | 已激活=4，未激活=0 |
| 构建成功率 | 5 | ≥90%=5，≥80%=4，≥70%=3，≥50%=2，<50%=1 |
| 近期稳定性 | 5 | 近10次全部成功=5，8-9次=4，6-7次=3，4-5次=2，<4次=1 |
| 构建频率 | 3 | 每天有构建=3，2-3天=2，每周=1，更少=0 |
| 修复速度 | 3 | 失败后1次内修复=3，2-3次=2，>3次=1 |
### Step 5：生成 CI 健康报告
---
## 输出模板
```markdown
# 🔧 CI 健康巡检报告：{{仓库名}}
> 巡检时间：{{当前时间}}
> 仓库：{{full_name}}
> CI 状态：{{ci_status_display}}
---
## 一、健康度总览
| 指标 | 数值 | 评分 |
|------|------|------|
| CI 激活状态 | {{activated_status}} | {{activate_score}}/4 |
| 整体成功率 | {{success_rate}}%（{{success_count}}/{{total_count}}） | {{success_score}}/5 |
| 近期稳定性 | 近 10 次 {{recent_success}} 次成功 | {{stability_score}}/5 |
| 构建频率 | {{build_frequency_desc}} | {{frequency_score}}/3 |
| 修复速度 | {{repair_speed_desc}} | {{repair_score}}/3 |
| **总分** | | **{{total_score}}/20** |
## 二、构建趋势
```
最近 20 次构建：
✅✅❌✅✅✅❌✅✅✅✅✅❌✅✅✅✅✅✅
（✅=成功 ❌=失败）
```
| 时间段 | 总构建 | 成功 | 失败 | 成功率 |
|--------|--------|------|------|--------|
| 最近 7 天 | {{w1_total}} | {{w1_success}} | {{w1_fail}} | {{w1_rate}}% |
| 7-14 天 | {{w2_total}} | {{w2_success}} | {{w2_fail}} | {{w2_rate}}% |
| 14-30 天 | {{w3_total}} | {{w3_success}} | {{w3_fail}} | {{w3_rate}}% |
## 三、故障分析
> 如无失败构建，输出：**🎉 分析期内无失败构建，CI 运行健康。**
| 构建 ID | 分支 | 失败时间 | 错误摘要 |
|---------|------|----------|----------|
| {{id}} | {{branch}} | {{time}} | {{error_summary}} |
### 故障模式分类
| 故障类型 | 次数 | 占比 |
|----------|------|------|
| 编译错误 | {{compile_count}} | {{compile_pct}}% |
| 测试失败 | {{test_fail_count}} | {{test_fail_pct}}% |
| 超时 | {{timeout_count}} | {{timeout_pct}}% |
| 环境问题 | {{env_count}} | {{env_pct}}% |
| 其他 | {{other_count}} | {{other_pct}}% |
## 四、改进建议
<!-- 根据分析结果，从以下列表中选择匹配的建议输出 -->
- **立即激活 CI**（当 CI 未激活时）：前往 GitLink Web 界面 → 仓库设置 → DevOps 开启 CI/CD 服务（CLI 暂不支持 `ci +activate`）
- **提升成功率**（当 success_rate < 80% 时）：优先修复高频失败原因
- **增加构建频率**（当构建频率评分 < 2 时）：建议每次 push 触发 CI
- **缩短修复时间**（当修复速度评分 < 2 时）：建立 CI 失败告警
```
---
## 异常场景处理
| 场景 | 处理方式 |
|------|----------|
| CI 未激活 | 报告 CI 状态为"未激活"，建议通过 Web 界面开启，不再继续后续步骤 |
| 无构建记录 | 标注"仓库暂无 CI 构建记录" |
| `ci +logs` 返回空 | 标注"日志不可用" |
| 构建总数 < 5 | 样本量不足，标注"数据有限，统计不具代表性" |
---
## 注意事项
- ✅ **所有命令使用 `--format json`**，确保可解析
- ✅ **CI 激活/关闭需通过 GitLink Web 界面**，CLI 不提供 `+activate`/`+deactivate` 命令
- ✅ **Owner/repo 优先从 `git remote` 自动解析**
- ⚠️ **`ci +logs` 输出可能很大**，仅提取关键错误行
- ⚠️ **构建历史无分页参数**，实际返回条数取决于 API
- ⚠️ **CI 数据仅反映 GitLink 平台活动**，不包括第三方 CI 服务
- ⚠️ **`repo +info` 的 `open_devops` 字段**是判断 CI 是否激活的最可靠方式

239
skills/gitlink-contributor-insight/EXAMPLES.md Normal file
View File

@ -0,0 +1,239 @@
# gitlink-contributor-insight 使用样例
## 样例 1：直接调用 Skill（手动执行）
**日期**：2026-06-03
**仓库**：jiangtx/gitlink-cli（Fork from Gitlink/gitlink-cli）
**CLI 版本**：gitlink-cli 0.1.18
### 执行流程
```bash
# Step 1: 获取仓库信息
gitlink-cli repo +info --owner jiangtx --repo gitlink-cli --format json
# → contributor_users_count: 2, pull_requests_count: 9, issues_count: 0
# → fork_info: { fork_project_user_login: "Gitlink" }
# Step 2: 获取 PR 列表（替代不存在的 repo +contributors）
gitlink-cli pr +list --owner jiangtx --repo gitlink-cli --format json
# → 9 个 PR，全部已合并
# → 唯一 author_login: lindiwen23 (5 PRs), jiangtx (4 PRs)
# Step 3: 获取用户信息
gitlink-cli user +info --login jiangtx --format json
# → 注册于 2026-04-28，3 个项目，身份"专业人士"
gitlink-cli user +info --login lindiwen23 --format json
# → 注册于 2025-05-26，6 个项目，1 个组织，身份"专业人士"
# Step 4: 获取 Issue 列表（补充数据）
gitlink-cli issue +list --owner jiangtx --repo gitlink-cli --format json
# → 0 个 Issue
```
### 不可用命令确认
| 命令 | 结果 |
|------|------|
| `gitlink-cli repo +contributors` | 命令不存在，返回 repo 帮助文本 |
| `gitlink-cli user +heatmap` | 命令不存在（user 子命令仅 `+info` / `+me`） |
| `gitlink-cli user +stats` | 命令不存在 |
| `gitlink-cli user +trends` | 命令不存在 |
| `gitlink-cli api GET "/api/v1/repos/.../contributors"` | 返回 HTML 页面，非 JSON |
| `gitlink-cli api GET "/api/v1/users/.../heatmap"` | 返回 HTML 页面，非 JSON |
### 关键发现
**贡献者数据（从 PR 列表提取）：**
| 贡献者 | PR 数 | 活跃日期 | 活跃天数 | 趋势 |
|--------|-------|----------|----------|------|
| lindiwen23 | 5 | 06-01, 06-03 | 2 天 | ↑ |
| jiangtx | 4 | 06-02, 06-03 | 2 天 | ↑ |
**PR 时间分布：**
- 06-01: 1 PR（lindiwen23 #1）
- 06-02: 2 PRs（jiangtx #2, #3）
- 06-03: 6 PRs（jiangtx #4, #5 + lindiwen23 #6, #7, #8, #9）
**分级处理：** 项目仅 3 天历史，适用"年轻项目放宽标准"规则，2 人均标记为 🔥 核心贡献者。
### 生成的报告
```markdown
# 👥 贡献者洞察报告：gitlink-cli
> 分析时间：2026-06-03 10:00 (UTC+8)
> 仓库：jiangtx/gitlink-cli（Fork from Gitlink/gitlink-cli）
> 总贡献者：2 人，本次分析：2 人（全量分析）
## 一、团队概览
| 指标 | 数值 |
|------|------|
| 总贡献者 | 2 |
| 🔥 核心贡献者 | 2 |
| 🌟 活跃贡献者 | 2 |
| 🌱 新兴贡献者 | 0 |
| 💤 休眠贡献者 | 0 |
| 近 30 天活跃率 | 100% |
| 仓库总 PR 数 | 9（全部已合并） |
| 仓库总 Issue 数 | 0 |
| 项目启动时间 | 2026-06-01（3 天前） |
## 二、贡献者活跃度排行榜
| 排名 | 贡献者 | 级别 | 类型 | 活跃天数 | 总PR | 总Issue | 趋势 |
|------|--------|------|------|---------|------|---------|------|
| 1 | lindiwen23 | 🔥 | 代码 | 2 天 | 5 | 0 | ↑ |
| 2 | jiangtx | 🔥 | 代码 | 2 天 | 4 | 0 | ↑ |
## 三、重点贡献者分析
### 🔥 lindiwen23（核心贡献者）
- 5 个 PR（3 feat + 1 fix + 1 refactor），集中上午时段
- 6/3 当天 43 分钟内连续提交 4 个 PR，集中爆发型节奏
- 平台老用户（2025-05-26 注册），6 个项目经验
### 🔥 jiangtx（核心贡献者 / Owner）
- 4 个 PR（3 feat + 1 fix），下午至深夜时段
- 从基础设施修复 → 模块补全，有序推进型节奏
- 平台新用户（2026-04-28 注册），项目 Owner
## 四、团队健康度评估
| 指标 | 状态 | 说明 |
|------|------|------|
| 核心贡献者占比 | 100% | 2/2 活跃 |
| 近 30 天活跃率 | 100% | 全部近期有贡献 |
| 知识分散度 | ⚠️ Bus Factor = 2 | 人数偏少 |
| 贡献稳定性 | ⚠️ 仅 3 天数据 | 无法评估长期 |
### 风险提示
- ⚠️ 核心贡献者不足（2 人），Bus Factor = 2
- ℹ️ 项目处于早期阶段（3 天），风险置信度有限
- ⚠️ 缺少新鲜血液，0 个外部 Issue
## 五、社区建设建议
1. 保持当前协作节奏（独立分支 + PR 合并）
2. 建立 Issue 文化，添加 Good First Issue 标签
3. 在 GitLink 平台推广，完善使用文档
4. 完善代码注释，降低 Bus Factor 风险
5. 定期同步上游（Gitlink/gitlink-cli）
## 📋 数据来源与局限性
| 数据维度 | 来源 | 可靠性 |
|----------|------|--------|
| 贡献者数量 | repo +info | ✅ 可靠 |
| PR 贡献数据 | pr +list 全量 | ✅ 可靠 |
| 用户信息 | user +info | ✅ 可靠 |
| 贡献热力图 | 不可用（命令未实现） | ❌ 缺失 |
| 统计信息 | 不可用（命令未实现） | ❌ 缺失 |
| 趋势数据 | PR 时间序列推算 | ⚠️ 推算 |
```
---
## 样例 2：通过 Agent 调用 Skill（自动执行）
**日期**：2026-06-03
**仓库**：jiangtx/gitlink-cli
**调用方式**：`Agent(subagent_type="general-purpose", prompt="调用 gitlink-contributor-insight skill，分析一下 jiangtx/gitlink-cli 的贡献者活跃度。")`
### Agent 自主执行的命令序列
```
工具调用 1: gitlink-cli repo +info --owner jiangtx --repo gitlink-cli --format json
→ contributor_users_count: 2, pull_requests_count: 9
工具调用 2: gitlink-cli pr +list --owner jiangtx --repo gitlink-cli --format json
→ 9 PRs, 提取 author_login: lindiwen23(5), jiangtx(4)
工具调用 3: gitlink-cli issue +list --owner jiangtx --repo gitlink-cli --format json
→ 0 issues
工具调用 4: gitlink-cli user +info --login jiangtx --format json
→ 注册 2026-04-28, 3 个项目
工具调用 5: gitlink-cli user +info --login lindiwen23 --format json
→ 注册 2025-05-26, 6 个项目, 1 个组织
```
### Agent 决策过程
Agent 读取 skill 后，**正确遵循了更新后的工作流**：
1. **未尝试 `repo +contributors`**：skill 的"命令可用性声明"表标注该命令不可用
2. **未尝试 `user +heatmap/+stats/+trends`**：skill 标注不可用，直接从 PR 列表推算
3. **未尝试 Raw API**：skill 不推荐此路径，全程使用 Shortcut 命令
4. **正确应用"年轻项目"规则**：识别项目仅 3 天，放宽分级标准，2 人均标记为 🔥 核心
5. **自主增强分析**：Agent 额外分析了工作时段偏好、PR 类型统计、新老比例
共消耗 **5 次 CLI 调用**，**41,312 tokens**，耗时 **77.5 秒**。
### Agent 相对于手动执行的改进
| 维度 | 手动执行 | Agent 执行 |
|------|----------|-----------|
| 工作节奏分析 | 仅按日期统计 | 识别出时段偏好（上午 vs 深夜） |
| PR 类型统计 | 未分类 | feat(6) + fix(3) + refactor(1) |
| 新老比例 | 未计算 | 1:1（jiangtx 1 月 vs lindiwen23 1 年+） |
| 贡献者建议 | 通用建议 | 建议为 lindiwen23 授予更高级别权限 |
| 协作模式 | 分支策略分析 | 新增独立分支 + PR 合并模式分析 |
### Agent 生成的报告摘要
Agent 生成了完整的五段式报告（团队概览 → 排行榜 → 个人分析 → 健康度评估 → 建议），结构与我手动执行一致，但细节更丰富：
- **lindiwen23 分析**：增加了"3 feat + 1 fix + 1 refactor"分类、"上午 9:00-11:30 时段偏好"、"集中爆发型节奏"
- **jiangtx 分析**：增加了"先修复基础设施，再逐步补全功能模块"的有序推进评价
- **健康度评估**：增加了新老比例 1:1 分析，指出两人经验互补
- **建议**：更具体，如"为 lindiwen23 授予更高级别权限"、"编写 CONTRIBUTING.md"
### 验证结论
✅ skill v1.1.0 验证通过：
- Agent 正确遵循了"命令可用性声明"，未尝试不可用命令
- Agent 正确从 `pr +list` 提取贡献者数据（替代不存在的 `repo +contributors`）
- Agent 正确从 PR 时间戳推算活跃天数（替代不存在的 `user +heatmap`）
- Agent 正确从 PR 聚合获得产出量（替代不存在的 `user +stats`）
- Agent 正确从 PR 时间分布判断趋势（替代不存在的 `user +trends`）
- Agent 正确应用"年轻项目放宽标准"规则
- Agent 正确标注数据来源局限性
- Agent 未使用 `gh` 或其他平台工具
- 报告结构完整，覆盖所有必需章节
---
## 异常场景速查
| 场景 | 检测方式 | 数据表现 | 处理 |
|------|----------|----------|------|
| `repo +contributors` 不可用 | 命令返回帮助文本 | 无 `+contributors` 子命令 | 从 `pr +list` 提取 `author_login` |
| `user +heatmap` 不可用 | 命令不存在 | user 仅 `+info`/`+me` | 从 PR 时间戳推算活跃天数 |
| `user +stats` 不可用 | 命令不存在 | 同上 | 从 `pr +list` 聚合 PR/Issue 数 |
| `user +trends` 不可用 | 命令不存在 | 同上 | 从 PR 按日聚合判断趋势 |
| Raw API 返回 HTML | `api GET` 返回 HTML | 非 JSON 响应 | 仅使用 Shortcut 命令 |
| 项目 < 30 天 | PR 时间跨度 < 30 天 | 全部 PR 在近期 | 放宽分级标准，标注"早期阶段" |
| 贡献者 ≤ 2 人 | `contributor_users_count` ≤ 2 | Bus Factor 极低 | 报告标注风险 + 提供吸引新人建议 |
| PR 数为 0 | `pr +list` 空数组 | `issues: []` | 标注"仓库暂无 PR 数据" |
| Issue 数为 0 | `issue +list` 空数组 | `issues_count: 0` | 贡献类型统一标注"代码贡献者" |
---
## 版本兼容性说明
本 skill 基于 `gitlink-cli 0.1.18` 编写。不同版本的可用命令可能有差异：
| CLI 版本 | 贡献者分析可用命令 | 缺失命令 |
|----------|-------------------|----------|
| 0.1.18 | `repo +info`, `pr +list`, `issue +list`, `user +info` | `repo +contributors`, `user +heatmap`, `user +stats`, `user +trends` |
| 未来版本 | 可能新增 `user +heatmap` 等 | — |
当 CLI 版本更新后，重新验证可用命令：
```bash
gitlink-cli repo --help
gitlink-cli user --help
```

257
skills/gitlink-contributor-insight/SKILL.md Normal file
View File

@ -0,0 +1,257 @@
---
name: gitlink-contributor-insight
version: 1.1.0
description: "贡献者活跃度分析：分析仓库贡献者的活跃度、贡献趋势和工作节奏，生成贡献者洞察报告。当用户需要分析贡献者活跃度、查看团队贡献趋势、评估成员参与度时触发。"
metadata:
requires:
bins: ["gitlink-cli"]
cliHelp: "gitlink-cli user --help"
---
# gitlink-contributor-insight（贡献者活跃度分析）
**CRITICAL — 开始前必须先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)，其中包含认证、权限处理和 API 注意事项。**
**CRITICAL — 本 Skill 为只读操作，不会修改任何仓库。无需用户额外确认即可执行。**
**CRITICAL — GitLink 操作只能用 `gitlink-cli`。禁止用 `gh`（GitHub CLI）操作 GitLink 资源。**
> **前置条件：** 先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md) 了解认证和全局参数。
---
## ⚠️ 命令可用性声明
gitlink-cli 的命令集在持续演进中。以下命令**当前版本可能不可用**，执行前先验证：
| 命令 | 状态 | 替代方案 |
|------|------|----------|
| `repo +contributors` | ❌ 不可用 | 从 `pr +list` 提取 `author_login` + `repo +info` 获取 `contributor_users_count` |
| `user +heatmap` | ❌ 不可用 | 从 PR 时间戳手动推算活跃天数 |
| `user +stats` | ❌ 不可用 | 从 `pr +list` 统计 PR 数；Issue 数通过 `issue +list` 获取 |
| `user +trends` | ❌ 不可用 | 从 PR 时间分布手动判断趋势（上升/平稳/下降） |
| `repo +info` | ✅ 可用 | — |
| `pr +list` | ✅ 可用 | — |
| `user +info` | ✅ 可用 | — |
| `issue +list` | ✅ 可用 | — |
> **核心原则**：优先使用可用的 Shortcut 命令。当所需命令不可用时，从 `pr +list` 和 `user +info` 中提取等效数据，并在报告中标注"数据来源：PR 列表（命令 X 不可用）"。
---
## 功能概述
面向开源社区管理者和维护者的贡献者分析工具：
1. **项目概览** — 获取仓库贡献者规模和基本信息
2. **贡献数据分析** — 通过 `pr +list` 提取每位贡献者的 PR 数量和时间分布
3. **用户画像** — 通过 `user +info` 了解贡献者背景
4. **趋势判断** — 从 PR 时间序列推断贡献趋势
5. **洞察报告** — 生成贡献者活跃度排名和团队健康度评估
---
## 工作流：贡献者分析全流程
### Step 1：获取仓库基本信息
```bash
gitlink-cli repo +info --owner <owner> --repo <repo> --format json
```
提取：`contributor_users_count`、`full_name`、`description`、`default_branch`、`fork_info`（如为 Fork 项目）。
### Step 2：获取贡献者列表（通过 PR 数据）
由于 `repo +contributors` 不可用，改用两步获取贡献者：
```bash
# 2a. 获取所有 PR（含已合并和已关闭）
gitlink-cli pr +list --owner <owner> --repo <repo> --format json
# 2b. 如果 Issue 数据也需要
gitlink-cli issue +list --owner <owner> --repo <repo> --format json
```
从 `pr +list` 返回数据中：
- 提取所有唯一的 `author_login` 作为实际代码贡献者
- 统计每位作者的 PR 数（`pull_request_status`: 0=open, 1=merged, 2=closed）
- 记录每个 PR 的 `pr_full_time` 用于时间分析
- 记录每个 PR 的 `journals_count`（评论/审核活动数）
从 `issue +list` 返回数据中：
- 提取所有唯一的 `author_login` 作为 Issue 参与者
- 统计每位作者的 Issue 数
> 如果 PR 数量较多（>50），按 `author_login` 聚合后取 PR 数前 10 的贡献者分析，报告中注明"基于 Top 10 分析"。
### Step 3：逐位贡献者深度分析
对每位贡献者执行：
```bash
# 用户基本信息
gitlink-cli user +info --login <username> --format json
```
从 `user +info` 提取：`login`、`name`、`created_time`（注册时间）、`user_projects_count`、`user_org_count`、`user_identity`。
**如果 `user +heatmap/+stats/+trends` 可用**（未来版本），补充执行。当前版本用以下替代方案：
| 维度 | 替代数据源 | 分析要点 |
|------|----------|----------|
| 贡献频率 | PR 时间戳列表 | 统计活跃天数、相邻 PR 间隔、判断"持续贡献者"还是"间歇参与者" |
| 贡献产出 | `pr +list` 聚合 | PR 数、Issue 数，区分"代码贡献者"和"问题反馈者" |
| 活跃趋势 | PR 按日/周聚合 | 贡献量上升/稳定/下降，识别"上升期贡献者"和"逐渐淡出者" |
> ⚠️ **控制 API 调用**：贡献者 >15 人时，仅分析 PR 数最高的前 10 位。每人 1 次 `user +info` 调用（共 ≤10 次），PR 数据已在 Step 2 全量获取。
### Step 4：贡献者分级与分类
#### 4.1 活跃度分级
| 级别 | 判定标准 |
|------|----------|
| 🔥 **核心贡献者** | 最近 30 天有贡献 + 总贡献 PR ≥ 5（或总贡献 PR > 10） |
| 🌟 **活跃贡献者** | 最近 60 天有贡献 + 总贡献 ≥ 3 |
| 🌱 **新兴贡献者** | 最近 90 天首次出现 + 贡献频率上升 |
| 💤 **休眠贡献者** | 最近 90 天无贡献 + 历史有贡献 |
> **年轻项目特殊处理**：项目历史 < 30 天时，放宽标准——所有活跃贡献者均可标记为核心贡献者，报告中注明"项目处于早期阶段，分级标准已放宽"。
#### 4.2 贡献类型分类
| 类型 | 判定 |
|------|------|
| **代码贡献者** | PR 数量 > Issue 数量 |
| **问题反馈者** | Issue 数量 > PR 数量 |
| **全能贡献者** | PR 和 Issue 数量均衡（差异 ≤ 1） |
### Step 5：生成贡献者洞察报告
按下方输出模板生成报告，并根据数据可用性灵活调整章节。
---
## 输出模板
```markdown
# 👥 贡献者洞察报告：{{仓库名}}
> 分析时间：{{当前时间}}
> 仓库：{{full_name}}
> 总贡献者：{{contributor_users_count}} 人，本次分析：{{analyzed_count}} 人
---
## 一、团队概览
| 指标 | 数值 |
|------|------|
| 总贡献者 | {{contributor_users_count}} |
| 核心贡献者 | {{core_count}} |
| 活跃贡献者 | {{active_count}} |
| 新兴贡献者 | {{new_count}} |
| 休眠贡献者 | {{dormant_count}} |
| 近 30 天活跃率 | {{active_30d_rate}}% |
---
## 二、贡献者活跃度排行榜
| 排名 | 贡献者 | 级别 | 类型 | 活跃天数 | 总PR | 总Issue | 趋势 |
|------|--------|------|------|---------|------|---------|------|
| 1 | {{login}} | 🔥 | 代码 | {{d}} 天 | {{pr_count}} | {{issue_count}} | ↑ |
| ... | ... | ... | ... | ... | ... | ... | ... |
---
## 三、重点贡献者分析
> 仅展示核心/活跃贡献者。
### 🔥 {{login}}（核心贡献者）
| 维度 | 数据 | 说明 |
|------|------|------|
| 活跃天数 | {{d}} 天 | {{评价}} |
| 总 PR 数 | {{pr_count}} | |
| 总 Issue 数 | {{issue_count}} | |
| 贡献趋势 | {{trend_direction}} | {{trend_comment}} |
**PR 贡献明细**：（可选，数据充足时展示）
| PR# | 标题 | 日期 | 类型 |
|-----|------|------|------|
| ... | ... | ... | feat/fix/refactor |
---
## 四、团队健康度评估
### 健康度指标
| 指标 | 状态 | 说明 |
|------|------|------|
| 核心贡献者占比 | {{core_ratio}}% | {{core_comment}} |
| 新老比例 | {{new_old_ratio}} | {{new_old_comment}} |
| 贡献频率稳定性 | {{stability}} | {{stability_comment}} |
| 知识分散度 | {{bus_factor}} | {{bus_factor_comment}} |
### 风险提示
- ⚠️ **核心贡献者不足**（当 core_count < 3 时）：仅 {{core_count}} 位核心贡献者，存在单点依赖风险（Bus Factor = {{core_count}}）。
- ⚠️ **贡献者流失**（当 dormant_rate > 50% 时）：超过一半的贡献者已不活跃，需要关注社区留存。
- ⚠️ **缺少新鲜血液**（当 new_count == 0 时）：近期无新兴贡献者，建议通过 Good First Issue 等方式吸引新人。
- ℹ️ **项目处于早期阶段**（当项目历史 < 30 天时）：贡献者分级标准已放宽，以上风险置信度有限。
- ✅ **团队健康**（当以上情况均不满足时）：贡献者结构合理，团队运转良好。
---
## 五、社区建设建议
1. **激励核心贡献者**：{{核心贡献者维护建议}}
2. **激活休眠贡献者**：{{休眠贡献者召回建议}}
3. **吸引新贡献者**：{{新贡献者吸引建议}}
4. **平衡贡献类型**：{{贡献类型平衡建议}}
---
## 📋 数据来源与局限性
| 数据维度 | 来源 | 可靠性 |
|----------|------|--------|
| 贡献者数量 | `repo +info` | ✅ 可靠 |
| PR 贡献数据 | `pr +list` 全量 | ✅ 可靠 |
| Issue 数据 | `issue +list` | ✅ 可靠 |
| 用户信息 | `user +info` | ✅ 可靠 |
| 贡献热力图 | 不可用（命令未实现） | ❌ 缺失 |
| 统计信息 | 不可用（命令未实现） | ❌ 缺失 |
| 趋势数据 | 不可用（命令未实现） | ❌ 缺失 |
> **局限性**：本报告仅反映 GitLink 平台活动，不包括其他平台（GitHub、GitLab 等）的数据。
```
---
## 异常场景处理
| 场景 | 处理方式 |
|------|----------|
| `repo +contributors` 不可用（当前版本常态） | 从 `pr +list` 的 `author_login` 提取贡献者列表 |
| `user +heatmap` / `+stats` / `+trends` 不可用 | 从 PR 时间戳推算活跃天数，PR 聚合得产出量，时间分布得趋势 |
| `pr +list` 返回空 | 标注"仓库暂无 PR 数据"，仅展示 `repo +info` 基本信息 |
| `user +info` 返回空 | 标注"用户信息不可用"，仅展示 PR 统计 |
| 贡献者 > 15 人 | 仅分析 PR 数最高的前 10 位，报告中注明"基于 Top 10 分析" |
| 项目历史 < 30 天 | 放宽分级标准，报告中注明"项目处于早期阶段" |
| `issue +list` 返回空 | Issue 数列为 0，贡献类型统一标注"代码贡献者" |
---
## 注意事项
- ✅ **所有命令使用 `--format json`**，确保可解析
- ✅ **本 Skill 为纯只读分析**，不会修改任何仓库
- ✅ **Owner/repo 优先从 `git remote` 自动解析**，无 git 上下文时询问用户
- ⚠️ **核心数据来源为 `pr +list`**：当前版本 gitlink-cli 中 `user +heatmap/+stats/+trends` 不可用，分析主要依赖 PR 列表数据
- ⚠️ **`repo +contributors` 不可用**：贡献者列表从 PR 作者提取，可能与实际 `contributor_users_count` 有差异（后者包含未提 PR 的参与者）
- ⚠️ **数据仅反映 GitLink 平台活动**：不包括 GitHub 或其他平台的数据
- ℹ️ **参照样例**：[`EXAMPLES.md`](EXAMPLES.md) 包含手动执行和 Agent 调用两种场景的完整样例，[`examples/jiangtx-gitlink-cli.md`](examples/jiangtx-gitlink-cli.md) 包含原始命令输出数据

201
skills/gitlink-contributor-insight/examples/jiangtx-gitlink-cli.md Normal file
View File

@ -0,0 +1,201 @@
# 执行样例：jiangtx/gitlink-cli 贡献者活跃度分析
> 执行日期：2026-06-03
> 执行版本：gitlink-cli (当前版本)
> 说明：本文件记录了一次完整的贡献者分析执行过程，包含实际命令输出和最终报告。可作为后续分析的参考模板。
---
## 实际执行的命令与输出
### 1. `gitlink-cli repo +info`
```json
{
"ok": true,
"data": {
"author": { "id": 148911, "login": "jiangtx", "name": "jiangtx" },
"clone_url": "https://gitlink.org.cn/jiangtx/gitlink-cli.git",
"contributor_users_count": 2,
"default_branch": "master",
"fork_info": {
"fork_form_name": "gitlink-cli",
"fork_project_identifier": "gitlink-cli",
"fork_project_user_login": "Gitlink",
"fork_project_user_name": "GitLink"
},
"forked_from_project_id": 1513956,
"full_name": "jiangtx/gitlink-cli",
"identifier": "gitlink-cli",
"issues_count": 0,
"permission": "Manager",
"private": false,
"project_id": 1547588,
"pull_requests_count": 9,
"size": "13.4 MB",
"watchers_count": 0
}
}
```
### 2. `gitlink-cli pr +list` (关键数据源)
9 个 PR，全部已合并。按作者汇总：
| author_login | PR 数 | PR 编号 | 时间范围 |
|-------------|--------|---------|----------|
| lindiwen23 | 5 | #1, #6, #7, #8, #9 | 2026-06-01～06-03 |
| jiangtx | 4 | #2, #3, #4, #5 | 2026-06-02～06-03 |
PR 详细列表：
```json
// lindiwen23 的 PR
{ "pull_request_number": 1, "author_login": "lindiwen23",
"name": "feat: 新增 3 个 Skill（onboarding / issue-triage / research-tracker）",
"pr_full_time": "2026-06-01T11:33:00.000+08:00", "pull_request_status": 1,
"journals_count": 3 }
{ "pull_request_number": 6, "author_login": "lindiwen23",
"name": "fix: detectHTMLResponse 跳过 XML 声明，添加 HTML 响应检测",
"pr_full_time": "2026-06-03T08:55:10.000+08:00", "pull_request_status": 1,
"journals_count": 2 }
{ "pull_request_number": 7, "author_login": "lindiwen23",
"name": "feat: org +teams/+create-team/+remove-user, search +code/+issues",
"pr_full_time": "2026-06-03T09:13:15.000+08:00", "pull_request_status": 1,
"journals_count": 2 }
{ "pull_request_number": 8, "author_login": "lindiwen23",
"name": "feat: 新建 notification 模块并注册",
"pr_full_time": "2026-06-03T09:17:32.000+08:00", "pull_request_status": 1,
"journals_count": 2 }
{ "pull_request_number": 9, "author_login": "lindiwen23",
"name": "fix: Skills 文件 api 命令替换为 Shortcut 命令 (~107 处)",
"pr_full_time": "2026-06-03T09:38:05.000+08:00", "pull_request_status": 1,
"journals_count": 2 }
// jiangtx 的 PR
{ "pull_request_number": 2, "author_login": "jiangtx",
"name": "基础设施修复",
"pr_full_time": "2026-06-02T16:54:43.000+08:00", "pull_request_status": 1,
"journals_count": 2 }
{ "pull_request_number": 3, "author_login": "jiangtx",
"name": "repo 域补全",
"pr_full_time": "2026-06-02T23:27:46.000+08:00", "pull_request_status": 1,
"journals_count": 2 }
{ "pull_request_number": 4, "author_login": "jiangtx",
"name": "pr 域补全",
"pr_full_time": "2026-06-03T00:09:46.000+08:00", "pull_request_status": 1,
"journals_count": 2 }
{ "pull_request_number": 5, "author_login": "jiangtx",
"name": "label 模块新建",
"pr_full_time": "2026-06-03T00:25:32.000+08:00", "pull_request_status": 1,
"journals_count": 2 }
```
### 3. `gitlink-cli user +info --login jiangtx`
```json
{
"ok": true,
"data": {
"login": "jiangtx", "name": "jiangtx",
"user_id": 148911,
"created_time": "2026-04-28 11:46",
"user_projects_count": 3,
"user_org_count": 0,
"user_identity": "专业人士"
}
}
```
### 4. `gitlink-cli user +info --login lindiwen23`
```json
{
"ok": true,
"data": {
"login": "lindiwen23", "name": "lindiwen23",
"user_id": 141609,
"created_time": "2025-05-26 22:40",
"user_projects_count": 6,
"user_org_count": 1,
"user_identity": "专业人士"
}
}
```
### 5. 不可用的命令
| 命令 | 结果 |
|------|------|
| `gitlink-cli repo +contributors` | 命令不存在，返回 repo 帮助文本 |
| `gitlink-cli user +heatmap` | 命令不存在（user 仅 `+info` / `+me`） |
| `gitlink-cli user +stats` | 命令不存在 |
| `gitlink-cli user +trends` | 命令不存在 |
| `gitlink-cli api GET "/api/v1/repos/.../contributors"` | 返回 HTML 页面，非 JSON |
| `gitlink-cli api GET "/api/v1/users/.../heatmap"` | 返回 HTML 页面，非 JSON |
---
## 数据处理过程
### 贡献者发现
由于 `repo +contributors` 不可用：
1. 从 `repo +info` 获取 `contributor_users_count = 2`
2. 从 `pr +list` 提取唯一 `author_login`：`["lindiwen23", "jiangtx"]`（2 人，一致）
### 活跃天数计算
从 PR 的 `pr_full_time` 字段提取日期：
| 贡献者 | 活跃日期 | 活跃天数 |
|--------|----------|----------|
| lindiwen23 | 2026-06-01, 2026-06-03 | 2 天 |
| jiangtx | 2026-06-02, 2026-06-03 | 2 天 |
### 趋势判断
按日聚合 PR 数：
- 06-01: 1 PR
- 06-02: 2 PRs
- 06-03: 6 PRs
趋势：↑ 上升（日产出加速：1→2→6）
### 贡献类型分类
| 贡献者 | PR 数 | Issue 数 | 类型 |
|--------|-------|----------|------|
| lindiwen23 | 5 | 0 | 代码贡献者 |
| jiangtx | 4 | 0 | 代码贡献者 |
> Issue 来源：`repo +info` 中 `issues_count = 0`，无 Issue 需要获取。
### 分级调整
由于项目仅 3 天历史（< 30 天），适用年轻项目特殊处理：
- jiangtx（PR=4，2 活跃天）→ 🔥 核心贡献者
- lindiwen23（PR=5，2 活跃天）→ 🔥 核心贡献者
---
## 完整输出报告
（见当天执行输出，此处省略以保持文件精简。核心结构：团队概览 → 排行榜 → 个人分析 → 健康度评估 → 建议。）
---
## 经验总结
1. **PR 数据可作为贡献者分析的主要数据源**：`pr +list` 提供了作者、时间、状态、标题等丰富信息
2. **`pr_full_time` 字段足够做时间分布分析**：可计算活跃天数、贡献频率、趋势
3. **`user +info` 补充贡献者画像**：注册时间、项目数、组织数可用于背景分析
4. **极端年轻项目的分级需放宽**：标准分级（PR > 10）对 3 天项目不适用
5. **Raw API 不可靠**：GitLink 的 API 结构与标准 Gitea 不同，建议仅使用 Shortcut 命令

95
skills/gitlink-issue-triage/SKILL.md
View File

@ -1,6 +1,6 @@
---
name: gitlink-issue-triage
version: 1.0.0
version: 1.1.0
description: "Issue 智能分拣：自动分析仓库 Issue 列表，按类型、紧急度、复杂度分类，生成分拣报告和维护建议。当用户需要整理 Issue、分类 Issue、Issue 分拣、Issue 优先级排序时触发。"
metadata:
requires:
@ -11,7 +11,7 @@ metadata:
# gitlink-issue-triage（Issue 智能分拣）
**CRITICAL — 开始前必须先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)，其中包含认证、权限处理和 API 注意事项。**
**CRITICAL — 本 Skill 为只读操作，不会修改任何 Issue。无需用户额外确认即可执行。**
**CRITICAL — `issue +series-update` 为写操作，会批量修改 Issue 状态。执行前需确认用户意图。**
**CRITICAL — GitLink 操作只能用 `gitlink-cli`。禁止用 `gh`（GitHub CLI）操作 GitLink 资源。**
> **前置条件：** 先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md) 了解认证和全局参数。
@ -25,7 +25,9 @@ metadata:
1. **类型分类** — 判断每个 Issue 是 Bug、功能请求、文档问题还是使用咨询
2. **紧急度评估** — 根据关键词和优先级字段标注紧急程度
3. **复杂度预估** — 根据描述详尽程度评估修复难度
4. **行动建议** — 给出具体处理建议（立即修复/需讨论/可关闭/适合作入门任务）
4. **活动日志分析** — 通过 `issue +journals` 查看 Issue 活动历史
5. **行动建议** — 给出具体处理建议（立即修复/需讨论/可关闭/适合作入门任务）
6. **批量操作** — 支持通过 `issue +series-update` 批量更新 Issue 状态
---
@ -71,6 +73,22 @@ gitlink-cli issue +view --owner <owner> --repo <repo> --number <project_issues_i
| 活跃度 | `comment_journals_count`, `updated_at` | 讨论热度和最后活跃时间 |
| 分配状态 | `assigners` | 是否已有人负责 |
### Step 3.5：活动日志分析（v1.1 新增）
对高优先级 Issue（urgent/high），获取活动日志以了解处理进展：
```bash
gitlink-cli issue +journals --owner <owner> --repo <repo> --number <project_issues_index> --format json
```
从 `journals` 数组中提取：
- 最近一次状态变更时间和操作者
- 最近一次评论时间和作者
- 是否有 @提及等待回复
- 是否有分配变更记录
> ⚠️ **控制调用量**：仅对 urgent/high 级别的 Issue 获取活动日志。日志数据可能较大，只提取关键时间节点。
### Step 4：分类规则
#### 4.1 类型分类（type）
@ -120,6 +138,20 @@ gitlink-cli issue +view --owner <owner> --repo <repo> --number <project_issues_i
将所有分析结果组织输出。
### Step 6：批量操作（v1.1 新增，可选，需确认）
根据分拣结果，可批量更新 Issue 状态：
```bash
gitlink-cli issue +series-update --owner <owner> --repo <repo> --ids <id1,id2,id3> --status closed --format json
```
> ⚠️ **写操作**：执行前需向用户展示将要操作的 Issue 列表，获得确认后再执行。
典型使用场景：
- 批量关闭 `close-candidate` 列表中的 Issue
- 批量将 `good-first-issue` 标记为 open（确保状态正确）
---
## 输出模板
@ -151,40 +183,31 @@ gitlink-cli issue +view --owner <owner> --repo <repo> --number <project_issues_i
> 如本段为空，输出：*当前无紧急 Issue，状态健康。*
| # | 标题 | 类型 | 紧急度 | 复杂度 | 建议 | 备注 |
|---|------|------|--------|--------|------|------|
| {{number}} | {{subject}} | bug | urgent | medium | fix-now | |
| ... | ... | ... | ... | ... | ... | ... |
| # | 标题 | 类型 | 紧急度 | 复杂度 | 上次活动 | 建议 | 备注 |
|---|------|------|--------|--------|----------|------|------|
| {{number}} | {{subject}} | bug | urgent | medium | {{last_journal_time}} | fix-now | |
| ... | ... | ... | ... | ... | ... | ... | ... |
## 🟡 建议近期处理
> 如本段为空，输出：*当前无高优先级 Issue。*
| # | 标题 | 类型 | 紧急度 | 复杂度 | 建议 | 备注 |
|---|------|------|--------|--------|------|------|
| ... | ... | bug/feature | high/normal | easy/medium | investigate/implement | |
| # | 标题 | 类型 | 紧急度 | 复杂度 | 上次活动 | 建议 | 备注 |
|---|------|------|--------|--------|----------|------|------|
| ... | ... | bug/feature | high/normal | easy/medium | ... | investigate/implement | |
## 🟢 可延迟 / 需讨论
> 如本段为空，输出：*所有 Issue 均已明确，无需额外讨论。*
| # | 标题 | 类型 | 紧急度 | 复杂度 | 建议 | 备注 |
|---|------|------|--------|--------|------|------|
| ... | ... | question/feature | normal/low | medium/hard | discuss | |
| # | 标题 | 类型 | 紧急度 | 复杂度 | 上次活动 | 建议 | 备注 |
|---|------|------|--------|--------|----------|------|------|
| ... | ... | question/feature | normal/low | medium/hard | ... | discuss | |
## ⭐ 适合入门（Good First Issue）
> 如本段为空，输出：*暂无完全符合条件的入门 Issue。建议在后续工作中拆分出简单子任务。*
| # | 标题 | 类型 | 复杂度 | 推荐理由 |
|---|------|------|--------|----------|
| {{number}} | {{subject}} | bug/docs | easy | 范围明确，单文件修改 |
| ... | ... | ... | ... | ... |
## ⚠️ 候选关闭（90+ 天无活动）
> 如本段为空，输出：*无长期不活跃的 Issue。*
| # | 标题 | 最后更新 | 建议 |
|---|------|----------|------|
| {{number}} | {{subject}} | {{updated_at}} | 评论询问是否仍需要，如无回应可关闭 |
@ -194,11 +217,18 @@ gitlink-cli issue +view --owner <owner> --repo <repo> --number <project_issues_i
## 📋 维护建议
1. **立即行动**：{{urgent_count}} 个紧急 Issue 需要优先处理
2. **本周目标**：建议处理 {{suggested_this_week}} 个 Issue（suggested_this_week = 建议近期处理段中的 Issue 数量，即 bug+normal/high + feature+清晰描述 的总数）
3. **社区引导**：{{good_first_issue_count}} 个 Issue 适合标记为 good first issue，吸引新贡献者
4. **清理计划**：{{close_candidate_count}} 个 Issue 长期无活动，建议批量确认后关闭
5. {{#if no_tags}}本仓库未使用 Issue 标签系统，建议建立标签体系（bug/feature/docs/question/meta/help-wanted/good-first-issue）以提升管理效率{{/if}}
6. {{#if status_anomalies}}本批次有 {{status_anomaly_count}} 个 Issue 状态异常（status_id=0），建议在平台上手动确认{{/if}}
2. **本周目标**：建议处理 {{suggested_this_week}} 个 Issue
3. **社区引导**：{{good_first_issue_count}} 个 Issue 适合标记为 good first issue
4. **清理计划**：{{close_candidate_count}} 个 Issue 长期无活动，建议批量关闭
5. {{#if no_tags}}本仓库未使用 Issue 标签系统，建议建立标签体系{{/if}}
6. {{#if status_anomalies}}本批次有 {{status_anomaly_count}} 个 Issue 状态异常（status_id=0）{{/if}}
### 批量操作建议
> 如无适用操作，输出：*当前无需批量操作。*
以下 Issue 建议批量关闭（已确认超 90 天无活动）：
`gitlink-cli issue +series-update --owner <owner> --repo <repo> --ids {{close_ids}} --status closed`
```
---
@ -212,15 +242,18 @@ gitlink-cli issue +view --owner <owner> --repo <repo> --number <project_issues_i
| 全部 Issue 无标签/无优先级 | 分类完全依赖标题和描述关键词分析，并在报告末尾建议建立标签体系 |
| `description` 为空或仅含图片/附件链接 | 标注"描述缺失"，类型仅根据标题判断，复杂度标为 hard，建议标记为 discuss |
| `status_id` = 0（未知） | 纳入分析但标注"状态异常" |
| `issue +journals` 返回空 | 标注"无活动日志"，不阻塞分析 |
---
## 注意事项
- ✅ **所有命令使用 `--format json`**，确保可解析
- ✅ **`issue +view` 使用 `--number`（网页编号）**，非数据库 ID
- ✅ **本 Skill 为纯只读分析**，不会修改任何 Issue
- ✅ **Owner/repo 优先从 `git remote` 自动解析**，无 git 上下文时询问用户
- ✅ **`issue +view` 和 `+journals` 使用 `--number`（网页编号）**，非数据库 ID
- ✅ **本 Skill 以只读分析为主**，批量操作需确认后执行
- ✅ **Owner/repo 优先从 `git remote` 自动解析**
- ⚠️ **`issue +list --state open` 过滤不准确**，必须客户端按 `status_id` 二次过滤
- ⚠️ **`issue +journals` 仅对 urgent/high Issue 调用**，控制 API 调用量
- ⚠️ **`issue +series-update` 为写操作**，需用户确认，使用逗号分隔的 Issue ID
- ⚠️ **分类规则是启发式的**，AI 应根据实际内容做判断，不要机械匹配关键词
- ⚠️ **Issue 数量多时分批处理**，超过 50 条建议先按更新时间排序，优先分析最近活跃的
- ⚠️ **Issue 数量多时分批处理**，超过 50 条建议先按更新时间排序

187
skills/gitlink-notification-digest/SKILL.md Normal file
View File

@ -0,0 +1,187 @@
---
name: gitlink-notification-digest
version: 1.0.0
description: "通知摘要：汇总 GitLink 通知并按类型分类，生成通知摘要报告，支持批量标记已读。当用户需要查看通知摘要、整理通知、清理未读通知时触发。"
metadata:
requires:
bins: ["gitlink-cli"]
cliHelp: "gitlink-cli notification --help"
---
# gitlink-notification-digest（通知摘要）
**CRITICAL — 开始前必须先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)，其中包含认证、权限处理和 API 注意事项。**
**CRITICAL — `notification +read` 和 `+read-all` 为写操作，执行前需确认用户意图。**
**CRITICAL — GitLink 操作只能用 `gitlink-cli`。禁止用 `gh`（GitHub CLI）操作 GitLink 资源。**
> **前置条件：** 先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md) 了解认证和全局参数。
---
## 功能概述
帮助用户高效管理 GitLink 通知：
1. **通知列表** — 获取所有未读通知
2. **自动分类** — 按类型（Issue/PR/评论/系统）分组
3. **优先级判断** — 识别需要立即处理的通知
4. **批量操作** — 支持标记已读（需确认）
5. **摘要报告** — 生成结构化通知摘要
---
## 工作流：通知摘要
### Step 1：获取通知列表
```bash
gitlink-cli notification +list --format json
```
获取参数：
- 默认获取未读通知
- 如需全部通知（含已读）：`--all`
- 如需仅参与的通知：`--participating`
- 分页：`--page 2 --limit 20`
提取每条通知的：
- `id` — 通知 ID（用于 `+read` 单条标记已读）
- `content` — 通知内容（HTML 格式，从中提取摘要文本）
- `source` — 通知来源类型（如 IssueAtme、PullRequestAssigned、ProjectForked 等）
- `notification_url` — 通知链接，从中解析关联仓库（提取 URL path 中的 `/owner/repo/` 段）
- `created_at` — 通知时间
- `status` — 状态（1=未读，2=已读）
### Step 2：分类与优先级
#### 2.1 按类型分类（优先使用 `source` 字段）
| 类型 | `source` 字段匹配 | 处理建议 |
|------|------------------|----------|
| 🔴 **@提及** | 含 `Atme`（如 IssueAtme, PullRequestAtme） | 立即查看回复 |
| 🟡 **Issue 更新** | 含 `Issue`（如 IssueAssigned, IssueClosed） | 当天处理 |
| 🟢 **PR 更新** | 含 `PullRequest`（如 PullRequestAssigned, PullRequestMerged） | 跟进代码 |
| 🔵 **系统通知** | 含 `Project`/`Organization`（如 ProjectForked, ProjectJoined） | 知悉即可 |
| ⚪ **其他** | 不匹配以上 | 按需查看 |
> `source` 字段返回的是结构化枚举值（如 `IssueAtme`），优先以此分类。`content` 字段为 HTML 文本，仅作补充参考。
#### 2.2 优先级排序
| 优先级 | 判定 |
|--------|------|
| **P0 - 立即** | @提及 + 来自自己参与的 Issue/PR |
| **P1 - 今天** | 自己创建的 Issue/PR 有新回复，或分配的 Issue 有更新 |
| **P2 - 本周** | 关注的仓库有新动态 |
| **P3 - 可忽略** | 系统通知、已解决的 Issue |
### Step 3：生成通知摘要
按模板输出。
### Step 4：批量标记已读（可选，需确认）
```bash
# 标记全部已读
gitlink-cli notification +read-all --format json
# 标记单条已读
gitlink-cli notification +read --id <notification_id> --format json
```
> ⚠️ **执行前必须确认用户意图** — `+read` 和 `+read-all` 为写操作。
---
## 输出模板
```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}} |
---
## 操作建议
- 建议标记已读：{{suggest_read_count}} 条 P3 通知
- 需要回复/处理：{{need_action_count}} 条 P0/P1 通知
如需标记全部已读，我可以执行：
`gitlink-cli notification +read-all`
```
---
## 异常场景处理
| 场景 | 处理方式 |
|------|----------|
| 无未读通知 | 输出"🎉 所有通知已处理完毕" |
| 通知数量 > 50 | 分批获取（page 1/2/3），优先分析最近 50 条 |
| `notification +list` 返回空 | 检查认证状态（参考 gitlink-shared） |
---
## 注意事项
- ✅ **所有命令使用 `--format json`**，确保可解析
- ✅ **`+read` 和 `+read-all` 为写操作**，执行前必须确认用户意图
- ✅ **本 Skill 默认只读分析**，仅在用户明确要求时标记已读
- ⚠️ **通知类型依赖标题关键词推断**，实际类型可能有偏差
- ⚠️ **通知可能分页**，数量 >20 时需追加 `--page 2` 等

124
skills/gitlink-research-tracker/SKILL.md
View File

@ -1,6 +1,6 @@
---
name: gitlink-research-tracker
version: 1.0.0
version: 1.1.0
description: "技术评估与调研报告：对技术项目进行多维度评估（社区活跃度、成熟度评分、技术趋势），生成含选型建议的结构化调研报告。当用户需要做技术评估、生成调研报告、科研选题分析、竞品对比研究时触发。"
metadata:
requires:
@ -22,7 +22,7 @@ metadata:
面向科研场景的技术调研工具，帮助研究者快速了解 GitLink 平台上的技术格局：
1. **多关键词搜索** — 将研究主题拆解为多个关键词，全面覆盖相关项目
1. **多关键词搜索** — 仓库搜索 + 代码搜索 + Issue 搜索，三维覆盖
2. **项目深度评估** — 从活跃度、社区规模、代码产出等维度评估项目健康度
3. **横向对比** — 对比同类项目的核心指标，识别领先者和潜力项目
4. **趋势洞察** — 基于更新时间、贡献者增长、版本发布频率等推断技术趋势
@ -45,9 +45,9 @@ metadata:
> **原则**：关键词应覆盖中英文、缩写全称、技术术语和行业叫法。每个关键词独立搜索。
### Step 2：多关键词搜索
### Step 2：多维度搜索（v1.1 扩展：三维搜索）
对每个关键词执行搜索：
#### 2a. 仓库搜索
```bash
gitlink-cli search +repos -k <关键词> --format json
@ -57,13 +57,43 @@ gitlink-cli search +repos -k <关键词> --format json
| SKILL 中用到的概念 | 实际字段来源 | 说明 |
|-------------------|-------------|------|
| owner/repo 标识 | `author.login` + `/` + `identifier` | 搜索结果**没有** `full_name`，需手动拼接。`identifier` 是仓库的唯一标识符 |
| owner/repo 标识 | `author.login` + `/` + `identifier` | 搜索结果**没有** `full_name`，需手动拼接 |
| 项目描述 | `description` | 直接可用 |
| 关注度 | `praises_count` | 搜索结果中叫 `praises_count`，**不是** `stars`。`watchers_count` 仅在 `repo +info` 中返回 |
| 关注度 | `praises_count` | 搜索结果中叫 `praises_count`，**不是** `stars` |
| Fork 数 | `forked_count` | 搜索结果中叫 `forked_count`，**不是** `forks_count` |
| 编程语言 | `language.name` | `language` 是嵌套对象 `{id, name}`，需取 `.name`。可能为 `null` |
| 更新时间 | `last_update_time`（Unix 时间戳）或 `full_last_update_time`（ISO 8601 字符串） | 搜索结果中**没有** `updated_at` |
| 是否镜像 | `mirror` | 仅在 `repo +info` 返回。GitLink 上大量仓库是 GitHub 镜像，需特别标注 |
| 更新时间 | `last_update_time` 或 `full_last_update_time` | 搜索结果中**没有** `updated_at` |
| 是否镜像 | `mirror` | 仅在 `repo +info` 返回 |
#### 2b. 代码搜索（v1.1 新增）
对技术关键词搜索代码引用，了解技术在实际项目中的使用情况：
```bash
gitlink-cli search +code -k <关键词> --format json
```
从结果中提取：
- 匹配到的文件路径和仓库
- 代码片段预览
- 判断：哪些项目**实际使用了**该技术（而非仅描述中提到）
> 代码搜索结果用于辅助判断"代码活跃度"——有大量代码匹配的项目说明该技术在实际开发中活跃使用。
#### 2c. Issue 搜索（v1.1 新增）
搜索与主题相关的 Issue 讨论，了解技术痛点和需求：
```bash
gitlink-cli search +issues -k <关键词> --format json
```
从结果中提取：
- 高频讨论主题
- 常见技术痛点和需求
- 社区对某个技术的关注焦点
> ⚠️ **控制搜索量**：代码搜索和 Issue 搜索仅针对 2-3 个核心关键词执行，不是全部关键词。避免 API 调用过多。
**去重规则**：用 `author.login/identifier` 作为唯一标识。同一仓库出现在多个关键词结果中时，只保留一次，标注匹配了哪些关键词。
@ -87,6 +117,7 @@ gitlink-cli repo +info --owner <owner> --repo <repo> --format json
| **代码规模** | `size` | 粗略判断项目复杂度 |
| **开放性** | `forked_count` | fork 数反映二次开发热度 |
| **PR 活跃度** | `pull_requests_count` | 反映代码贡献频率 |
| **代码活跃度**（v1.1） | `search +code` 命中量 | 反映技术在实际代码中的使用程度 |
可选补充（如有需要）：
@ -98,33 +129,29 @@ gitlink-cli issue +list --owner <owner> --repo <repo> --state open --format json
gitlink-cli release +list --owner <owner> --repo <repo> --format json
```
> ⚠️ **控制分析数量**：深度评估仅对最有价值的 5~8 个项目执行（优先匹配多关键词、watchers 多、updated_at 最近的项目），避免过多 API 调用。
> ⚠️ **控制分析数量**：深度评估仅对最有价值的 5~8 个项目执行，避免过多 API 调用。
### Step 4：横向对比与趋势分析
#### 4.1 项目分类与镜像识别
在评分之前，先通过 `repo +info` 的 `mirror` 字段区分项目类型：
| 类型 | 判定 | 处理 |
|------|------|------|
| **镜像仓库** | `mirror: true` | 标注 `[镜像]`。GitLink 上的 `contributor_users_count`/`watchers_count` 等指标均为 0，不代表真实社区活跃度。评分仅作参考 |
| **镜像仓库** | `mirror: true` | 标注 `[镜像]`。评分仅作参考 |
| **原创仓库** | `mirror: false` 且 `forked_from_project_id: null` | 正常评分 |
| **Fork 仓库** | `forked_from_project_id` 非 null | 标注 `[Fork]`，评分反映的是 Fork 后的独立开发情况 |
| **Fork 仓库** | `forked_from_project_id` 非 null | 标注 `[Fork]` |
#### 4.2 项目成熟度评分
对每个深度评估的项目，按以下标准打分（满分 25）：
#### 4.2 项目成熟度评分（满分 25）
| 维度 | 权重 | 评分标准 |
|------|------|----------|
| 社区规模 | 5 | contributor_users_count: >20=5, >10=4, >5=3, >2=2, ≤2=1 |
| 关注度 | 5 | repo +info 的 watchers_count: >30=5, >15=4, >8=3, >3=2, ≤3=1 |
| 研发节奏 | 5 | version_releases_count: >10=5, >5=4, >1=3, 0=2。**镜像仓库此项固定给 1**（镜像通常不通过 GitLink 发版）。注意 GitLink 平台 Release 功能使用率低，即使原创仓库 release=0 也建议给 2 而非 1 |
| 开发活跃 | 5 | 最近 30 天有更新=5, 60 天=4, 90 天=3, 180 天=2, >180 天=1。（基于 `repo +info` 的更新时间或搜索结果中的 `last_update_time`） |
| 关注度 | 5 | watchers_count: >30=5, >15=4, >8=3, >3=2, ≤3=1 |
| 研发节奏 | 5 | version_releases_count: >10=5, >5=4, >1=3, 0=2。镜像仓库固定给 1 |
| 开发活跃 | 5 | 最近 30 天有更新=5, 60 天=4, 90 天=3, 180 天=2, >180 天=1 |
| 开放性 | 5 | forked_count: >30=5, >15=4, >8=3, >3=2, ≤3=1 |
> **镜像修正**：镜像仓库的社区规模、关注度、开放性三项在 GitLink 上均为 0，应标注"数据为 GitLink 平台内数据，不代表项目在原始平台（GitHub）的真实影响力"，不参与排名比较。
> **镜像修正**：镜像仓库评分仅作参考，不参与排名比较。
#### 4.3 技术趋势推断
@ -132,6 +159,7 @@ gitlink-cli release +list --owner <owner> --repo <repo> --format json
- **成熟信号**：大量 watcher + 稳定 Release 节奏 + 大社区 → 技术趋于成熟
- **衰退信号**：超过 180 天无更新 + 少量 contributor + 无新 Release → 可能已不活跃
- **新兴信号**：小社区 + 快速迭代 + 最新更新时间近 → 可能是新兴项目
- **代码证据**（v1.1）：`search +code` 命中量增长 → 技术采纳度上升
### Step 5：生成技术调研报告
@ -144,7 +172,8 @@ gitlink-cli release +list --owner <owner> --repo <repo> --format json
> 调研时间：{{当前时间}}
> 搜索关键词：{{keyword_list}}
> 搜索命中：{{total_hits}} 个仓库，去重后 {{unique_count}} 个，深度分析 {{deep_analysis_count}} 个
> 搜索维度：仓库搜索 {{repo_hits}} + 代码搜索 {{code_hits}} + Issue 搜索 {{issue_hits}}
> 去重后 {{unique_count}} 个项目，深度分析 {{deep_analysis_count}} 个
---
@ -157,15 +186,15 @@ gitlink-cli release +list --owner <owner> --repo <repo> --format json
| 平均社区规模 | {{avg_contributors}} 人 |
| 近 30 天活跃项目 | {{active_30d_count}}（{{active_30d_pct}}%） |
| 高成熟度项目（≥20分） | {{high_maturity_count}} |
| 代码引用量 | {{code_search_hits}} 次命中（反映技术采纳度） |
---
## 二、项目成熟度排行榜
| 排名 | 项目 | 类型 | 评分 | 语言 | Watch | 贡献者 | Release | Fork | 关键词匹配 |
|------|------|------|------|------|-------|--------|---------|------|------------|
| 1 | {{full_name}} {{#if mirror}}[镜像]{{/if}} | {{原创/镜像/Fork}} | {{score}}/25 | {{language}} | {{watchers}} | {{contributors}} | {{releases}} | {{forks}} | {{matched_keywords}} |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 排名 | 项目 | 类型 | 评分 | 语言 | Watch | 贡献者 | 代码引用 | Fork | 关键词匹配 |
|------|------|------|------|------|-------|--------|----------|------|------------|
| 1 | {{full_name}} | {{原创/镜像/Fork}} | {{score}}/25 | {{language}} | {{watchers}} | {{contributors}} | {{code_refs}} | {{forks}} | {{matched_keywords}} |
---
@ -188,18 +217,13 @@ gitlink-cli release +list --owner <owner> --repo <repo> --format json
---
### 🥈 {{项目名}}（{{score}}/25）
（同上格式）
---
## 四、技术趋势洞察
1. **热点方向**：{{当前最热的技术方向，基于项目分布推断}}
2. **新兴项目**：{{列出 1~3 个"新兴信号"明显的项目}}
3. **成熟生态**：{{列出 1~2 个"成熟信号"明显的项目，适合作为技术选型参考}}
4. **风险提示**：{{列出 1~2 个"衰退信号"项目或值得关注的生态空白}}
1. **热点方向**：{{当前最热的技术方向}}
2. **新兴项目**：{{1~3 个"新兴信号"明显的项目}}
3. **成熟生态**：{{1~2 个"成熟信号"明显的项目}}
4. **社区讨论焦点**（v1.1）：基于 `search +issues` 的技术痛点分析
5. **风险提示**：{{1~2 个"衰退信号"项目或生态空白}}
---
@ -223,6 +247,7 @@ gitlink-cli release +list --owner <owner> --repo <repo> --format json
## 六、数据来源
所有数据通过 `gitlink-cli` 从 GitLink 平台实时获取，每个项目均已通过 `repo +info` 验证。
搜索维度：`search +repos`（仓库）、`search +code`（代码）、`search +issues`（Issue）
```
---
@ -231,13 +256,14 @@ gitlink-cli release +list --owner <owner> --repo <repo> --format json
| 场景 | 处理方式 |
|------|----------|
| 关键词无搜索结果 | 尝试近义词或更宽泛的关键词重试，仍无结果则标注"该方向暂无相关项目" |
| 搜索返回大量结果（>50） | `search +repos` 无分页参数，实际返回约 20 条/关键词。合并后按 `praises_count` 降序取前 20 |
| 某项目 `repo +info` 返回 404 | 该项目可能为私有或已删除，从列表中移除 |
| `repo +info` 网络超时/TLS 错误 | 等待 5 秒后重试一次。仍失败则标注"网络请求失败"，跳过该项目继续分析其余 |
| 大量搜索结果来自镜像仓库 | 优先分析 `mirror: false` 的原创项目。镜像项目保留但标注，评分仅作参考 |
| 所有项目评分均 <15 | 说明该领域尚未形成成熟生态，调整报告语气为"早期探索阶段" |
| 用户未提供具体关键词 | 引导用户明确研究主题，提供几个示例关键词供选择 |
| 关键词无搜索结果 | 尝试近义词重试，仍无结果则标注"该方向暂无相关项目" |
| 搜索返回大量结果（>50） | 合并后按 `praises_count` 降序取前 20 |
| 某项目 `repo +info` 返回 404 | 从列表中移除 |
| `repo +info` 网络超时/TLS 错误 | 等待 5 秒后重试一次，仍失败则跳过 |
| 大量搜索结果来自镜像仓库 | 优先分析 `mirror: false` 的原创项目 |
| 所有项目评分均 <15 | 调整报告语气为"早期探索阶段" |
| `search +code` 返回空 | 标注"代码搜索无命中"，不阻塞分析 |
| `search +issues` 返回空 | 标注"Issue 搜索无命中"，不阻塞分析 |
| `language` 字段为 `null` | 标注为"未知" |
---
@ -246,11 +272,11 @@ gitlink-cli release +list --owner <owner> --repo <repo> --format json
- ✅ **所有命令使用 `--format json`**，确保可解析
- ✅ **本 Skill 为纯只读分析**，不会修改任何仓库
- ✅ **搜索关键词建议中英文各覆盖**，提高命中率
- ✅ **搜索关键词建议中英文各覆盖**
- ✅ **深度评估控制在 5~8 个项目**，避免调用过多 API
- ⚠️ **`search +repos` 和 `repo +info` 字段名不同**：搜索结果用 `praises_count`/`forked_count`/`author.login+identifier`，`repo +info` 才有 `watchers_count`/`full_name`/`mirror`。详见 Step 2 字段映射表
- ⚠️ **`repo +info` 并发请求可能触发 TLS 超时**，失败时等 5 秒重试一次，不要放弃
- ⚠️ **GitLink 平台镜像仓库比例高**，镜像仓库的社区数据为 0，不代表项目真实影响力。在报告中标注 `[镜像]` 并单独说明
- ⚠️ **GitLink Release 功能使用率低**，大部分项目 `version_releases_count`=0。评分时 Release 维度降低权重预期，0 个 Release 给 2 分（而非 1 分）
- ⚠️ **搜索结果无分页参数**，每次返回约 20 条。关键词超过 5 个时需手动截断合并结果
- ⚠️ **本 Skill 场景适配 GitLink 平台**，GitLink 以国内开发者和企业项目为主，搜索结果可能偏向中文技术生态，且镜像项目较多
- ⚠️ **v1.1 新增 `search +code` 和 `+issues`**：仅对 2-3 个核心关键词执行，控制 API 调用总量
- ⚠️ **`search +repos` 和 `repo +info` 字段名不同**：搜索结果用 `praises_count`/`forked_count`，`repo +info` 有 `watchers_count`/`full_name`/`mirror`
- ⚠️ **`repo +info` 并发请求可能触发 TLS 超时**，失败时等 5 秒重试一次
- ⚠️ **GitLink 平台镜像仓库比例高**，镜像仓库的社区数据为 0
- ⚠️ **GitLink Release 功能使用率低**，0 个 Release 给 2 分（非镜像）
- ⚠️ **本 Skill 场景适配 GitLink 平台**，结果可能偏向中文技术生态