# workflow-hub — reference

## 技能目录与文件角色

| 技能目录 | SKILL.md | reference.md |
|----------|----------|--------------|
| workflow-hub | 调度顺序与门禁总览 | 本文档（补充说明） |
| geelib-task-flow | 兼容入口（已并入 workflow-hub） | 迁移说明（指向 workflow-hub） |
| dev-task-flow | 开发四阶段与完成态闸门 | 硬规则全文、Query/POST/上报模板、Preflight |
| self-test-flow | 自测五阶段与输出闸门 | 联调步骤、校验、报告结构细则 |
| deploy-test-env | 提交与测试环境部署：审阅→同步→单测(按需)→提交→push 同名分支→local_build.sh | 命令细节、与 self-test 区分说明 |

## 决策树（简版）

**说明**：下列 1～4 步用于**单意图**下「先进入哪个技能」的分派；若用户**同时**要开发与部署，**实际执行顺序**以 **workflow-hub/SKILL.md** 技能链为准：**开发 → 联调自测 → 提交部署**，不得颠倒。

1. 用户消息是否包含 GeeLib / geelib URL / matterType / subId？  
   - 是 → 从 **workflow-hub（GeeLib阶段）** 开始；若**同条消息**还包含「提交代码 / 部署测试环境 / 发测试」等（与 **deploy-test-env** 激活词一致），在完成 **self-test-flow**（或零代码场景下与交付对齐）后**追加** **deploy-test-env**，再回到 **workflow-hub（GeeLib收尾）**。  
   - 否 → 2。

2. 是否明确要求「提交代码」或「更新/部署测试环境」等（且无 GeeLib 闭环）？  
   - 是 → **deploy-test-env**。  
   - 否 → 3。

3. 是否「自测」「自测流程」或纯联调验证（用户未要求同时开发新功能）？  
   - 是 → **self-test-flow**。  
   - 否 → 4。

4. 是否开发/实现/修接口或模块？  
   - 是 → **dev-task-flow**（其阶段 3 再拉 **self-test-flow**）。  
   - 否 → 按用户具体指令处理，或请用户澄清场景。

## 触发稳定性建议（workflow-hub 配套）

- 采用“**优先级首个命中**”策略，避免同条消息触发多个入口导致摇摆。
- 为每条规则维护「命中词 / 排除词 / 降级关系」三元组；新增技能时先补这三项再上线。
- workflow-hub 同时承载 GeeLib 闭环步骤；其余开发/自测/提交步骤下沉到子技能。
- 每次分派输出回执：命中规则、命中词、已加载技能路径、当前链路、阶段状态。

## 回归样例（建议每次改 hub 后跑一遍）

| 输入示例 | 期望命中 | 期望技能链 |
|----------|----------|------------|
| 部署测试环境 / 更新测试环境 / 提交代码 | B | deploy-test-env |
| 帮我实现一个接口并自测 | C | dev-task-flow -> self-test-flow |
| 我只想做联调自测，不改代码 | D | self-test-flow |
| 打开 geelib.qihoo.net 拉一个 matterType 任务 | A | workflow-hub(GeeLib阶段) |
| 从 GeeLib 拉任务，修 bug 后回写状态 | A | workflow-hub(GeeLib阶段) -> dev-task-flow -> self-test-flow -> workflow-hub(GeeLib收尾) |
| GeeLib 闭环且同轮要求部署测试环境 / 提交代码 | A | workflow-hub(GeeLib阶段) -> dev-task-flow -> self-test-flow -> deploy-test-env -> workflow-hub(GeeLib收尾) |
| 我想优化下流程（未说明具体任务） | E | 先澄清，再分派 |

## 与 deploy-test-env 的关系

- **deploy-test-env**：审阅 → `fetch`/`pull` → 用户要求时 `go test` → 提交 → 推送 `origin` 同名分支 → `local_build.sh`（镜像构建与推送）；细则见 **deploy-test-env/SKILL.md**。
- **deploy-test-env** 内的 `go test` 与 **self-test-flow** 联调报告分离；要联调证据时走 **self-test-flow**。
- **dev-task-flow** 完成态不要求必须先走 **deploy-test-env**；用户单说「提交代码」或「部署测试环境」时走 **deploy-test-env**。**GeeLib 规则 A** 且同轮含提交/部署诉求时，在 **self-test-flow** 之后串联 **deploy-test-env** 再 GeeLib 收尾。

## GeeLib 执行位置

- GeeLib 浏览器操作（拉任务/读详情/改状态）统一在 **workflow-hub** 内执行。  
- 从需求梳理/编码开始切到 **dev-task-flow**；联调自测走 **self-test-flow**。  
- 完成后回到 **workflow-hub** 做 GeeLib 收尾回写；若用户还要求提交/部署测试环境，则在收尾前按上节串联 **deploy-test-env**。

## 维护说明

- 新增技能时：在本 reference 的表格与决策树中增加一行；在 **workflow-hub/SKILL.md** 的调度表中增加对应行或脚注。
