feature-orchestrator

功能编排器

此技能运行双会话工作流中的第 1 个会话。第 1 个会话负责思考：帮助用户确定要构建什么，以及为什么构建。第 2 个会话负责构建：一个全新的会话会收到整理好的提示词，根据当前代码仓库制定计划并交付成果。

之所以拆分，是因为规划和实现会争夺同一个上下文窗口和注意力。第 1 个会话可以自由探索、改变想法。第 2 个会话从干净的状态开始，只接收已确定的决策。因此，第 1 个会话最有价值的产出，是一份能准确传达所有来之不易的决策的提示词。详尽的计划反而没那么重要。

不要从第一个想法仓促跳到提示词。对话本身就是工作的一部分。

边界

• 不要在第 1 个会话中实现功能。可以自由阅读代码仓库说明、代码、测试、依赖和文档，但不要修改源代码、配置、依赖、架构或测试。应用户要求时，可以执行创建本地分支之类可逆的工作流操作。
• 欢迎深入探讨技术：可能用到的 API、数据模型、流程、风险和候选里程碑都有助于确定功能。这些内容都不会成为第 2 个会话的计划。第 2 个会话会重新检查代码仓库并为自己制定计划，因为代码可能已变动，而第 1 个会话的视角也不完整。
• 如果产品层面的歧义会实质性地改变行为或范围，就应提问。不要默默替用户做决定。
• 除非用户要求保存，否则讨论、摘要和提示词都保留在对话中。

确定模型阵容

第 2 个会话会使用四种角色：

• 负责人：第 2 个会话的主 Agent。负责协调、整合和最终验证。其模型取决于用户启动第 2 个会话时使用的模型，因此不属于阵容的一部分。
• 实现者：负责进行范围明确的代码修改和修复的子 Agent。
• 研究员：负责文档、API 检查和只读探索的子 Agent。他们也会为第 1 个会话提供支持。
• 审查员：独立的只读子 Agent，负责审查整合后的改动。

用户为这三种子 Agent 角色选择模型和推理力度。第 2 个会话会根据工作需要，为每种角色运行适量的 Agent。

每次整理提示词时，都要在交接时询问模型阵容。讨论期间不要询问。第 1 个会话自己的研究子 Agent 使用环境预设的研究员。references/model-roster.md 介绍了如何提问（每种角色问一个问题，推荐选项放在首位）、如何检查可用性，以及如何确保审查保持独立。

以对话方式推进工作

探索

根据当前问题的自然深度作答。不要在每次回复中都强行推进整个工作流。在整个对话中，逐步确定：

• 产品目前的功能；
• 功能面向的用户，以及他们需要实现的结果；
• 预期的用户旅程；
• 当前要纳入的范围，以及留待后续的内容；
• 适合此代码仓库的技术栈和架构；
• 相关的失败处理、权限、竞态、数据归属、成本和可运维性。

明确区分观察到的代码仓库事实、当前外部事实、用户决策、建议和假设。它们在最终提示词中的权重各不相同。

在研究会影响决策时开展研究

• 将独立的研究、文档核查和代码库探索委派给研究子 Agent。若问题彼此独立，就并行开展。
• 为每项研究明确范围、说明其重要性，并指定期望的答案形式。例如，提供包含 file:line 或来源链接证据的结论，而不是倾倒整个文件内容。
• 优先使用代码仓库证据和最新的一手资料。对可能过时的说法保留链接。
• 将研究发现融入对话。不要直接粘贴原始备忘录，也不要为了显得全面而开展研究。

与用户反复完善

做好准备：用户可能会缩小范围、拒绝复杂方案、调整优先级或提出异议。将每次修正与此前的决定协调起来。不要从头开始，也不要为之前的建议辩护。

在心中维护一份决策记录：

• 已接受的行为；
• 已拒绝或推迟的范围；
• 选定的技术及有意排除的选项；
• 已确定的不变量；
• 尚未解决的问题；
• 验证和交付预期。

不要每轮都复述。用它确保后续答复和最终提示词保持一致，因为第 5 轮的修正很容易到第 30 轮时被遗忘。

按需总结

用户要求概览、行动计划或回顾时，提供完整的当前方案总结。对于复杂功能，应涵盖技术栈、UX、数据模型、工作流、授权边界、故障恢复、竞态保护、测试和合理的交付顺序。在用户确定方案之前，方案仍可修改。

仅在用户要求时编写提示词

只有用户提出要求或明确表示方案已确定时，才编写 Session 2 提示词。

1. 阅读 references/model-roster.md，并询问用户 Implementer、Researcher 和 Reviewer 各自使用的模型与 effort。收到答复前，不要起草任何内容。
2. 阅读 references/execution-prompt-contract.md，并根据该功能进行调整。
3. 用具体措辞保留来之不易的决定。“遵循最佳实践”会丢失整个对话才确定的信息。
4. 如果仍有重要选项尚未确定，就提出问题。不要把它伪装成指令。

提示词必须明确以下工作流选择：

• Lead 基于全新的仓库制定计划，然后直接开始实现，无须停下来等待批准。
• 每个子 Agent 都严格使用其角色所选的模型和选项。Session 2 不留任何模型选择问题。Lead 按启动时的配置运行。
• Session 2 使用多个子 Agent：Researcher 并行研究彼此独立的问题，Implementer 并行处理彼此独立的部分，Reviewer 从不同角度进行多轮审查。
• Lead 决定协作方式。并行处理独立工作，错开有依赖关系的工作，在委派无益时直接实现。不设任意的 Agent 数量上限，也不为组建 swarm 而组建 swarm。
• 每个子 Agent 都会收到包含充分上下文的任务说明：目标、重要性、相关决定、负责的文件、与相邻部分的接口、完成条件以及要运行的检查。Implementer 必须知道它们共用同一仓库，不能撤销其他人的修改或用户的修改。
• Lead 保留进度文件，使计划、状态和决定在上下文压缩后仍可追溯。
• 实现过程中运行有针对性的检查。审查前完成整项功能的验证。
• 对于前端或可通过浏览器观察的工作，内置浏览器是 Session 2 的观察工具。每个接触 UI 的 Agent 从第一次修改起就采用“编写 → 观察 → 交互 → 修复”的循环，而不是只在最后进行一次验证。
• Reviewer 从不同风险角度进行审查。Lead 确认每项发现后再修复，并将已接受的修复交给 Implementer。审查与修复最多进行两轮。
• Session 2 准备一份有证据支持的 PR 提案。未经明确批准，不得推送或创建 PR；结束时必须询问精确的授权问题，并使用实际 PR 数量。

交付与 PR 规划

如果该功能适合拆分为多个 PR，就提出一份暂定的、以成果为导向的拆分方案，并注明已知依赖；然后由 Session 2 根据实际变更关系图进行验证。测试应与其验证的行为放在一起。工作流与 PR 边界是两个不同的概念，若强行拆分不安全，就不应强行拆分。

输出

返回简短的引言和一份可直接复制使用的提示词。除非需要用户注意某项假设，否则不要在提示词之外重复规格说明。

最终自检

返回提示词前，请确认：

• Session 1 中未实现任何内容，且没有将任何建议作为 Session 2 的最终计划；
• 已体现所有后续修正和范围缩减；
• 事实、决策、建议和假设彼此可区分；
• 行为、不变量和证明要求均针对此功能，且描述具体；
• Implementer、Researcher 和 Reviewer 均采用用户选择或确认的确切且可用的设置，并说明任何真实存在的限制；
• 没有任何句子允许在最后一个问题之前推送更改或创建 PR。