Grill Test 是一条面向代码任务的组合式技能链路，适用于用户明确选择此组合的场景。它由四个阶段组成，每个阶段都加载对应的原始 Skill 执行，不修改原 Skill 文件内容。
一、grill 阶段 加载固定的 grill-me 原文，执行 grilling 会话。环境事实由子 Agent 调查，实际决定询问用户并等待回答，frontier 为空后请用户确认共同理解。会话摘要回传 SDK grill Action，通过 confirm-understanding Wait 保存确认。此阶段不创建 brief 或其他业务文档。
二、to-spec 阶段 读取 to-spec 原文，综合已确认的会话和代码事实，不再次访谈已有决定。按原模板七个章节生成第一份正式文档，确认测试 seams，发布至本地 tracker 的 .scratch/grill-test/spec.md，通过 confirm-spec 保存确认。
三、to-tickets 阶段 读取 to-tickets 原文，展示 tracer-bullet 切片、粒度和 blocking edges，取得用户决定后按原模板一票一文件写入 .scratch/grill-test/issues/，使用 ready-for-agent 标签。tickets.json 仅作为实际文件和依赖的核对索引。通过 confirm-tickets 保存确认。
四、implement 阶段 根 Run 的 authorize-implementation 获批后，读取 implement 原文，按已批准票据实现，使用 tdd 在约定 seams 验证，执行相关检查与最终完整业务测试，按 code-review 原文开展 Standards/Spec 双轴子 Agent 审查，只在隔离项目本地提交。implementation.json 是应用的执行记录。
使用方式 通过 comet runtime dispatch 命令启动流程，使用 --application-file 指定本目录 application.json，--project-root 指定项目路径，--request 传入临时 JSON。查询和恢复使用 --application grill-test 与原 Run ID。输入包含 goal、acceptance 数组和 testCommand 数组，本地 tracker 由用户事先选择。所有业务检查使用原测试命令，验证器只读检查结果，独立 Eval 另外运行原始测试。
限制 获批 Spec 与票据在实现阶段保持只读。真实批准或 Skill 能力缺失时停在当前步骤并保留原 Run。只使用当前 Action/Wait 身份，不伪造会话回答、批准或成功状态。凭据仅留在执行环境。本应用不授权远端 Issue、PR、推送、发布或真实消息。宿主无法加载固定版本时阻塞并保留原 Action。只有实际 SDK 根 Run completed、业务测试通过且评审证据可查，才能报告业务任务完成。