implement-feature

实现功能

高级构建编排器：将计划转化为已实现并经过审查的功能，方法是将其拆分为任务，并将每项任务委派给 implement-and-review。你（主 Agent，即 Opus 席位——模型 ID 仅记录在 shared/references/model-roster.md 中）负责拆解、依赖 DAG 与调度、跨任务集成，以及整个功能的最终审查。每项任务的构建工作——FE/BE 拆分、跨模型审查和 TDD——由 implement-and-review 负责。调用它，不要重新实现它。

流程：计划 → to-tasks（垂直切片）→ 每项任务调用 implement-and-review（相互独立时并行）→ 按依赖顺序集成 → 整个功能的 full-review → 通过。

详细的调度与集成命令见 references/feature-orchestration.md；请在阶段 1 前阅读。

硬性规则

1. 使用 to-tasks 拆解。 将计划拆分为 tracer-bullet 垂直切片任务，每项任务都要有可机器检查的验收契约、门控标志（审查视角 + security）和 blocked_by 依赖项。
2. 任务是价值和并行的基本单位。 相互独立的任务并行运行；有依赖关系的任务必须等待阻塞项完成。
3. 将每项任务委派给 implement-and-review。 不要重复实现其 FE/BE/TDD/交叉审查逻辑——将任务、每项任务专属的 --slice 命名空间，以及作为构建基础的基线交给它。
4. 写入操作必须经过门控。 在用户批准任务拆解前不得编写代码（仅 --auto 可跳过此步骤）。
5. 按依赖顺序集成。 每项任务都必须通过验收契约，其依赖任务才能启动。
6. 进行整个功能的最终审查。 所有任务集成后，对整个功能运行 full-review（重点审查跨任务接缝；每项任务已完成单独审查），修复发现的问题，确保通过。
7. 限制范围并升级处理。 如果某项任务的 implement-and-review 达到 3 轮上限，则升级处理；它只会阻塞其依赖任务——相互独立的任务继续进行。
8. 绝不虚构席位；按优雅降级处理。

预检

1. 宿主环境与 git。 工作树（因此也包括并行任务）需要 git；没有 git 时改为串行执行。
2. 席位。 提前使用共享探测工具验证主要席位，避免所有任务都失败：python3 .agents/skills/shared/scripts/discover_runners.py probe --native-agent yes --seat codex --seat opus --seat kimi --format json。每项任务的 implement-and-review 都需要默认的 Codex 席位，以及原生或由 runner 支持的 Opus 席位；Kimi 是首选的备用审查者。
3. 验证命令。 检测项目范围内的功能测试和构建命令。to-tasks 验收契约必须使用现有命令。
4. 并发上限。 默认最多 3 项任务同时进行（每项任务都会运行完整的 FE+BE 构建）；席位或成本受限时应调低上限。
5. 基线与产物。 将 HEAD 记录为功能 <base>；创建功能集成分支；使用 .ai-workflow/impl-review/<session_id>/ 存放任务拆解、各任务子目录和报告。

阶段 0 — 规划与分解（关卡）

1. 接收计划。 来源：用户提供的计划／规格说明；现有的 TASKS.md 或跟踪器问题；或者 models-consensus 轮询模式报告（通过 --from-consensus <path> 传入，例如 .ai-workflow/consensus/<session_id>.md）——将其中的 Consensus answer 作为计划，并先与用户解决其中的 Open caveats。

   如果构建前先进行了共识运行，交接时须遵守三条规则：

   • 在不透露背景的情况下向评审组说明请求。 将原始请求作为待回答的任务交给评审组（"determine what this feature requires and the best approach: <request>"）。编排器不得预先分析请求，也不得贴出自己的解读——无偏的并行征询就是轮询的全部价值。
   • 两次运行使用同一个会话 ID。 共识运行和本次构建共用一个会话 ID（.ai-workflow/consensus/<id>.md → --from-consensus），这样构建使用的正是已生成的共识，而不是重新运行、改述或再次轮询的结果。
   • 无需编写代码 → 停止。 如果共识表明请求是一个问题或决策，而不是要构建的工作，就在此停止，直接返回共识答案，不要进行任何分解。

2. 使用 to-tasks 进行分解 → 拆分为包含验收标准、关卡和依赖项的垂直切片任务。如果工作确实只有一项任务，跳过 to-tasks，直接调用 implement-and-review（然后停止）。

3. 展示任务列表（标题、依赖项、验收标准、关卡、HITL／AFK）和验证命令。编写任何代码前都必须获得批准，除非使用 --auto。

阶段 1 — 排期并构建 DAG

根据 blocked_by 构建依赖图。然后：

• 优先安排 HITL 任务；无人值守地运行 AFK 任务。
• 并发运行所有当前未受阻的任务，但不超过上限；每项任务都通过运行 implement-and-review 来执行——传入任务说明、每项任务专属的 --slice <task> 命名空间，以及 --base = 当前的功能集成分支头（这样每项任务都基于已集成的工作构建）。参见 references/feature-orchestration.md。
• 每项任务的构建完成且通过验收契约后，按依赖顺序将其集成到功能集成分支，重新计算就绪状态，并启动下一批就绪任务。
• 持续执行，直到所有任务完成或升级处理。升级处理的任务只会阻塞其依赖项。
• 报告进度（已完成／进行中／受阻）；绝不默默丢弃任务。

运行状态

一个功能可能持续数小时并涉及许多子进程，因此 DAG 的进度记录在台账中，而不是对话记录中。此技能遵循 shared/references/run-state-contract.md——请阅读该文件，了解状态结构、尝试次数／关卡／副作用规则以及恢复协议。每个功能仅有一份功能级运行状态，此外每个 implement-and-review 还会维护各任务自己的状态。这里只说明功能专属的键：

• ceilings.max_in_flight — 并发上限（默认值为 3）。应根据实际正在执行的任务数量计算，而不是估算。
• side_effects 的键为 merge:<task-id> — 在将任务合并到功能集成分支之前写入；如果键已存在，则跳过该任务的合并。
• 集成分支头是恢复锚点。 steps 条目以稳定的 T-ID 为键，因此已记录在 steps 中的任务均已完成：恢复时，重新读取当前集成分支头，根据台账重新计算就绪状态，并且只安排剩余任务。恢复的功能绝不重新构建已集成的任务。升级处理的任务意味着退出流程，而不是留下缺口——将其结果和原因记录在 steps 中，以便最终报告能够根据台账而非记忆重建。

阶段 2 — 功能级最终审查

所有任务集成后，针对整个功能（与功能 <base> 的差异）运行 full-review，重点审查跨任务集成和衔接处，以及各任务审查无法发现的问题。如果任何任务涉及安全敏感内容，则设置 security_focus=true。处理审查发现（通过 implement-and-review 将问题分配给对应任务的实现者，或进行范围明确的修复），然后重新验证，确保整套测试全部通过。

阶段 3 — 报告

在线提交报告，并写入 .ai-workflow/impl-review/<session_id>/report.md：

1. 功能和最终状态（done / partial / escalated）。
2. 任务 — 表格列出：任务、依赖项、状态、验收结果、审查轮次、并行运行情况。
3. 集成 — 合并顺序、已解决的冲突。
4. 功能级完整审查 — 结论、按严重程度分类的发现、已修复的问题、延期处理事项。
5. 验证 — 命令和结果（通过 / 失败）。
6. 分支 / 工作树 — 功能集成分支，以及如何检查和合并。除非收到要求，否则不要推送、创建 PR 或删除工作树。
7. 升级处理 — 任何因其构建的 3 轮上限而停止的任务，以及尚未解决的发现。

灵活降级

• 不是 git 仓库： 在工作树中按顺序运行任务（每个任务都通过 implement-and-review 的无 git 降级方案执行），不并行运行。
• 可用席位少 / 成本紧张： 将上限调低至 1 左右（按顺序执行任务）。
• 只有一个任务： 跳过 DAG — 直接调用 implement-and-review 并报告结果。
• 任务升级处理： 继续构建互不依赖的任务，并在报告中说明升级情况。

注意事项

• 不要重新实现 implement-and-review。 此技能仅负责拆分任务、构建 DAG、跨任务集成和功能级审查。
• 每个任务都基于当前集成 HEAD（--base）构建，而不是过时的功能基准，这样后续任务就能看到之前的工作；遵循 blocked_by，并为可能修改相同文件的任务添加 blocked_by，使其按顺序执行。
• 每个任务的审查已在各自的 implement-and-review 中完成；功能级 full-review 针对的是衔接处，避免耗费资源对每个任务进行完整的重复审查。
• 纵向与横向： to-tasks 任务是纵向的（涵盖所有层）；implement-and-review 将每个任务横向拆分（前端 / 后端）。任务是外层单元；前端 / 后端拆分在每个任务内部进行。
• 在编排器中维护状态 — 跟踪 DAG 和集成 HEAD；阅读每个任务的精简报告，而非完整记录。