开发流水线：需求分析 → 看板 → 认领 → 子agent派发

主agent担任需求分析师，把结构化需求单上传到 Taskboard，自动认领后按路由表派发子agent执行，最后回写结果并转 in_review。

本技能是 manage-taskboard 技能的上层编排，遵循其全部规则（写操作必须 --thread-id、并发更新必须 --if-version、in_review → done 只能由用户确认触发）。

常量（使用前请根据本地环境替换）

以下常量在每次会话首次调用时由主 agent 确认一次，后续复用：

首次使用建议：将以上占位符替换后，在项目 .trae/rules/ 下建一条规则文件，写入上述映射，主 agent 会自动读取，无需每次手动替换。

前置检查

执行任何阶段前先跑 node <TASKCTL_CLI_PATH> context current：

• 正常返回 JSON → 服务在跑，继续
• exit code 3（服务不可用）→ 告知用户需在 Taskboard 服务端目录执行 npm start，不要自行静默拉起长时间驻留服务（除非用户明确要求）

阶段 1：需求分析（主agent = 需求分析师）

两种入口模式：

• 接单模式：用户给出粗略想法 → 主agent细化。缺口信息（目标、范围边界、验收标准）用 AskUserQuestion 一次性问清，已明确的细节不反复追问。
• 提案模式：用户要求主动提案（"提点需求""有什么该做的"）→ 主agent从项目记忆、遗留问题（标记过"待清理""已知缺陷"的事项）、技术债中提炼候选需求，列清单给用户挑选确认。

产出的需求单必须包含以下章节（Markdown）：

## 背景
为什么要做，关联的业务场景

## 需求范围
- 做：具体条目
- 不做：明确排除项

## 验收标准
- [ ] 可逐条验证的条目

## 分类与模块
建议分类（backend/frontend/ui/test/perf/review）+ 涉及模块

阶段 2：上传看板

1. 查重：node <TASKCTL_CLI_PATH> issue list --project <PROJECT_ID>，已有同类 issue 则把新细节 comment add 追加到该 issue，不新建。
2. 创建：需求单写入临时 md 文件（避免命令行转义问题），然后：

node <TASKCTL_CLI_PATH> issue create --project <PROJECT_ID> --title "标题" --description-file "<临时文件>" --labels <分类>,<模块> --priority <none|low|medium|high|urgent> --thread-id <THREAD_ID>

3. 记录返回的 identifier（如 PA-ERP-1）与 version，删除临时文件。
4. 跨前后端的需求：拆成父 issue + 多个子 issue，用 issue relation add <子ID> --type parent --issue <父ID> --thread-id <THREAD_ID> 建立关系，分别派发。

阶段 3：自动认领

node <TASKCTL_CLI_PATH> issue move <identifier> --status in_progress --if-version <version> --thread-id <THREAD_ID>

版本冲突（exit 5）→ 重新 issue get <identifier> → 协调新状态 → 用新 version 重试。认领失败（他人在做/状态已变）则跳过该 issue。

阶段 4：派发子agent

路由表见 references/routing.md。要点：

1. 派发前必须 Read 对应角色文件（<AGENTS_DIR>/<role>.md），把完整角色定义嵌入 Task query——子agent不共享本会话上下文，角色规范必须随任务下发。
2. Task query 结构：角色文件全文 + issue 全文（含验收标准）+ 执行边界（允许/禁止/工作目录/完成后返回什么）。
3. 探索类任务用 subagent_type=search，浏览器实测用 browser_use，其余一律 general_purpose_task + 对应角色文件。
4. 并行派发不超过 4 个。
5. 子agent返回后主agent必须亲自验证（构建/测试/数据一致性/验收标准逐条核对），不信任子agent自述。

阶段 5：收尾回写

1. 评论记录：

node <TASKCTL_CLI_PATH> comment add <identifier> --body "改动文件: ...\n验证: ...\n风险: ..." --thread-id <THREAD_ID>

（body 较长时同样先写临时文件再引用，或分段 comment）

2. 转审核：node <TASKCTL_CLI_PATH> issue move <identifier> --status in_review --if-version <最新version> --thread-id <THREAD_ID>
3. 用户明确确认验收后才 done；无法继续 blocked；不做了 canceled。永远不自审自过。

硬性规则

• 子agent只做被派发的事；需求分析、看板读写、结果验证归主agent。
• issue 从创建到 in_review 的每次状态流转都要在同一会话内完成闭环，不留半途 issue。
• 看板数据与实际改动必须一致：issue 里写了什么文件，验证时就查什么文件。