Matt Pocock 的工作流：从一个模糊想法到可交付代码
内容提要
TypeScript 名师 Matt Pocock 开源了一套 Claude Code Skills，以五个命令构成主线：/grill-with-docs 逐个问题拷问想法并沉淀文档，/to-spec 综合成规范，/to-tickets 拆分为可独立演示的垂直切片票据，/implement 按票据进行 TDD 实现，/code-review 从编码标准与规范符合度两条轴并行评审。其核心是将“想清楚”与“写代码”分为两段：前三步只做认知对齐，后两步才动手实现。
延伸解读
为什么先“想清楚”再“写代码”
这套流程把开发分成两段：前三步（拷问、规范、拆票）不写代码，只做认知对齐；后两步（实现、评审）才动手。这样做的目的是避免在需求模糊时过早编码，导致返工。文章强调，想法越模糊，越应该从 /grill-with-docs 起步，而不是直接开工。这种分离有助于团队在动手前对齐目标，减少实现偏差。
垂直切片与示踪弹：拆票的关键
to-tickets 要求每张票是一个“示踪弹”式的垂直切片：窄而完整，贯穿数据库、API、界面和测试，能独立演示。这与水平横切（先建所有表、再写所有接口）不同，后者在拼合前无法验证。垂直切片确保每完成一个切片就能跑通一条链路，降低集成风险。拆票时还遵循“扩展-收缩”原则处理大重构，先让改动变容易，再做容易的改动。
双轴评审：标准与规范分开
code-review 用两个并行子 Agent 分别评审：标准轴检查代码是否符合仓库编码规范和 Fowler 的十二种代码异味；规范轴检查代码是否忠实实现最初的 issue 或 PRD。两条轴独立运行，不合并结果，避免“代码写得漂亮”掩盖“做错了事”。这种设计让评审更全面，既关注实现质量，也关注目标一致性。
wayfinder 与 grill-with-docs 的分工
wayfinder 处理又大又模糊、一个会话装不下的目标，在 issue 跟踪器上建立调查地图，拆解子问题并管理依赖，产出决策而非交付物。grill-with-docs 则针对已聚焦的想法，在一个会话内通过一次一个问题的访谈拷问计划，并沉淀文档。两者互补：想法越模糊庞大，越应从 wayfinder 起步；想法已明确，直接进 grill。
Q&A
Matt Pocock 的 Claude Code Skills 主线包含哪五个命令？
主线五个命令依次是：/grill-with-docs、/to-spec、/to-tickets、/implement、/code-review。
这套工作流为什么要把“想清楚”和“写代码”分成两段？
前三步（/grill-with-docs、/to-spec、/to-tickets）几乎不写代码，只做认知对齐；后两步（/implement、/code-review）才动手实现和评审。这样能确保在编码前把想法和结构定清楚，避免盲目开工。
wayfinder 和 grill-with-docs 有什么区别？
wayfinder 处理又大又模糊、一个会话装不下的项目，在 issue 跟踪器上建地图和子 issue，产出决策；grill-with-docs 处理一个会话内已明确的想法，通过访谈拷问计划并沉淀文档。两者互补，wayfinder 在上游。
to-tickets 拆出的“示踪弹垂直切片”是什么意思？
示踪弹垂直切片是一条从头贯通到尾的最小垂直切片，范围窄但贯穿 schema、API、UI、测试所有层，能单独演示验证，粒度小到能塞进一个上下文窗口。
code-review 的双轴评审具体指哪两条轴？
第一条是标准轴，检查代码是否符合仓库编码规范，并参考 Fowler 的十二种代码异味；第二条是规范轴，检查代码是否忠实实现最初的 issue 或 PRD。两条轴由不同子 Agent 并行执行，互不干扰。
implement 步骤中 TDD 和测试运行有什么要求？
能用 TDD 的地方就用 /tdd，只在事先约好的接缝上写测试；类型检查要频繁跑，单个测试文件时不时跑一遍，整个测试套件留到最后跑一次。写完后自动调用 /code-review 再提交。
