图 01 · 功能流

一个模糊的功能需求如何变成可验证的小改动？

双泳道服务蓝图：上方是人工决策，下方是 Agent 工作流。每次交接都携带一个产物，防止信息在步骤之间丢失。

功能流双泳道服务蓝图 上方泳道为人工决策（意图、范围、验收标准、审查），下方泳道为 Agent 工作流（/grill-with-docs、/to-spec、/to-tickets、/implement、tdd、code-review），中间展示产物传递与 Triage 汇入点。 人工决策层（HUMAN DECISIONS） 意图定义 「我想做什么？」 业务目标与价值动机 范围边界 「改哪些模块？」 权衡取舍与非目标 验收标准 「成功是什么样？」 验证条件与边界行为 审查与批准 「批准合并上线」 PR 评审与最终签发 ── 人机协作泳道边界 ── Agent 工作流（AGENT WORKFLOW） [用户 / 工程] /grill-with-docs 澄清意图与建立共享词汇 底层使用 {grilling} 产物 · 仓库持久化 CONTEXT.md + ADR 决策 共享语言基础 [用户 / 工程] /to-spec 描述行为前置与后置条件 消除所有实现歧义 产物 · 规范 spec 确定行为契约 [用户 / 工程] /to-tickets 分解为带依赖边的工单 产出已是 Agent-Ready [用户 / 工程] /implement 按工单构建切片 不偏离已定 spec [Agent / 工程] {tdd} 红 → 绿 → 重构 先写失败测试 [Agent / 工程] {code-review} 双轴审查检查 规范合规 + 符合 spec 最终产物 已审查 diff 通过测试与规范 TRIAGE 汇入点（INCOMING WORK JOIN POINT） [用户 / 工程] /triage 外部原始工单分拣 ① 意图或领域词汇不明确 → 先走 /grill-with-docs ② 描述充分完整 → 直接进入 /to-spec ⚠ 边界规则：/to-tickets 工单无需再次 Triage /to-tickets 产出的工单自带依赖边和验收标准， 已经是 Agent-Ready，直接交给 /implement。

为什么流程是顺序的？

每次交接都携带一个产物。CONTEXT.md 让 /to-spec 不需要重新发现词汇；spec 让 /to-tickets 不需要猜测行为边界；工单让 /implement 不需要做范围决策。

关于 {grilling} 原语

五个 orchestrator（/grill-me、/grill-with-docs、/triage、/wayfinder、/improve-codebase-architecture）都在内部使用 {grilling} 来逐一挖掘未解决的决策分支。用户启动 orchestrator，agent 使用原语。

实例：TypeScript 实体库生命周期钩子

软件工程场景

「为 TypeScript 实体库添加生命周期钩子」→ /grill-with-docs 澄清"钩子"的触发条件 → CONTEXT.md 记录 lifecycle event 术语 → spec 描述 onMount/onUnmount 行为 → 3 个工单（接口、实现、文档）→ /implement → {tdd} → {code-review}

Triage 汇入示例

外部 Issue #142：「实体 activate 偶尔不触发钩子」→ /triage 分拣确认是有效 bug 报告 → 因缺少复现条件，走 /grill-with-docs 澄清 → spec 补充边界时序 → /implement 修复。

线性阅读顺序：用户提供意图 → /grill-with-docs 产出共享语言（CONTEXT.md + ADR）→ /to-spec 产出 spec → /to-tickets 产出带依赖边的工单 → /implement 按工单构建 → {tdd} 验证 → {code-review} 审查 → 已审查的 diff 准备上线。
相关技能
/grill-with-docs /to-spec /to-tickets /implement {tdd} {code-review} /triage {grilling}