@auto-ai/agent 2.1.142 → 2.1.144

package/skills-runtime/dev-task-flow/reference.md

@@ -0,0 +1,158 @@
+# dev-task-flow — reference
+
+## Scope
+- 适用于日常功能开发与接口实现，不替代「提交代码 / 部署测试环境」流程（**deploy-test-env**）。
+- 本技能默认包含：技术文档、代码实现、自测、自测报告检查、开发报告。
+- 若用户明确要求跳过某阶段，按用户要求执行并在结果中注明风险。
+
+## Hard Rules
+- 按顺序执行，失败即停：前置阶段未完成，不进入下一阶段。
+- 不使用破坏性 git 命令；不改动与当前需求无关的文件。
+- 启动服务前先检查已有终端，避免重复拉起进程。
+- 每个实现步骤都要有可验证结果（日志、响应、数据库查询结果等）。
+- 不提交敏感文件（如 `.env`、`*.pem`、`*.key`、`credentials.json`）。
+- Request 结构强约束：所有 HTTP 接口请求结构必须继承 `BaseHttpRequest`（查询类可在其上扩展 `BaseHttpListRequest` 能力），禁止手写散乱字段解析。
+- 查询接口强约束：凡是 Query/List 类接口，必须严格按「1.1 查询类接口实现模板」编码，不得跳步或替换实现范式。
+- 禁止绕开模板：不允许「手工解析 filter + 直接查库 + 手工拼装返回」替代统一查询模板，除非用户明确批准偏离模板。
+- 若发现历史代码未按模板实现：本次改动范围内需优先重构到模板形态，再继续新增需求。
+- 文件拆分强约束：新增独立功能域（如 license、billing、audit）时，必须新建独立 service 文件（如 `license_service.go`），禁止继续堆叠到已有大文件（如 `tenant_service.go`），除非用户明确要求复用原文件。
+- 路由注解同步强约束：新建 service 文件后，必须同步更新注解收集逻辑（如 `go:embed` + `ExtractRouteAnnotationsFromString`）确保新增接口被自动注册；未完成注册校验不得进入下一阶段。
+- 文档策略：默认按用户诉求执行，**非明确要求不强制产出文档文件**；当任务或用户要求文档时，需在仓库中落盘并给出路径。
+- 完成态闸门：默认以「需求梳理 + 代码实现 + 编译检查」为完成条件；若任务包含文档交付，再将文档作为强制项。
+
+## Preflight Checklist（执行前自检）
+- 是否已在内部记录当前技能（可选 `[SKILL:dev-task-flow]` 标记）：是/否。
+- 是否匹配「开发/实现/完善接口或模块」任务：是/否。
+- 是否按 Workflow 顺序执行：是/否。
+- 若包含 Query/List 接口：是否满足「1.1 模板强约束」（参数处理、SQL查询、数据渲染三段完整且可验证）：是/否。
+
+## Workflow（详细）
+
+### 1）梳理需求（按需输出技术方案）
+- 将需求拆成：输入、处理、输出、边界条件、错误场景。
+- 当任务明确要求文档时，技术文档分两部分：
+  - **设计文档**：设计思路、数据库设计、流程图。
+  - **接口文档**：接口路径/方法、请求参数、响应结构、错误码、示例。
+- 文档落地要求（按需）：
+- 按当前项目规划选择实现模板（见下文 1.1 / 1.2 / 1.3）。
+
+#### 1.1 查询类接口实现模板
+- 参考项目：`code/host/sdmgrvirus`（按项目现有结构对齐）。
+- 固定步骤：
+  1. 参数处理（必填校验、类型转换、默认值、分页排序）。
+  2. SQL 编写查询（过滤条件、分页、排序、总数统计）。
+  3. 返回数据渲染（字段映射、脱敏/格式化、统一响应结构）。
+- Request 模板（强制）：
+  1. 定义请求结构时必须以 `BaseHttpRequest` 为基类。
+  2. Query/List 请求必须具备统一过滤能力（`filter/search/date`、分页、排序），不得绕过基类能力。
+  3. 业务字段只允许作为基类扩展字段追加，不允许替代基类字段。
+- 代码模板（可直接复用）：
+```go
+type QueryXXXRequest struct {
+	query.BaseHttpListRequest
+	// 业务扩展字段（按需）
+	Pcid string `json:"pcid" form:"pcid"`
+}
+
+// @route GET /module/xxx/query
+func (s XxxService) QueryXXX(req *QueryXXXRequest) (any, error) {
+	if req == nil {
+		return []map[string]any{}, nil
+	}
+	if strings.TrimSpace(req.Pcid) == "" {
+		return common.Response{Errno: 1, Errmsg: "pcid不能为空", Timestamp: time.Now().Unix()}, nil
+	}
+
+	req.SetDbType(query.DB_TYPE_MYSQL)
+	req.BaseFilter("tid", query.EQFilter("tid"))
+	req.BaseFilter("tids", query.INFilter("tid"))
+	req.Operator(query.EQUAL, "saas", "model_name")
+
+	rows, err := req.Query("select tid,data from settings", "")
+	if err != nil {
+		return nil, err
+	}
+	return rows, nil
+}
+```
+- 严格落地要求：
+  1. 过滤条件必须优先接入项目统一过滤器机制（如 `BaseHttpListRequest`、`BaseFilter`、`INFilter`、`EQFilter`）。
+  2. 查询执行与渲染加工必须解耦：先得到标准查询结果，再做字段映射/补充。
+  3. 默认要求可分页且可统计总数；若业务明确不需要总数，需在实现说明中写明理由。
+  4. 返回格式与错误处理必须复用项目统一响应风格，禁止自定义散乱结构。
+- 反例（禁止）：
+  - 仅通过 `json.Unmarshal(req.Filter)` 手工取 `tids` 后直接 `db.Table(...).Find(...)`，且未接入统一过滤器。
+  - 在单个方法中混合参数解析、过滤组装、SQL 执行、复杂渲染且无模板分层。
+
+#### 1.2 POST 表单提交类接口实现模板
+- 固定步骤：
+  1. 参数绑定与校验（必填、长度、枚举、格式）。
+  2. 业务处理（去重/幂等、状态流转、事务边界）。
+  3. 数据写入（MySQL/ClickHouse 或其他存储）。
+  4. 返回提交结果（成功标识、主键/业务 ID、失败原因）。
+- Request 模板（强制）：
+  1. POST 请求结构必须继承 `BaseHttpRequest`。
+  2. 参数校验必须在 Service 入口统一进行，不允许在多处重复解析 `map[string]any`。
+  3. 校验失败统一走项目响应结构，不允许返回非标准错误体。
+- 代码模板（可直接复用）：
+```go
+type SubmitXXXRequest struct {
+	query.BaseHttpRequest
+	Tid                string `json:"tid" form:"tid"`
+	Pcid               string `json:"pcid" form:"pcid"`
+	AuthorizeTimestamp int64  `json:"authorize_timestamp" form:"authorize_timestamp"`
+}
+
+// @route POST /module/xxx/submit
+func (s XxxService) SubmitXXX(req *SubmitXXXRequest) (any, error) {
+	tid := strings.TrimSpace(req.Tid)
+	pcid := strings.TrimSpace(req.Pcid)
+	if tid == "" {
+		return common.Response{Errno: 1, Errmsg: "tid不能为空", Timestamp: time.Now().Unix()}, nil
+	}
+	if pcid == "" {
+		return common.Response{Errno: 1, Errmsg: "pcid不能为空", Timestamp: time.Now().Unix()}, nil
+	}
+	if req.AuthorizeTimestamp <= 0 {
+		return common.Response{Errno: 1, Errmsg: "authorize_timestamp不能为空", Timestamp: time.Now().Unix()}, nil
+	}
+
+	// 业务处理 + 落库
+	return common.SuccessResponse("success", nil), nil
+}
+```
+
+#### 1.3 客户端上报类 workflow 实现模板
+- 固定步骤：
+  1. 定义上报消息结构与校验规则。
+  2. 接入上报入口（通常 NSQ/消息队列）并消费处理。
+  3. 数据清洗与标准化（时间、字段、枚举映射）。
+  4. 落库（常见为 ClickHouse，也可按现有链路写入 MySQL/CH）。
+  5. 提供查询/校验路径（HTTP 查询接口或 DB 校验语句）。
+
+### 2）开始编写代码和检查
+- 按第 1 步确定的模板编码，优先复用项目现有模式与公共组件。
+- 对新增功能域先做文件边界决策：优先新建独立 service 文件并控制单文件复杂度，避免无边界扩展历史文件。
+- 编码后至少完成编译检查（保证改动范围可编译）。
+- 对关键分支补充必要的错误处理与日志，保证问题可定位。
+- 检查点：参数校验完整、SQL 条件正确、返回字段与接口文档一致。
+
+### 3）检查编译错误和review代码
+- go build ./...。
+- Lint检查。
+
+## Output Contract
+- 每个阶段输出 `PASS` 或 `FAIL`。
+- 若 `FAIL`，必须包含：
+  - 失败步骤
+  - 关键错误现象
+  - 已确认原因/待确认点
+  - 下一步动作
+- 全部成功时，至少输出：
+  - 实现模板类型（查询类 / POST / 客户端上报）
+  - 已完成文档列表（如本次任务要求：设计文档、接口文档、测试文档、开发报告）
+  - 自测结论摘要
+- 交付清单强制项（缺一不可）：
+  - 代码改动文件路径
+  - 编译/测试结果
+  - 若任务要求文档：对应文档文件路径

package/skills-runtime/self-test-flow/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: self-test-flow
+description: 当用户输入「自测」「自测流程」或要求按联调方式验证模块时使用。梳理接口、写测试步骤文档、启进程、按 CRUD 等步骤执行并校验（NSQ/HTTP、MySQL/ClickHouse），输出带模拟数据与校验过程的测试报告。
+---
+
+# Self-Test Flow（自测流程）
+
+## Activation
+- 用户消息含「自测」「自测流程」，或明确要求按联调/接口方式验证模块时应用本技能。
+- **命中词（任一）**：自测 / 自测流程 / 联调验证 / 接口联调 / 验证模块。
+- **排除词（任一）**：提交代码（且无联调诉求）。
+- **冲突降级**：若同条消息含开发诉求，入口由 `workflow-hub` 先分配到 `dev-task-flow`，本技能作为其阶段 3 子流程执行；若含 GeeLib 闭环语义，先进入 `geelib-task-flow`。
+- 激活后首行输出：`[SKILL:self-test-flow]`。
+
+## 门禁
+- **失败即停**：本步未 PASS 则不得将依赖其结果的后继标为 PASS（除非用户要求继续探测）。
+- **非单元测试**：不默认编写或修改 `*_test.go`；不未经用户同意改业务代码。
+- **环境不可达则停**：中间件/网络阻塞时说明原因，不空转。
+- **每步必校验**：HTTP/NSQ 执行后须含落库一致性校验证据，否则该步 **FAIL**。
+- **启动前**：检查已有终端，避免重复拉起相同服务。
+
+## 阶段（顺序执行）
+
+| 阶段 | 内容 | 通过条件 |
+|------|------|----------|
+| 1 | 梳理接口/Topic，写可执行测试文档 | 文档含 CRUD 顺序与存储类型（MySQL/CH/缓存） |
+| 2 | 启动进程与依赖 | 端口与配置与文档一致，有记录 |
+| 3 | 按文档逐步执行 | HTTP/NSQ 操作与文档一致 |
+| 4 | 每步即时校验 | 状态码/响应/库表与模拟数据一致；有查询依据 |
+| 5 | 输出测试报告 | 逐步 PASS/FAIL + 总览 |
+
+## 输出约定
+- 每大步 `PASS` / `FAIL`；`PASS` 须含库表校验证据。
+- **步骤写法、NSQ/HTTP 细则、报告结构**：同目录 **`reference.md`**。
+
+## 执行回执（每次进入本技能都要输出）
+- `已命中技能`：self-test-flow
+- `命中关键词`：列出触发词
+- `已加载文档`：`.cursor/skills/self-test-flow/SKILL.md`、`.cursor/skills/self-test-flow/reference.md`
+- `阶段状态`：阶段 1/2/3/4/5 的已完成、进行中、待执行

package/skills-runtime/self-test-flow/reference.md

@@ -0,0 +1,56 @@
+# self-test-flow — reference
+
+## Scope
+- 面向接口与数据链路的联调自测（非替代 `go test ./...` 单元测试）。
+- 不默认编写或修改 `*_test.go`；不未经用户同意改动业务代码。
+- 依赖不可达（中间件/库/网络）或环境阻塞时停止并说明原因，不空转等待。
+
+## Hard Rules（展开）
+- 失败即停：某步骤校验不通过则记录现象，不强行执行后续依赖该结果的步骤（除非用户要求继续探测）。
+- 启动进程前检查已有终端，避免重复拉起相同服务。
+- 模拟数据需可复现：记录 topic/URL、请求体、关键 header、时间范围等。
+- 区分数据入口：**NSQ 消费**（客户端上报类 → 常落 ClickHouse）；**HTTP**（多为查 MySQL/ClickHouse，或写 MySQL/ClickHouse）。步骤设计须与真实路径一致。
+- 每步完成后必须做**结果校验**（HTTP 响应、DB/CH 查询行数与字段、NSQ 消费日志或下游表数据等）。
+- 每个接口或 NSQ 消息执行后，必须做**数据库一致性校验**（MySQL/ClickHouse 至少其一，按真实落库路径选择），并与该步模拟数据逐字段比对；未完成该校验或比对不一致，**该步骤一律判定 FAIL**。
+
+## Workflow（详细）
+
+### 1）梳理接口测试方式
+- 列出本次要测的接口或消息：HTTP 路径与方法、NSQ topic（及期望消费者）。
+- 将测试文档写为可执行步骤列表；默认按**整套 CRUD 逻辑**组织，例如：
+  1. 插入/创建数据  
+  2. 查询验证  
+  3. 修改/更新  
+  4. 再次查询验证  
+  5. 删除（若适用）  
+  6. 最终状态校验  
+- 文档中注明每步对应的存储：**MySQL / ClickHouse / 仅缓存**等，便于选对校验方式。
+
+### 2）启动进程
+- 按项目约定启动被测服务（及依赖：NSQ、MySQL、ClickHouse 等）；确认监听端口与配置与测试文档一致。
+- 记录启动命令与关键配置来源（如配置文件路径、环境变量名，不写敏感值）。
+
+### 3）开始测试
+- 严格按步骤顺序操作：发 HTTP、或向 NSQ 生产消息、或调用既有工具脚本。
+- **NSQ 路径**：模拟客户端上报 payload → 等待消费完成（合理超时 + 重试快照）→ 再查 ClickHouse（或文档指定的落库）。
+- **HTTP 路径**：模拟查询/写入请求；若接口写 MySQL 或 ClickHouse，后续步骤用查询接口或直接查库校验（以项目可接受方式为准）。
+
+### 4）每步校验
+- 每步结束后立即校验：**状态码/错误码、响应体关键字段、数据库或 ClickHouse 中记录是否与输入一致**（含时间字段、枚举、关联 ID）。
+- 记录**本步输入（模拟数据）**与**校验依据**（例如执行的 SQL/CH 查询条件、期望行数或字段快照）。
+- 强制要求：无论 HTTP 还是 NSQ，均需提供可复现的 SQL/CH 查询语句（或等价查询条件）与查询结果摘要，证明落库数据与模拟数据一致后方可标记 PASS。
+- 若与预期不符：保留请求/消息原文、响应或查询结果摘要、相关日志片段（脱敏）。
+
+### 5）输出测试报告
+- 使用结构化小节，**逐步**对应测试文档，每步至少包含：
+  - **步骤编号与名称**  
+  - **模拟数据**（完整可复现：URL、方法、body、topic、消息体等）  
+  - **执行结果**（成功/失败）  
+  - **校验过程**（查了哪里、期望什么、实际什么）  
+  - **结论**（PASS / FAIL）  
+- 文末给出**总览**：通过步骤数/总步骤数、未通过项与阻塞原因、建议下一步（修代码/补数据/改配置）。
+
+## Output Contract
+- 每个大步骤汇报 `PASS` 或 `FAIL`；`FAIL` 须含：操作内容、错误现象、与预期差异、建议定位方向。
+- `PASS` 前置条件：必须包含数据库一致性校验证据（查询条件/SQL、关键结果、与模拟数据逐字段对照结论）；缺一不可。
+- 完整成功时额外给出：服务启动确认、测试覆盖的接口/Topic 列表、报告已按上节结构输出。

package/skills-runtime/workflow-hub/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: workflow-hub
+description: >-
+  GeeLib任务管理，当用户要求执行GeeLib时使用此技能并按照调度顺序完成任务。
+---
+
+# Workflow Hub（技能调度）
+
+## Activation
+- 用户问「技能顺序」「先走哪个 SKILL」「流程编排」「多文件 SKILL 怎么用」时应用本技能。
+- 用户消息命中 GeeLib 语义（`GeeLib` / `geelib.qihoo.net` / `matterType` / `subId` / 拉任务 / 改状态）时，**默认先进入本技能做分派与门禁检查**。
+- 可在内部回执使用标记：`[SKILL:workflow-hub]`，不强制对用户输出首行标记。
+
+## 门禁（先于一切）
+- **入口强约束**：命中任一子流程前，必须先 `Read` 目标技能的 `SKILL.md`；若该技能存在同目录 `reference.md`，也必须 `Read` 后再进入执行。
+- **单技能内**：遵守该技能 `SKILL.md` 中的阶段顺序与 PASS/FAIL；不得跳过未声明可跳过的阶段。
+
+## 调度顺序（唯一规则 A）
+
+**执行顺序原则（有代码交付时）**：先 **开发（dev-task-flow）** → 再 **联调自测（self-test-flow）** → 再 **提交与部署（deploy-test-env）** → 最后 **GeeLib 收尾**。不得在开发未完成、自测证据未齐套前进入 **deploy-test-env**。
+
+| 规则 | 命中关键词（任一） | 技能链（按顺序） |
+|------|--------------------|--------------------|
+| A | GeeLib / geelib.qihoo.net / matterType / subId / 拉任务 / 改状态 / 开发功能 / 实现接口 / 修 bug / 完善模块 / 自测 / 自测流程 / 联调验证 | **workflow-hub(GeeLib阶段)** →（若含开发）**dev-task-flow** → **self-test-flow** → **deploy-test-env** → **workflow-hub(GeeLib收尾)** |
+
+
+**嵌套规则（必读）**
+- **dev-task-flow** 阶段 3：必须按 **self-test-flow** 的 `SKILL.md` + `reference.md` 执行（非 `go test ./...`）。
+- **deploy-test-env**：进入执行前须 `Read` **deploy-test-env/SKILL.md** 与 **deploy-test-env/reference.md**。流程为审阅 → 同步 →（用户要求时 `go test`）→ 提交 → 推送同名分支 → `local_build.sh`；其中 `go test` 与 **self-test-flow** 的联调自测并列、互不替代。
+- **GeeLib 阶段遇到本仓库改代码**：在未 `Read` **dev-task-flow/SKILL.md** 与 `reference.md` 前禁止编码；开发段按 dev-task-flow 全流程执行。
+- **零代码任务**：无开发段时，在 GeeLib 阶段与交付对齐后仍须执行 **deploy-test-env**（若无代码可提交则阶段 4 跳过提交，继续推送与构建验证）。
+
+## GeeLib MCP 优先策略（必读）
+
+**所有涉及任务信息的读写操作，必须优先使用 `user-geelib` MCP，禁止默认走浏览器。**
+
+| 操作类型 | 优先方案 | 降级方案（仅当 MCP 不可用时） |
+|---------|---------|--------------------------|
+| 查询工作项列表 | `list_matters` | 浏览器导航 |
+| 查询工作项详情 | `get_matter_detail` | 浏览器导航 |
+| 查询工作项类型 | `list_matter_types` | 浏览器导航 |
+| 查询状态列表 | `list_matter_statuses` | 浏览器导航 |
+| 更新状态/备注 | `update_matter` | 浏览器点击操作 |
+| 添加评论 | `add_comment` | 浏览器填写表单 |
+| 查询项目信息 | `get_project_detail` | 浏览器导航 |
+| 查询项目成员 | `list_project_members` | 浏览器导航 |
+
+降级条件：MCP 工具调用返回非 2000 错误码，且重试一次仍失败，才可切换到浏览器 MCP。
+
+## GeeLib 阶段
+- **阶段 1 验证可访问**：调用 `get_user_info` 确认 MCP 已鉴权、会话有效。如果返回非 2000，立即停止并提示用户检查 GeeLib MCP 配置。
+- **阶段 2 选取任务**：用 `list_matters` + `list_matter_types` 获取工作项列表，分析任务类型；需求开发类任务先用 `get_matter_detail` 读取描述与接口文档。
+- **阶段 3 读取详情**：用 `get_matter_detail` 记录标题、描述、当前状态；将交付范围和用户对齐一句。
+- **阶段 4 本仓库执行**：开发类强制切 `dev-task-flow`；零代码任务可直接执行。
+- **阶段 5 回写 GeeLib 状态**：用 `update_matter` 更新状态与备注，用 `add_comment` 写交付说明；调用后再次 `get_matter_detail` 确认保存成功。
+- **阶段 6 收尾回复**：输出任务标识、交付内容、GeeLib 最终状态、提交信息（若有）。
+
+## GeeLib 门禁
+- `user-geelib` MCP 自带鉴权 Token，无需浏览器登录；但仍需确保 VPN 可访问 GeeLib 服务。
+- 不把 Cookie/Token/密码写入仓库或代码。
+- 涉及代码改动时，未完成 `self-test-flow` 完整证据（启动记录 + 步骤执行 + 存储侧校验），禁止回写「已完成/关闭」。
+- 仅当用户在当前对话明确要求"跳过自测/仅编译验证"时，允许回写完成态；必须在 GeeLib 备注与回复中记录风险。
+
+## 输出约定
+- 每次调度必须包含以下回执字段（可用编号）：
+  1) `已命中规则`：A  
+  2) `命中关键词`：列出触发词  
+  3) `已加载技能`：列出已 `Read` 的路径（至少 `SKILL.md`；若存在 `reference.md` 也列出）  
+  4) `当前技能链`：按执行顺序展示  
+  5) `当前阶段`：已完成 / 进行中 / 待执行
+- 用表格或编号列出「当前对话应激活的技能链」与「已完成/待完成阶段」。
+- 指向路径使用仓库内相对根路径：`.cursor/skills/<skill-name>/SKILL.md` 与 `reference.md`。
+
+## 延伸阅读
+- 完整决策树、与其他文档关系：**同目录 `reference.md`**。

package/skills-runtime/workflow-hub/reference.md

@@ -0,0 +1,66 @@
+# 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** 的调度表中增加对应行或脚注。