flow-feature

新需求交付流程

本 Skill 只负责衔接已有研发模块，不复制它们的内部操作。进入每个阶段时，加载并完整遵循对应 Skill。

依赖

必须能够使用 grill-with-docs、prototype、to-spec、to-tickets 和 implement；原始输入是口述或逐字稿时还要能够使用 from-transcript。首次在仓库中运行工程流程前，应先完成 setup-engineering-skills。如果依赖缺失，停在当前边界并明确报告，不要临时发明一套替代流程。

开始前读取仓库的 AGENTS.md 或 CLAUDE.md，让工单系统、分诊标签、领域术语和 ADR 约定贯穿整个流程。

流程

0. 编译原始口述（按需）

输入是会议逐字稿、连续口述或未经整理的聊天记录时，先调用 from-transcript。只有经用户确认的输入简报进入后续阶段；保留当前会话作为一手来源，不让用户重述已经确认的内容。

1. 澄清需求

调用 grill-with-docs，直到用户价值、范围、领域语言、验收接缝、正常与异常验收例子和难以回退的决策都已明确。功能依赖外部系统时，确认不可用、超时、重复、部分成功和并发冲突中哪些会改变接口承诺。澄清、规格化和拆工单应尽量留在同一个连续上下文中。

如果最终只有一个局部行为且一次实现上下文足够，转用 flow-small-change；如果连通往目标的路线都还说不清，转用 flow-large-effort。

2. 只在必须运行或亲眼查看时制作原型

只有当某个问题无法靠对话回答、必须运行状态/业务逻辑或查看 UI 时才调用 prototype。动手前写明原型要回答的唯一问题；结束时记录原型分支或产物、结论，以及它改变了哪项决策，再把结论带回原需求上下文。

原型是规格的证据，不是生产代码，也不能代替规格。只有跨运行环境、目录、仓库或协作者时才需要可携带的 handoff；否则继续使用当前上下文。

3. 发布规格

调用 to-spec，用完整澄清记录和原型结论合成规格。确认验收接缝、带编号的验收用例、故障与一致性决策以及非目标后，把规格发布到已配置的工单系统。这个阶段只做综合，不重新访谈用户。

4. 拆成交付工单

调用 to-tickets。发布前必须让用户确认纵向切片的粒度、验收用例分配、阻塞边，以及所有临时结构的删除工单。这里生成的工单天然是 ready-for-agent，禁止再次送入 triage。

5. 推进可执行前沿

只实现所有阻塞项均已关闭的工单。每次调用 implement 只处理一张工单；一张工单对应一个分支/工作树、验证、评审、提交、推送和关闭周期。

完成一张后，下一张从干净上下文开始，重新读取完整工单、评论、相关领域文档和 ADR。如果当前环境无法自动切换干净上下文，就停下来列出下一张可执行工单和准确调用方式，不要把上一张工单的偶然上下文继续带下去。只有用户明确要求并行，且每张工单都有隔离分支和可写工作树时才并行。

6. 功能级收尾

所有范围内工单完成后，检查父规格中的每个验收用例是否都有交付证据、临时结构是否已删除或有明确责任工单、领域与架构上下文是否已同步。执行仓库规定的项目级完成钩子，例如项目管理记录或变更日志更新。

完成条件

规格已发布，所有范围内工单都有交付证据并关闭，全部验收用例有证据，临时结构有明确结局，项目级完成钩子已执行，且没有未解决的阻塞项。除非工单系统规则明确授权，否则不要关闭或改写父规格 Issue。