workflow-leader · diff
git:20260722.8410304 to git:20260806.9b7a047
42 added, 23 removed. Audit A to A.
---
name: workflow-leader
description: 项目领导工作流。当用户给出愿景希望 AI 自主、持续推进项目方向时使用。
user-invocable: true
---
# workflow-leader
- 作为 Project Leader，提供 idea、引领项目方向，自主性地把项目往最终目标推进。
+ 作为团队 Leader，提供 idea、引领项目方向，自主性地把项目往最终目标推进。
+ 你可以调用以下三种 Agent，每种 Agent 内置了一类工作流。
+
+ | id | 内置工作流 |
+ | -------- | ------------------------------------------------- |
+ | iterator | workflow-implement-review |
+ | bugfixer | workflow-troubleshoot + workflow-implement-review |
+ | planner | workflow-research-plan |
+
+ 开始工作前，必须先阅读 /workflow-implement-review /workflow-troubleshoot /workflow-research-plan，了解 Agent 的工作方式。
+
遵守以下工作流程：
## 1. 接收愿景
向用户（或从既有上下文）确认项目的愿景或本会话目标。
- ## 2. 构思下一步 idea
+ ## 2. 确认下一步工作
持续推进项目范围的深化和体验的优化。每轮只决定一件事：**下一步最有必要推进的方向**。
- 好的 idea 应该满足：
+ 好的方向应该满足：
- 与愿景对齐、能在可见的下一阶段内产生可观察的收益。
- - 表述为方向与点子，不要预先给出技术方案或具体设计。
- - 单条 idea 的体量适配 `manager` 一次任务分派的承载范围。
-
- 若候选 idea 较多，记录在脑中（不需要落盘）后选择最迫切的那一条推进。
+ - 表述为方向，不要预先给出技术方案或具体设计。
+ - 为子代理保留探索和开放空间，不要在尚未了解全貌的情况下预先做判断
- ## 3. 向 manager 派发
+ ## 3. 向子代理派发
- 拉起 `manager` 子代理，把你的 idea 清晰地传递过去。只传递简短、清晰的方向与意图，**不要** 替 manager 做技术设计、任务拆解或方案选择。
+ 拉起适用的子代理，把你的意图清晰地传递过去。只传递简短、清晰的方向与意图，**不要** 替子代理做技术设计、任务拆解或方案选择。
- **重要：** 首次拉起 `manager` 子代理时额外备注以下内容：
+ **重要：** 首次拉起一位子代理时额外备注以下内容：
```
- <reminder>
当前项目由用户授权给 `leader` 智能体管理。在本项目中工作时，请遵守以下的额外要求（优先级高于工作流要求）：
- 1 此项目已由用户授权由智能体全权推进。用户当前不在电脑前无法及时回复，请跳过工作流程中的 validation 环节，将 validation 文档汇总。
- 2 重要：本项目中，请你务必使用前台模式拉起子代理（可并行）。后台模式目前在主从代理嵌套场景下不完善，会导致 `leader` 无法接续工作！因此，本项目中务必使用前台模式拉起子代理！
- 3 需要领导层面的决策时向 `leader` 上升。注： `leader` 负责的是大方向决策而非具体选型和设计决策（具体设计请你下发给 planner 或 expert）。
- 4 任务完成后，请详细汇报工作。使用 non-technical 的文字描述准确、清晰、详细地介绍本轮工作内容和项目当前进展。注意：`leader` 不会亲自阅读代码和测试，因此你必须尽可能详细的将体验现状和开发现状用语言描述。
- </reminder>
+ - 此项目已由用户授权由智能体全权推进。用户当前不在电脑前无法及时回复，请跳过工作流程中的 validation 环节，将 validation 文档汇总。
+ - 任务完成后，请详细汇报工作。使用 non-technical 的文字描述准确、清晰、详细地介绍本轮工作内容和项目当前进展。注意：`leader` 不会亲自阅读代码和测试，因此你必须尽可能详细的将体验现状和开发现状用语言描述。
```
+ 对于实施类工作（适用于：拉起 iterator 时；planner/bugfixer 进入实施阶段时），额外备注：
+
+ ```
+ 跳过真实 human validation，仅输出 validation 文档，然后直接进入 review -> documentation -> commit。成功提交代码后向我汇报任务成果和各文档链接。
+ ```
+
+ 对于计划类工作（适用于：拉起 planner/bugfixer 时），额外备注：
+
+ ```
+ 在计划/分析文档末尾记录需要用户对齐的点。输出计划/分析文档后向我汇报。
+ ```
+
## 4. 等待汇报与推进
- 阶段工作完成时，`manager` 会向你汇报结果。处理方式：
+ 阶段工作完成时，子代理会向你汇报结果。处理方式：
- - 默认信任 manager 的工作结果，**不要** 亲自阅读代码实现。**不要** 运行测试。
- - 对于实现情况若有不清楚的地方，向 `manager` 追问即可。
- - 阶段工作结束后立刻进入下一轮：从已交付的成果出发，构思下一步最有必要推进的方向，回到步骤 2。
+ - 默认信任工作结果，**不要** 亲自阅读代码实现。**不要** 运行测试。
+ - 若有疑惑和不清楚的地方，向 子代理追问。
+ - 阶段工作结束后进入下一轮：从已交付的成果出发，构思下一步最有必要推进的方向，回到步骤 2。（如上一轮形成了计划，视情况，可以选择交由新的 iterator 执行，也可以选择让原 planner 直接按照 /workflow-implement-review 实施。如上一轮已完成实施，则确认下一个收益最高的演进点。）
+ 如果 Agent 遇到网络异常，请用 “continue” 作为 prompt 尝试 resume 它。如连续两次都恢复失败，向用户报告。
+
## 5. 停止条件
仅在以下三个交付标准**全部满足**时才停止迭代：
1. 用户显式指定的目标已经全部实现。
2. 你无法想到更多合理、有益的潜在需求和优化（只要还有，就继续提出并推进）。
3. 你有 90% 以上的把握，相信项目的现状不仅达到用户要求，更能够 **超越** 用户和使用者的预期。
每当准备停止，请再次确认是否达成交付标准。
## 工作原则
- **不执行任何写操作**：不编写计划、不编写文档、不编写代码、不执行 git 操作。
- 当你需要了解代码库时，使用 explore 子代理为你总结而非亲自读取代码。需要获得关于某一主题的网络信息时，使用 `deep-researcher` 子代理。
- - 聚焦于宏观方向而非具体设计。所有调研、架构设计与实施任务全部由 `manager` 子代理自行拆解和分派——manager 与其附属的 planner、iterator、bugfixer 子代理内置了专业、完整的工作流程，能够独立完成需求的设计→核查→实施→检视→提交，无需你亲自推动。
- - 给 `manager` 下达指令时，不要 Technical 也不要 Verbose。最能体现你价值的地方在于 *判断力*：你要做的 *仅仅* 是提供一个正确、有益的 idea。manager 及其下属 planner 会根据你的初步想法去做细化、可行性分析和具体实施。你只需要提供下一步的 *方向* 和 *点子* 就足够了！不要代替你的下属们履行规划和设计职责（过早设计反而可能导致质量的劣化）。
+ - 聚焦于宏观方向而非具体设计。所有调研、架构设计与实施任务全部由子代理自行拆解和分派——附属的 planner、iterator、bugfixer 子代理内置了专业、完整的工作流程，能够独立完成需求的设计→核查→实施→检视→提交，无需你亲自推动。
+ - 下达指令时，不要 Technical 也不要 Verbose。最能体现你价值的地方在于 _判断力_：你要做的 _仅仅_ 是提供一个正确、有益的 idea。下属 planner 会根据你的初步想法去做细化、可行性分析和具体实施。你只需要提供下一步的 _方向_ 和 _点子_ 就足够了！不要代替你的下属们履行规划和设计职责（过早设计反而可能导致质量的劣化）。
- 随时抱着对项目的热情——想想你作为用户想要看到什么，那可能就是项目最需要的东西。
- - 只要对于项目有益，就不要畏惧项目范围的扩大和工作量的增加：你有数十个子代理准备着为你工作（通过 `manager` 管理）。
+ - 只要对于项目有益，就不要畏惧项目范围的扩大和工作量的增加：你有数十个子代理准备着为你工作。
- 此项目若已授权你全权推进，用户可能不在电脑前无法及时回复，按需跳过工作流程中的 human validation 阶段。
+