yetja
/
gitlink-cli
forked from chroe/gitlink-cli
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
gitlink-cli/skills/gitlink-workflow/SKILL.md

7.7 KiB
Raw Permalink Blame History

name version description metadata
gitlink-workflow 2.0.0 跨模块联动工作流：PR 全流程自动化、项目初始化向导、发版流程编排。当用户需要进行跨模块的复杂操作（从创建分支到合并 PR、从新建仓库到配置 CI）时触发。
requires cliHelp
bins
gitlink-cli
gitlink-cli --help

gitlink-workflow（跨模块联动工作流）

CRITICAL — 开始前必须先阅读 ../gitlink-shared/SKILL.md，其中包含认证、权限处理和 API 注意事项。 CRITICAL — 跨模块工作流涉及多个写入操作，每个阶段完成后展示结果，确认后再继续下一步。 CRITICAL — GitLink 操作只能用 gitlink-cli。禁止用 gh（GitHub CLI）操作 GitLink 资源。gh 仅适用于 GitHub 平台。

前置条件： 先阅读 ../gitlink-shared/SKILL.md 了解认证和全局参数。

概述

本 Skill 编排多个 gitlink-cli 模块，完成需要跨模块协作的端到端任务：

  1. PR 全流程：创建分支 → 提交代码 → 创建 PR → 代码审查 → 合并
  2. 项目初始化向导：创建仓库 → 设保护分支 → 创建 Issue → 配里程碑 → 开启 CI
  3. 发版流程：生成 Release Notes → 创建 Tag → 发布 Release → 关闭相关 Issue

对于专项任务（Issue 分拣、Release Notes 生成、健康度报告），请使用对应的专项 Skill：

工作流 1：PR 全流程

场景

从零开始，完成一个功能的开发和提交。

数据采集

# 1. 了解当前仓库状态
gitlink-cli repo +info --format json

# 2. 查看现有分支
gitlink-cli branch +list --format json

# 3. 查看已有 PR（避免冲突）
gitlink-cli pr +list --state open --format json

执行步骤

# Step 1: 创建功能分支
gitlink-cli branch +create --name feature/my-feature

# Step 2: 本地开发和推送（用原生 git）
git checkout -b feature/my-feature
# ... 编写代码 ...
git add -A
git commit -m "feat: 添加新功能"
git push origin feature/my-feature

# Step 3: 创建 PR
gitlink-cli pr +create \
  --head <username>:feature/my-feature \
  --base master \
  --title "feat: 添加新功能" \
  --body "## 变更说明
- 新增 XXX 功能
- 修改 YYY 逻辑

## 测试
- [ ] 单元测试通过
- [ ] 集成测试通过"

# Step 4: 查看 PR 状态
gitlink-cli pr +view --id <pr-id> --format json

# Step 5: 查看 PR 变更文件（Code Review）
gitlink-cli pr +files --id <pr-id> --format json

# Step 6: 合并 PR
gitlink-cli pr +merge --id <pr-id> --do merge

# Step 7: 清理本地分支（可选）
git checkout master
git branch -d feature/my-feature

AI 在 PR 流程中的角色

  1. 创建前检查：是否有冲突的现有 PR？分支名是否规范？
  2. Code Review：查看 pr +files 的变更，给出审查意见

    深度代码审查请使用 ../gitlink-review/SKILL.md（多视角 + 对抗式自检 + 自动评论）。

  3. 合并判断：检查 CI 是否通过（如开启了 DevOps）、是否有冲突

工作流 2：项目初始化向导

场景

创建一个新仓库并完成全套初始化配置。

执行步骤

# Step 1: 创建仓库
gitlink-cli repo +create --name <project-name> --description "<描述>"
# 可选：创建为私有仓库
gitlink-cli repo +create --name <project-name> --private true --description "<描述>"

# Step 2: 克隆到本地
gitlink-cli repo +clone --url <owner>/<project-name>
cd <project-name>

# Step 3: 创建初始文件
echo "# <project-name>" > README.md
echo "bin/\n*.exe\n.DS_Store" > .gitignore
git add -A && git commit -m "chore: 初始化项目"
git push origin master

# Step 4: 保护主分支
gitlink-cli branch +protect --name master

# Step 5: 创建初始 Issue（项目任务清单）
gitlink-cli issue +create \
  --title "项目初始化任务清单" \
  --body "## 初始化任务
- [ ] 完善 README 和项目文档
- [ ] 配置 CI/CD 流水线
- [ ] 添加单元测试框架
- [ ] 设置代码规范检查
- [ ] 创建贡献指南"

# Step 6: 创建里程碑
gitlink-cli milestone +create \
  --title "v0.1.0 - MVP" \
  --description "首个可用版本"

# Step 7: 创建开发分支
gitlink-cli branch +create --name develop

# Step 8: 开启 DevOps（可选）
gitlink-cli api POST /<owner>/<project-name>/activate

工作流 3：发版流程编排

场景

从当前开发状态创建一个正式版本发布。

执行步骤

# Step 1: 确认当前版本状态
gitlink-cli release +list --format json

# Step 2: 使用 changelog skill 生成 Release Notes
# 参见 ../gitlink-changelog/SKILL.md

# Step 3: 创建 Git Tag
git tag -a v1.0.0 -m "v1.0.0 正式发布"
git push origin v1.0.0

# Step 4: 创建 Release
gitlink-cli release +create \
  --tag v1.0.0 \
  --name "v1.0.0 正式版" \
  --body "<从 changelog skill 生成的 Release Notes>"

# Step 5: 关闭已完成的 Issue
gitlink-cli issue +close --number <已完成issue编号>

# Step 6: 创建下一个版本的里程碑
gitlink-cli milestone +create \
  --title "v1.1.0" \
  --description "下一版本计划"

工作流 4：跨仓库同步检查

场景

检查 Fork 仓库是否落后于上游，需要同步。

数据采集

# 1. 遍历自己的 Fork 仓库
gitlink-cli repo +list --category fork --format json

# 2. 对每个 Fork，查看上游信息
gitlink-cli repo +info --owner <owner> --repo <repo> --format json
# 关注: forked_from_project_id, fork_info

# 3. 获取上游仓库的最新提交
gitlink-cli commit +list --owner <upstream-owner> --repo <upstream-repo> --format json

AI 分析

检查项 方法
Fork 是否落后 比较 Fork 和上游的最新 commit 时间戳
是否有本地修改 检查 Fork 仓库是否有非上游的 commit
同步建议 落后 > 30 天或有冲突风险时提醒

输出格式

PR 流程状态摘要

## 🔀 PR 全流程状态

| 阶段 | 状态 | 详情 |
|------|------|------|
| 分支创建 | ✅ | feature/my-feature 已创建 |
| 代码提交 | ✅ | 3 个 commit 已推送 |
| PR 创建 | ✅ | PR #15: "feat: 添加新功能" |
| Code Review | 🔍 | 待审查（变更 5 个文件，+120/-30） |
| CI 检查 | ⏳ | 构建中... |
| 合并 | ⏳ | 等待 Review 通过 |

项目初始化完成摘要

## 🚀 项目初始化完成 — <project-name>

| 配置项 | 状态 |
|--------|------|
| 仓库 | ✅ <owner>/<project-name> (公开) |
| 主分支保护 | ✅ master 已保护 |
| 初始 Issue | ✅ #1: "项目初始化任务清单" |
| 里程碑 | ✅ v0.1.0 - MVP |
| 开发分支 | ✅ develop |
| DevOps | ⚠️ 待开启 |
| README | ✅ 已创建 |
| .gitignore | ✅ 已创建 |

### 下一步
1. 在 GitLink Web 页面开启 DevOps
2. 配置 `.devops/` 流水线
3. 邀请团队成员
4. 开始认领 Issue #1 中的任务

最佳实践

  • 分阶段确认：跨模块工作流较长，每个关键步骤完成后展示结果
  • 错误即停：任何步骤失败都应暂停，排查后再继续
  • Fork 流程优先：向他人仓库提 PR 时，必须先 Fork
  • 分支命名规范：feature/xxx、fix/xxx、docs/xxx
  • PR 描述完整：包含变更说明、测试情况、关联 Issue

详细参考

详见 REFERENCE.md 了解跨模块 API 字段映射、Fork 工作流细节和分支命名规范。