技能介绍

它解决什么问题

把一个需求变成可验证的代码，中间要穿过好几道坎：需求没想清楚就动手，改到一半发现方向错了；上下文越积越长，AI 写到后面开始遗忘前面的约束；改完了不知道质量如何，只能肉眼扫一遍就提交。matt-flow 的价值在于，它把 Matt Pocock 的一组编码技能串成一条有状态的工作流，每一步都有明确的完成标志，每张 ticket 都在独立上下文里实现，用 git log 而不是记忆来判断进度。

它如何工作

入口是一个状态检查：当你调用 /matt-flow [project-dir] 时，它会扫描项目当前处于哪个阶段，然后直接跳到对应入口。

init：新项目没有 git 也没有 scratch，问你是否初始化。
grill：没有 ticket，需要先想清楚做什么。
implement：已有未完成的 ticket，进入自动实现阶段。
review：所有 ticket 都完成了，进入验收。

Phase 1 是需求收敛。 通过 /grill-with-docs 反复追问，产出 CONTEXT.md（领域术语表）和可选的 ADR。这一步的完成标志是文档存在且你明确表示"理解了"。然后做分支决策：改动足够小（大约一个 ticket，~100K tokens）就直接实现跳到验收；改动大就进入下一阶段。

Phase 2 是拆解。 /to-spec 把需求写成 scratch/SPEC.md，包含问题陈述、用户故事、验收标准和实施决策；/to-tickets 再拆成多个 ticket，每个 ticket 约等于一个 context window，写到 scratch/tickets/NNNN-name.md。

Phase 3 是自动实现，有两条路径。 推荐路径是一个脚本：按顺序读 ticket 文件，用 git log 跳过已提交的，加载 Spec 和 Ticket 上下文实现，跑项目自身的类型检查/构建/测试，然后调 pi 子进程做 Code Review（双轴审查：对照 Spec 和对照代码标准），通过就 git commit，失败重试最多 3 次。手动路径则逐条加载上下文、实现、审查、提交，每次完成后清空上下文。

Phase 4 是验收。 展示这批成果，讨论失败的 ticket，问你继续下一批还是结束。

适用边界

这套流程对项目自身的检查和测试体系有依赖——Phase 3 需要项目里有能跑的类型检查、构建和测试命令，否则验证步骤没有意义。自动路径依赖脚本执行环境，手动路径则要求你自己守住"每个 ticket 后清空上下文"这条纪律，否则还是会退化成上下文膨胀。重试 3 次仍失败的 ticket 会停下来等人处理，它不会绕过人工。另外它预设你愿意把进度记录在 git commit 里，不提交就无法判断哪些 ticket 已完成。