name: workflow-orchestration description: 通过链接autonomous-ci、code-review、smart-commit和jules-integration插件来协调多步骤CI/CD流水线。在执行验证到PR的工作流或从CI故障中恢复时使用。
技能: workflow-orchestration
概述
该技能通过将现有插件链接成流水线来编排复杂的工作流。 它通过CHANGELOG.md保持状态感知，并协调跨插件操作。
使用时机
- 提交前验证: 在任何提交之前，确保所有质量门通过
- PR创建: 当变更准备好进行评审和PR创建时
- CI恢复: 当CI失败且需要自动化诊断/修复时
- 多步骤自动化: 任何需要协调插件执行的任务
前提条件
必需插件:
autonomous-ci- 验证和CI监控code-review- 质量分析smart-commit- 提交消息生成
可选插件:
jules-integration- 异步PR委托
必需技能(来自超能力):
systematic-debugging- 用于故障分析verification-before-completion- 用于基于证据的完成
流程
阶段1: 上下文收集
在执行任何流水线之前:
# 1. 读取CHANGELOG获取最近上下文
读取文件: CHANGELOG.md
# 关注[Unreleased]部分以了解待处理工作
# 2. 检查git状态
git status --porcelain
git log --oneline -5
# 3. 验证所需插件是否可用
claude plugin list
阶段2: 流水线选择
根据任务选择合适的流水线:
| 任务 | 流水线 | 使用的插件 |
|---|---|---|
| 提交前验证 | pre-commit |
autonomous-ci, code-review, smart-commit |
| 创建PR | pr-create |
所有 + jules-integration |
| 修复CI故障 | ci-recover |
autonomous-ci + systematic-debugging |
阶段3: 流水线执行
提交前流水线
步骤1: 验证
├── 运行: ./tooling/scripts/local-validate.sh
├── 成功时: 继续
└── 失败时: 停止，报告问题
步骤2: 评审
├── 调用: code-review技能
├── 分析: 安全性、风格、性能
├── 成功时: 继续
└── 失败时: 报告问题，建议修复
步骤3: 提交消息
├── 调用: smart-commit技能
├── 生成: 约定式提交消息
├── 成功时: 呈现消息供人工批准
└── 失败时: 提供手动模板
PR创建流水线
步骤1: 提交前流水线
├── 执行完整提交前流水线
└── 失败时: 停止
步骤2: 暂存变更
├── 呈现差异供人工评审
├── 要求: 人工批准git提交
└── 批准时: 继续
步骤3: 委托给Jules
├── 调用: jules-integration技能
├── 创建: 带有PR任务的Jules会话
├── 设置: requirePlanApproval = true
└── 监控: 会话状态
CI恢复流水线
步骤1: 诊断
├── 调用: systematic-debugging技能
├── 分析: CI故障日志
├── 识别: 根本原因
└── 失败时: 上报给人工
步骤2: 修复
├── 基于诊断实施修复
├── 如果添加代码则遵循TDD
└── 失败时: 带上下文上报
步骤3: 重新验证
├── 运行: ./tooling/scripts/local-validate.sh
├── 成功时: 报告恢复
├── 失败时: 重试(最多3次)
└── 达到最大重试次数时: 上报
阶段4: 完成
在声明完成前始终验证:
# 运行验证
./tooling/scripts/local-validate.sh
# 检查所有测试通过
# (如果适用)
# 在[Unreleased]下更新CHANGELOG.md
提供证据报告:
## 流水线执行摘要
| 步骤 | 状态 | 证据 |
|------|--------|----------|
| 验证 | ✅ | local-validate.sh通过 |
| 评审 | ✅ | 无关键问题 |
| 提交 | ⏳ | 等待人工批准 |
### 工件
- 提交消息: `feat: add workflow orchestration`
- 更改的文件: 5
- 行数: +230 / -12
状态管理
编排器从多个源读取状态:
CHANGELOG.md
# 提取待处理工作
grep -A 50 "\[Unreleased\]" CHANGELOG.md
提供:
- 已添加/更改/修复的内容
- 待处理的内容
- 最近的决策和上下文
Git状态
git status --porcelain # 工作目录状态
git log --oneline -5 # 最近提交
git diff --stat # 变更摘要
CI状态
# 通过autonomous-ci技能
./plugins/autonomous-ci/scripts/wait-for-ci.sh
错误处理
验证失败
- 解析错误输出
- 识别失败的检查(shellcheck、markdownlint、插件验证)
- 如果确定则尝试自动修复
- 重新运行验证
- 如果3次尝试后仍然失败，提供完整上下文报告
评审失败
- 收集所有评审问题
- 按严重性分类(关键、警告、信息)
- 对于关键问题: 停止并报告
- 对于警告: 报告并在人工确认后继续
Jules API失败
- 检查API密钥有效性
- 使用指数退避重试(5秒、15秒、30秒)
- 如果持续失败，报告并建议手动创建PR
与其他技能的集成
来自超能力
| 技能 | 使用时机 |
|---|---|
systematic-debugging |
CI故障诊断 |
test-driven-development |
编写修复 |
verification-before-completion |
在声明完成前 |
brainstorming |
复杂的架构决策 |
来自此仓库
| 技能 | 使用时机 |
|---|---|
autonomous-ci |
验证和监控 |
code-review |
质量分析 |
smart-commit |
提交生成 |
jules-integration |
PR委托 |
working-on-ancplua-plugins |
仓库约定 |
示例
示例1: 提交前流程
触发: 开发人员在提交前请求验证
1. 读取CHANGELOG.md → 理解上下文
2. 运行local-validate.sh → 所有检查通过
3. 调用code-review → 无关键问题
4. 调用smart-commit → 生成: "feat(agent): add workflow orchestrator"
5. 呈现摘要 → 人工批准
6. 提供证据报告完成
示例2: CI恢复
触发: CI在shellcheck上失败
1. 通过autonomous-ci监控检测到故障
2. 调用systematic-debugging:
- 阶段1: 收集证据(CI日志)
- 阶段2: 识别原因(SC2086未引用的变量)
- 阶段3: 假设修复(添加引号)
- 阶段4: 本地验证修复
3. 将修复应用到脚本
4. 运行local-validate.sh → 通过
5. 提供证据报告恢复
示例3: 完整PR流水线
触发: 功能完成，准备评审
1. 执行提交前流水线 → 全部通过
2. 呈现差异供人工评审
3. 人工批准提交
4. 调用jules-integration:
- 创建会话: "为workflow-orchestrator代理创建PR"
- 设置requirePlanApproval: true
- 监控会话
5. 创建时报告PR URL
Claude的维护规则
- 永不跳过验证 - 在完成前始终运行local-validate.sh
- 始终先读取CHANGELOG - 上下文防止重复工作
- 链接技能，不要重新发明 - 使用现有插件而不是自定义逻辑
- 要求人工批准提交 - 编排 ≠ 自主提交
- 提供证据报告 - 带有状态和工件的表格
- 更新CHANGELOG - 每次更改文件的流水线执行