最近在用 Matt Pocock 的 Skills 做开发。先用 grill-me 把需求讨论清楚，再通过 to-spec、to-tickets 整理规格、拆成 GitHub Tickets。
我很喜欢这种方式：先想清楚要做什么，再让 Agent 动手。
但任务拆完以后，还有一段工作需要自己反复操作：让 Agent 开始开发、检查结果、跟进修复、处理 PR，然后继续下一张 Ticket。
任务已经在 GitHub 上了，依赖关系也有了，这些步骤能不能自动推进？
于是我做了 grill-engineering。
把拆好的任务交给 Codex，自动往下做
grill-engineering 接着 Matt Skills 的工作流往下执行。
配置完成后，一条命令启动，程序会按任务依赖调用 Codex 开发。开发完成后，对照需求验收；发现问题，就交回开发修复，再次验收。
整个过程是一个循环：
开发 → 验收 → 修复 → 再验收。
PR 创建、等待 CI 检查、合并子任务、继续后续任务，也由程序处理。
为什么把验收放进这个循环？
因为 Agent 报告“完成”，不一定意味着结果满足要求。有时会漏掉需求，有时修好了一个地方，又影响了原来的功能。如果只是连续执行任务，检查和返工还是会落回人身上。
所以我希望自动推进的同时，也能把发现的问题交回开发，继续修复。
自动推进，但保留人工决定的地方
程序会处理能够继续执行的步骤。遇到需要人做决定的情况，或者修复达到次数上限时，会暂停并保留已有工作。
最终交付仍然需要维护者批准合并。
对我来说，这个工具想减少的是开发过程中的重复协调：安排下一张任务、转交验收结果、跟进修复、等待检查。需求怎么定、结果是否接受，仍然由自己决定。
运行到哪一步，可以直接看
长时间运行的任务，我比较关心两个问题：现在做到哪了，以及中间发生过什么。
status 用来看当前任务和运行进度：
history 用来看每轮开发、验收、修复和合并记录：
这样需要查看进度或处理暂停时，可以先了解当前状态，再决定怎么继续。
怎么开始用
如果你已经在用 Matt 的 grill-me 系列 Skills，可以沿用现有方式讨论需求、拆解任务，再让 grill-engineering 接手后面的开发过程。
仓库提供了中文 README，也单独整理了面向 Agent 的安装和操作指南，可以把指南交给 Agent，让它协助检查环境和完成配置。
项目采用 MIT 协议开源。工作流配套 Matt Pocock Skills，设计上也借鉴了 Peter Steinberger 的 ClawSweeper，感谢他们公开分享自己的工作。
如果你也习惯先把需求拆成 GitHub Issues，再交给 Agent 开发，欢迎试试：
