Agent Skills: Skill: Workflow

|

UncategorizedID: protagonistss/ithinku-plugins/workflow

Install this agent skill to your local

pnpm dlx add-skill https://github.com/Protagonistss/ithinku-plugins/tree/HEAD/plugins/git-tools/skills/workflow

Skill Files

Browse the full folder contents for workflow.

Download Skill

Loading file tree…

plugins/git-tools/skills/workflow/SKILL.md

Skill Metadata

Name
workflow
Description
|

Skill: Workflow

团队工作流管理技能 - 协作规范、自动化流程和最佳实践。

核心功能

  • 🏗️ 工作流模板 - GitFlow、GitHub Flow、Trunk Based
  • 👥 代码审查 - 自动分配审查者和跟踪状态
  • 🚀 发布管理 - 版本控制和自动化发布流程
  • 📋 团队规范 - 提交规范、分支保护执行
  • 🔗 工具集成 - JIRA、Slack、GitHub/GitLab

快速使用

# 初始化工作流
/workflow init --template gitflow

# 创建功能分支
/workflow start-feature PROJ-123 "用户认证"

# 分配代码审查
/workflow assign-review

# 发布版本
/workflow release --type minor

工作流模板

GitFlow(适合有发布周期的团队)

main (生产)
  └── develop (开发)
        ├── feature/* → 开发完成后合并到 develop
        ├── release/* → 从 develop 创建,测试后合并到 main
        └── hotfix/* → 从 main 创建,修复后合并到 main 和 develop

初始化命令

/workflow init --template gitflow
# 创建:main, develop 分支
# 配置:分支保护规则

GitHub Flow(适合持续部署)

main (始终可部署)
  └── feature/* → 开发完成后创建 PR 合并到 main

初始化命令

/workflow init --template github-flow
# 配置:PR 模板、CI/CD

Trunk Based(适合高频发布)

main (主干)
  └── short-lived/* → 短期分支(<1天),快速合并

功能开发流程

开始新功能

# 创建功能分支(自动命名)
/workflow start-feature PROJ-123 "用户认证"

# 等同于
git checkout develop
git pull origin develop
git checkout -b feature/PROJ-123-user-auth

功能完成流程

  1. 代码自审 - 检查代码质量和规范
  2. 提交变更 - 使用规范的 commit message
  3. 创建 PR/MR - 填写完整的描述
  4. 请求审查 - 自动分配审查者
  5. 处理反馈 - 修改并回复评论
  6. 合并代码 - Squash 或保留提交历史

代码审查

自动分配审查者

# 基于代码所有权分配
/workflow assign-review --strategy codeowners

# 基于负载均衡分配
/workflow assign-review --strategy balanced

# 随机分配(排除作者)
/workflow assign-review --strategy random

审查检查清单

  • [ ] 代码功能正确
  • [ ] 有足够的测试覆盖
  • [ ] 遵循编码规范
  • [ ] 无安全漏洞
  • [ ] 文档已更新
  • [ ] 提交信息清晰

审查状态跟踪

# 查看待审查列表
/workflow review-status --pending

# 查看我的审查任务
/workflow review-status --mine

版本发布

语义化版本

  • MAJOR (主版本) - 不兼容的 API 变更
  • MINOR (次版本) - 向后兼容的功能新增
  • PATCH (补丁版本) - 向后兼容的问题修复

发布流程

# 创建发布分支
/workflow release --type minor --version 2.1.0

# 执行步骤:
# 1. 从 develop 创建 release/2.1.0
# 2. 更新版本号
# 3. 更新 CHANGELOG
# 4. 测试和修复
# 5. 合并到 main 并打标签
# 6. 合并回 develop
# 7. 推送到远程

自动化发布

{
  "release": {
    "autoChangelog": true,
    "autoTag": true,
    "notifySlack": true,
    "environments": ["staging", "production"]
  }
}

工具集成

JIRA 集成

# 关联分支到 JIRA 工单
/workflow link-jira PROJ-123

# 自动更新工单状态
# feature 开始 → In Progress
# PR 创建 → In Review
# 合并完成 → Done

Slack 集成

# 配置通知
/workflow config-slack --channel "#dev-notifications"

# 触发通知的事件:
# - 新 PR 创建
# - 审查请求
# - 合并完成
# - 发布开始/完成

配置

{
  "workflow": {
    "template": "gitflow",
    "autoReview": true,
    "autoRelease": false,
    "integrations": ["slack", "jira"],
    "branchProtection": {
      "main": { "requiredReviews": 2, "requiredStatusChecks": ["ci"] },
      "develop": { "requiredReviews": 1 }
    }
  }
}

最佳实践

✅ 推荐做法

  • 保持功能分支简短(< 3天)
  • 及时响应代码审查请求
  • 发布前进行充分测试
  • 保持 CHANGELOG 更新

❌ 避免做法

  • 跳过代码审查直接合并
  • 长期存在的功能分支
  • 不关联工单的提交
  • 在发布分支上开发新功能

详细信息