执行已讨论的计划

接续 grill-me 的讨论，根据需求明确程度、任务依赖和并行收益，选择足够完成工作的流程，简短解释后开始执行。用户可以在访谈开始时预先要求讨论收敛后自动执行，也可以在讨论结束后调用本技能。

1. 确认实施依据

读取当前对话中的最终决策、已有规格与工单，以及相关代码和仓库约定。沿用用户已选定的范围、流程和授权。判断现有能力能复用多少：文件数、页面数、代码行数和“完整功能”等措辞都不能单独决定工作规模。

需求就绪意味着目标行为、范围边界、验收标准和影响实施的关键决策已经明确。仓库能回答的事实先自行查明；若仍有影响行为或架构的未决问题，加载 grilling 继续对应分支，收到答案后重新判断。只讨论、只推荐或明确要求暂不实施时，按该限制交付，不能把讨论结束本身当作实施授权。

完成标准：能指出实施依据和验收方式，且不存在需要猜测的阻塞决策。已有确认有效时直接沿用，不重复询问。

2. 分别判断规格、工单和实施方式

**是否需要 to-spec：**当规则、状态、异常或接口约定较多，决策分散在对话中，或者后续实施需要可独立阅读的共同依据时，先固化规格。范围集中、当前讨论已足够明确时，可直接将目标、验收标准、范围和已有测试决策作为 implement 的输入。已有适用规格时复用，只补充确实缺失或改变的部分。

**是否需要 to-tickets：**当工作能自然拆成多个可独立验证的交付单元，且分阶段验收、依赖管理或上下文隔离有实际价值时拆工单。以端到端行为划分，而不是按数据库、API、UI 层机械拆分。工单可直接来自计划或对话，生成工单不强制先生成独立规格。已有工单时检查其范围、验收标准和阻塞关系，复用仍然有效的部分。

选择实施方式：

选择 implement-spec 时必须具备整份规格、关联工单和跟踪器；缺少的产物分别通过 to-spec、to-tickets 补齐。确认环境支持子代理、独立 worktree 和所需 Git 操作。能力不可用或现有授权限制了必要操作时，说明原因，采用可执行的顺序 implement 路线；用户明确要求并行且不能接受该替代时，报告具体阻塞。

完成标准：已分别决定规格是否需要补齐、工单是否需要拆分、实施采用哪种方式，并有对话或代码证据支持。工单形成后若依赖关系与预判不同，更新实施方式并说明变化。

3. 说明路线并立即执行

用一至三句话说明所选路线、复用或跳过的产物，以及关键原因。例如：

采用 to-spec → implement：项目已有打开接口，本次集中在启动入口和失败恢复；先固定行为与测试决策，随后整体实现。

这不是等待批准的菜单。说明后立即加载下一步所需的 Skill 并执行；每步完成后接着推进，直到实施和验证完成，或遇到具体阻塞。

按名称在当前可用技能目录定位并读取对应 SKILL.md；无需用户逐个重输命令。只加载选中路径需要的技能。若通过本仓库文件访问，先解析本技能所在目录的实际路径，再以 skills/ 为根定位下列入口，以兼容分类目录与扁平 Junction 安装：

向下游传递规格或工单引用、已确认的决策与测试接缝、验收标准和用户限制。执行下游正文，不在这里复制其模板或用概述代替实际加载。依赖无法读取时，报告缺失的技能及受阻步骤。

• 所选流程需要跟踪器时，读取 docs/agents/issue-tracker.md 及其引用配置。若缺失，按下游要求提示用户运行 setup-matt-pocock-skills；准备不依赖配置的内容，暂停依赖跟踪器的发布与调度。
• to-spec / tdd 的测试接缝确认、to-tickets 的拆分确认沿用已有有效答案；确有新增待确认内容时，先展示具体方案，再按相应技能要求等待。说明该确认来自哪个 Skill 的哪条要求，回答后自动继续，无需重新批准整条路线。
• 实施阶段沿用 tdd 和 code-review 要求。顺序逐工单调用 implement 时，每次调用完成后审查；implement-spec 在各工单实施中测试，汇入后统一审查。
• Git 提交、发布及其他外部操作遵守用户和仓库的授权边界；调用本技能本身不覆盖这些限制。仅支持已提交差异的审查步骤若无法覆盖未提交改动，应明确报告覆盖限制，不为满足下游步骤擅自提交或声称已通过审查。

完成标准：所选流程的实现、验证和适用审查已完成。最终简述实际路线、交付结果、验证证据和剩余阻塞；仅生成规格或工单不代表实施完成。