spec-first

先编写规范，再开发

对于非简单实现，先遵循共享的准备流程。将需求、决策和步骤保留在同一个议题中，以便执行者和独立审查者检查同一份事实来源。

流程约定

输入：

• 用户请求、代码仓库、现有议题／计划，以及已获授权的交付范围。

输出：

• 可直接执行的议题，或具体的规划阻碍事项。
• 获准实施时，提供实施证据和交付门禁状态。

创建／修改：

• 通过受委托的引擎，在调用方授权范围内创建／修改所请求的准备材料、实现内容和交付产物。

外部副作用：

• 仅限已获授权的跟踪器／代码仓库操作；遵守所有访问权限和主机限制。

所需确认：

• 现有的实施授权涵盖同一范围内的准备和执行。仅在缺少重要意图或需要扩大授权时才询问。 仅请求准备工作的流程在准备完成后即停止。代码仓库合并／部署权限以及必需的审查／CI 门禁仍然适用。

委托给：

• feature-intake，负责需求梳理和已确定的实施规划。
• prd-quality-gate，负责阻止执行准备不足的任务并验证信息是否为最新。
• executing-plans，负责按要求实施并提供交付证据。

工作流程

1. 如已提供实时议题和当前计划，先阅读。如果材料缺失或需要准备，则运行 feature-intake 技能。该协调器使用规范的需求和计划模板；不要另建独立的规范、待办事项和决策文件，也不要强迫用户在三种备选方案中做选择。
2. 针对当前代码和需求，以 execution-readiness 模式运行 prd-quality-gate 技能。规划者负责弥补缺口并修正过时假设；不得授予执行者自行决定缺失行为或架构的权限。
3. 如果已获准实施且状态为 READY，则运行 executing-plans 技能，并提供准确的议题／当前计划、范围、主机限制和必需的交付门禁。遵循运行环境选定的执行者；不要在此处选择模型或工作量。
4. 要求提供实施检查、完整的验收证据、由运行环境策略选定的另一实验室进行独立审查，以及最终 PR 提交所需的 CI。计划审查或自我审查不能替代实施审查。审查资源不足时，必须明确标示，并阻止任务完成。
5. 将未解决的决策交回规划者，将代码缺陷交由指定流程修复，并将无法访问或执行检查的情况明确标记为受阻状态。代码变更后，针对实际的最终修订版本重新进行受影响的检查／审查。
6. 如实报告交付状态。只有完整满足全部验收约定和项目交付门禁，功能才算完成。子任务／后端 PR 合并以及部分 CI 检查通过，都不能作为关闭未完成的功能或 Epic 的依据。

范围适度

对于范围明确的工作，使用精简材料；拼写错误或机械性编辑无需完整 PRD。保持相同的决策和验证边界。完整功能应在其议题中包含所有必要的 API、UI、连接逻辑、迁移、测试、文档和运维交接；如需拆分，应遵循共享的独立成果规则。