| name | automatic-handoff-pipeline |
| description | 使用 Designer、Architect、Developer、Tester 四个子智能体串联完成设计、架构、开发、测试的完整交付流程；适用于端到端需求实现、多阶段协作与产出物交接。 |
| argument-hint | 描述你的需求，或说明从哪个阶段开始执行 |
| user-invocable | true |
| disable-model-invocation | false |
自动交接流水线技能
这个技能用于把一个需求按固定流水线拆给多个专职子智能体处理，并确保每一环都有明确产出物，供下一环节继续使用。
何时使用
- 用户希望“从想法到结果”一条龙完成。
- 任务同时包含页面设计、技术方案、代码实现、测试验收。
- 需要把多阶段思考沉淀到
thinking/ 目录，方便追踪和复用。
子智能体职责与产出物
| 子智能体 | 主要职责 | 输出文件 | 下一环节 |
|---|
Designer | 页面设计、信息架构、交互与视觉约束 | thinking/designer.md | Architect |
Architect | 技术方案、接口契约、模块拆分与实现步骤 | thinking/architect.md | Developer |
Developer | 代码实现、文件改动说明、验证记录 | thinking/developer.md | Tester |
Tester | 测试验收、缺陷记录、交付建议 | thinking/tester.md | 最终输出 |
推荐执行流程
- 先调用
Designer，把需求转成设计交接包。
- 再调用
Architect，基于 thinking/designer.md 形成架构方案。
- 接着调用
Developer，基于 thinking/architect.md 完成实现。
- 最后调用
Tester，基于 thinking/developer.md 做验证结论。
- 汇总四个阶段的结果，向用户说明：做了什么、验证了什么、还有什么风险。
具体规则
- 每一位子智能体必须读取上一环节产出物。
- 若上游信息缺失，使用
[*] 标注，不得臆造。
- 每一环都必须写入对应的
thinking/*.md 文件。
- 非必要不要跳步；若确需跳过，必须在最终汇总中说明原因。
使用示例
- “请按完整流水线完成一个用户注册功能。”
- “请先用 Designer 和 Architect 帮我把商城首页方案做出来。”
- “请从 Developer 开始，根据现有架构文档直接落地实现。”
最终输出要求
最终汇总时必须包含：
- 已完成内容
- 实际验证内容
- 剩余风险与限制
- 建议的下一步动作
