gitlink-cli/workflows

GitLink CLI 工作流自动化

5 个端到端自动化场景，将 gitlink-cli 的 shortcut 命令串联成完整工作流，解决实际项目管理痛点。

---

环境准备

1. 安装 gitlink-cli

# 确认已安装
gitlink-cli version

# 未安装则从项目根目录构建
cd /home/kevin/gitlink-cli
make build

2. 安装 jq

脚本用 jq 解析 CLI 返回的 JSON。

# Ubuntu/Debian
sudo apt-get install -y jq

# macOS
brew install jq

3. 登录认证

# 方式一：交互式登录（推荐）
gitlink-cli auth login

# 方式二：环境变量
export GITLINK_TOKEN="你的私人令牌"
# 令牌获取：https://gitlink.org.cn → 个人设置 → 私人令牌

# 验证
gitlink-cli auth status
# 应显示：✓ Logged in as 用户名

4. 验证环境

# 测试 JSON 输出是否正常
gitlink-cli issue +list --owner zzx-coder --repo gitlink-cli --state open --limit 3 --format json | jq '.ok'
# 应输出：true

---

五个场景

#	场景	脚本	串联命令	解决什么问题
1	社区运营自动化	01-community-ops.sh	7 个	Issue 积压无人处理、周报手写、Release Notes 手动整理
2	代码质量看门人	02-code-quality-gatekeeper.sh	7 个	PR 审查效率低、质量标准不统一、AI 代码审查（基于 gitlink-code-review skill）
3	项目一键初始化	03-project-init.sh	6 个	新建项目重复劳动多、Issue/文档/分支保护手动配
4	多仓库协同	04-multi-repo-collab.sh	7 个	跨仓库状态分散、缺乏统一视图
5	贡献者成长体系	05-contributor-growth.sh	6 个	贡献者活跃度难追踪、缺乏激励机制

---

场景一：社区运营自动化

脚本: 01-community-ops.sh

解决什么问题

新 Issue 没人分类、不知道谁该负责、社区周报手写、发版时才手忙脚乱写 Release Notes。

工作流程

issue +list → 读取所有 open Issue
    ↓
按关键词分类: Bug / Feature / Question / Docs
    ↓
issue +label-add → 自动打标签
    ↓
repo +members → 获取仓库成员列表
issue +update → 轮询分配负责人
    ↓
pr +list → 统计本周合并的 PR
issue +list → 统计本周关闭的 Issue
    ↓
wiki +create → 发布社区周报到 Wiki
    ↓
release +create → 自动生成 Release Notes

串联的命令

步骤	命令	作用
1	issue +list	获取所有 open Issue
2	issue +label-add	按分类打标签 (bug/feature/question/documentation)
3	repo +members	获取仓库成员列表
4	issue +update	给 Bug/Feature Issue 分配负责人
5	pr +list	统计本周合并的 PR
6	wiki +create	发布社区周报
7	release +create	自动生成 Release Notes

输出有什么用

• 标签分类: 仓库 Issue 页面可按标签筛选，一目了然
• 负责人分配: 每个 Issue 有明确负责人，避免互相推诿
• Wiki 周报: 团队和社区用户可在 Wiki 查看每周进展
• Release Notes: 发版时无需手动整理变更

运行

bash workflows/01-community-ops.sh --owner 你的组织 --repo 你的仓库

# 示例
bash workflows/01-community-ops.sh --owner zzx-coder --repo gitlink-cli

---

场景二：代码质量看门人

脚本: 02-code-quality-gatekeeper.sh

解决什么问题

PR 审查是代码质量的核心环节，但人工审查耗时且标准不统一。这个工作流加载 gitlink-code-review skill 的审查方法论，用 AI (Claude) 对 PR 进行四维度代码审查，自动打分评级，达标后自动合并。

工作流程

pr +list → 获取所有 open PR
    ↓
pr +view → 读取 PR 详情
pr +files → 获取变更文件列表
pr +diff → 获取代码差异
    ↓
加载 gitlink-code-review skill:
  - 审查维度与检查项
  - 评分标准 (90-100 优秀, 75-89 良好, ...)
  - 问题严重级别 (CRITICAL/HIGH/MEDIUM/LOW)
    ↓
┌─────────────────────────────────────┐
│  AI 代码审查 (Claude + Skill)       │
│  四维度评分 (各 0-25，总分 100):     │
│  - 代码质量: 复杂度、命名、注释      │
│  - 安全性: SQL注入、XSS、敏感信息    │
│  - 性能: 循环效率、资源泄漏、N+1     │
│  - 可维护性: 重复、职责单一、耦合    │
│                                     │
│  输出:                              │
│  - 结构化问题清单 (severity+file+    │
│    rule+description+suggestion)      │
│  - 优秀实践 (positive_notes)        │
│  - 改进建议 (recommendations)       │
│  - 总分 + PASS/FAIL                 │
└─────────────────────────────────────┘
    ↓
api POST /reviews → 发布审查评论到 PR
    ↓
ci +builds → 检查 CI 构建状态
    ↓
pr +merge → 分数 >= 阈值 且 CI 通过 → 自动合并

AI 审查示例输出（基于 gitlink-code-review skill）

Overall Score:        88 / 100
Code Quality:         23 / 25
Security:             25 / 25
Performance:          20 / 25
Maintainability:      20 / 25

Issues Found:
  - [LOW] quality: 条目格式说明中 PR 条目用 (@作者) 带括号，commit 条目用 (作者名) 不带 @ 前缀
    → 统一格式规范，建议 commit 条目也使用 (@作者) 格式
  - [LOW] maintainability: 示例中贡献者列表变更但完整变更日志链接仍指向旧仓库
    → 将变更日志链接中的 OWNER 也更新为与示例贡献者一致

Positive Notes:
  + 变更目的清晰，所有文件的修改一致地贯彻了需求，无遗漏
  + 变更范围合理，仅修改文档和示例，不涉及代码逻辑变更，风险极低

Recommendations:
  > 统一 PR 条目和 commit 条目的作者标注格式
  > 在 collect-data.md 中补充 author 字段为空时的降级处理说明

串联的命令

步骤	命令	作用
1	pr +list	获取 open PR 列表
2	pr +view	读取 PR 详情（标题、作者、状态）
3	pr +files	获取变更文件列表
4	pr +diff	获取代码差异内容
5	gitlink-code-review	加载 skill 的审查维度、检查项、评分标准
6	claude -p	AI 按 skill 方法论进行四维度代码审查
7	api POST .../reviews	将审查评论发布到 PR
8	pr +merge	质量分 >= 阈值且 CI 通过时自动合并

输出有什么用

• 结构化评分: 每个 PR 有 0-100 的质量评分，团队可设定统一合并门槛
• AI 问题清单: 自动列出安全隐患、性能问题、代码质量问题，人工审查时重点关注
• PR 评论: 审查结果直接评论在 PR 上，作者和审查者都能看到
• 自动合并: 高质量 PR 无需人工点击

运行

# 审查所有 open PR
bash workflows/02-code-quality-gatekeeper.sh --owner 你的组织 --repo 你的仓库

# 审查指定 PR
bash workflows/02-code-quality-gatekeeper.sh --owner 你的组织 --repo 你的仓库 --pr-id 42

# 自定义质量阈值（默认 80）
bash workflows/02-code-quality-gatekeeper.sh --owner 你的组织 --repo 你的仓库 --threshold 70

# 预览模式（不实际合并）
bash workflows/02-code-quality-gatekeeper.sh --owner 你的组织 --repo 你的仓库 --dry-run

# 示例
bash workflows/02-code-quality-gatekeeper.sh --owner zzx-coder --repo gitlink-cli --pr-id 20

---

场景三：项目一键初始化

脚本: 03-project-init.sh

解决什么问题

新建项目仓库后，还要手动创建 README、写 CONTRIBUTING 指南、创建初始 Issue、设置分支保护、打初始 Release。一条命令搞定全部。

工作流程

repo +create → 创建仓库
    ↓
wiki +create → 生成 README（根据语言模板）
wiki +create → 生成 CONTRIBUTING 贡献指南
    ↓
issue +create × 5 → 创建初始待办 Issue:
  - 搭建 CI/CD 流水线
  - 编写项目文档
  - 建立代码审查流程
  - 添加单元测试
  - 配置依赖管理
    ↓
branch +protect → 保护 master 分支
    ↓
release +create → 创建 v0.1.0 初始版本

串联的命令

步骤	命令	作用
1	repo +create	创建新仓库
2	wiki +create	生成 README（支持 Go/Python/Node/Java）
3	wiki +create	生成 CONTRIBUTING 贡献指南
4	issue +create	创建 5 个初始 Issue 并打标签
5	branch +protect	设置 master 分支保护规则
6	release +create	创建 v0.1.0 初始版本

输出有什么用

• 开箱即用: 新成员克隆后就知道怎么构建、测试、贡献
• 标准化 Issue: 关键待办已创建好，团队可直接认领
• 分支保护: 防止直接 push 到 master，强制走 PR 流程
• 首个 Release: 项目从创建之初就有版本管理

运行

# Go 项目
bash workflows/03-project-init.sh --owner 你的组织 --name my-go-app --description "我的Go应用" --lang go

# Python 项目（私有）
bash workflows/03-project-init.sh --owner 你的组织 --name my-api --description "REST API服务" --lang python --private

# Node.js 项目
bash workflows/03-project-init.sh --owner 你的组织 --name my-web --description "Web前端" --lang node

# Java 项目
bash workflows/03-project-init.sh --owner 你的组织 --name my-service --description "微服务" --lang java

---

场景四：多仓库协同

脚本: 04-multi-repo-collab.sh

解决什么问题

当一个组织有多个仓库时，管理者需要逐个查看每个仓库的 Issue、PR、Release 状态。这个工作流汇总所有仓库数据，生成一个 HTML 仪表盘，并支持一键协调发版。

工作流程

repo +list → 列出组织下所有仓库
    ↓
对每个仓库:
  issue +list → 获取 open/closed Issue
  pr +list → 获取 open/merged PR
  release +list → 获取最新 Release
    ↓
生成 HTML 仪表盘:
  - 总览卡片: 仓库数、Open Issue、Open PR、总活动量
  - 详情表格: 每个仓库的 Issue/PR/Release 状态
  - 健康度: Healthy / Moderate / Needs Attention
    ↓
（可选）release +create → 一键为所有仓库创建同一版本号的 Release

串联的命令

步骤	命令	作用
1	repo +list	列出组织下所有仓库
2	issue +list	获取每个仓库的 Issue 数据
3	pr +list	获取每个仓库的 PR 数据
4	release +list	获取每个仓库的最新 Release
5	生成 HTML	输出可视化仪表盘
6	release +create	（可选）协调发版

输出有什么用

• 统一视图: 一个 HTML 页面看到组织所有仓库的健康状态
• 健康度预警: Open Issue 超 10 个标橙色，超 20 个标红色
• 协调发版: 多个关联仓库需要同步发版时，一条命令搞定
• 可分享: HTML 文件可直接发给团队或部署到内部网站

运行

# 扫描组织下所有仓库
bash workflows/04-multi-repo-collab.sh --org 你的组织

# 只看指定仓库
bash workflows/04-multi-repo-collab.sh --org 你的组织 --repos "repo-a,repo-b,repo-c"

# 生成仪表盘 + 协调发版
bash workflows/04-multi-repo-collab.sh --org 你的组织 --release v2.0.0

# 自定义输出文件
bash workflows/04-multi-repo-collab.sh --org 你的组织 --output my-dashboard.html

# 示例
bash workflows/04-multi-repo-collab.sh --org zzx-coder

运行后在当前目录生成 dashboard.html，浏览器打开即可查看。

---

场景五：贡献者成长体系

脚本: 05-contributor-growth.sh

解决什么问题

开源项目需要激励贡献者持续参与，但很难量化每个人的贡献。这个工作流自动追踪贡献者活动，计算贡献分数，生成排行榜，并可选自动颁发成就徽章。

工作流程

contrib +report → 生成带 ECharts 饼图的 HTML 贡献报告
    ↓
issue +list → 统计 Issue 活动
pr +list → 统计 PR 活动
api GET /contributors → 获取提交数等 API 统计
    ↓
计算贡献分数 (AHP 权重模型):
  - PR 被合并: 10 分
  - 提交 PR: 5 分
  - 创建/解决 Issue: 3 分
  - 代码提交: 2 分
    ↓
评定等级:
  Champion (冠军)        >= 50 分
  Core Contributor       >= 30 分
  Active Contributor     >= 15 分
  Contributor            >= 5 分
  Newcomer (新人)        < 5 分
    ↓
（可选）issue +create → 自动创建徽章颁发 Issue
    ↓
wiki +create → 发布排行榜到 Wiki

串联的命令

步骤	命令	作用
1	contrib +report	生成 HTML 贡献报告（带 ECharts 图表）
2	issue +list	统计 open/closed Issue 活动
3	pr +list	统计 open/merged PR 活动
4	api GET /contributors	获取 API 级别的贡献者统计
5	issue +create	（可选）自动颁发成就徽章
6	wiki +create	发布排行榜到 Wiki

输出有什么用

• HTML 贡献报告: 可视化展示贡献分布，适合团队会议演示
• 贡献排行榜: 量化每个人的贡献，公开透明
• Wiki 排行榜: 永久保存，贡献者可随时查看排名
• 徽章激励: 通过 Issue 颁发徽章，增强成就感和归属感

运行

# 基本运行
bash workflows/05-contributor-growth.sh --owner 你的组织 --repo 你的仓库

# 自定义统计周期（默认 30 天）
bash workflows/05-contributor-growth.sh --owner 你的组织 --repo 你的仓库 --period 90

# 启用自动颁发徽章
bash workflows/05-contributor-growth.sh --owner 你的组织 --repo 你的仓库 --award

# 示例
bash workflows/05-contributor-growth.sh --owner zzx-coder --repo gitlink-cli --award

---

通用参数

参数	说明
--owner OWNER	仓库所属组织或用户（在 git 仓库内可自动检测）
--repo REPO	仓库名称（在 git 仓库内可自动检测）
--dry-run	预览模式，不实际执行写操作
--help	显示帮助信息

---

项目结构

workflows/
├── lib/
│   └── common.sh                  # 共享工具库（认证、JSON解析、CLI封装、日志）
├── 01-community-ops.sh            # 场景一：社区运营自动化
├── 02-code-quality-gatekeeper.sh  # 场景二：代码质量看门人（AI审查）
├── 03-project-init.sh             # 场景三：项目一键初始化
├── 04-multi-repo-collab.sh        # 场景四：多仓库协同
├── 05-contributor-growth.sh       # 场景五：贡献者成长体系
├── test.sh                        # 测试套件
└── README.md                      # 本文档

共享库 lib/common.sh

所有脚本共享的基础设施：

函数	作用
check_auth	检查认证状态（环境变量 或 CLI 登录）
gl_run	CLI 封装，自动追加 --format json
gl_check	CLI 封装 + JSON 格式校验 + ok 字段检查
json_ok / json_get / json_error	JSON 解析工具
detect_owner_repo	从 git remote 自动检测 owner/repo
log_step / log_ok / log_warn / log_err	彩色日志输出

---

涉及的 Skill

工作流通过加载 Skill 的审查方法论、分类规则和模板来指导 AI 分析：

Skill	被哪个场景使用	作用
gitlink-code-review	场景 2	已集成 — 加载审查维度、检查项、评分标准，指导 AI 代码审查
gitlink-issue-triage	场景 1	Issue 分类规则（关键词匹配、优先级判定）
gitlink-changelog	场景 1	Release Notes 生成模板（按类型分组、贡献者列表）
gitlink-health	场景 4	项目健康度评分体系（100 分制）
gitlink-onboard	场景 5	新人引导和 Issue 推荐规则
gitlink-workflow	全部	基础工作流编排（Issue 分类、PR 审查、发版、Sprint 报告）

场景 2 的 gitlink-code-review skill 已完整集成：脚本运行时自动从 skills/gitlink-code-review/SKILL.md 加载审查维度和检查项，传给 AI 作为审查方法论。其他场景使用关键词匹配等规则引擎。

---

测试

# 运行测试套件（使用真实 GitLink 仓库验证）
bash workflows/test.sh

# 指定仓库
bash workflows/test.sh zzx-coder gitlink-cli

测试覆盖：

• 认证状态检查
• CLI JSON 输出格式验证
• 数据字段提取（issue/PR/repo/release/member/contributor）
• PR 文件和 Diff 内容解析
• Issue/PR View 接口
• Wiki / Label 列表接口
• common.sh 工具函数
• 所有脚本语法校验