我是怎么用grill-me的，Matt pocock技能库使用经验分享。

这段时间用mattpocock/skills搞了几个给自己用的小玩意，分享一点经验。

啥最好用

grill-me/grill-with-docs

王者grill-me/grill-with-docs再次上线。这技能强就强在“达成共识”四个字，如果你的需求太宽泛，是真的会问到你神志不清的。我试过几次前面一些问题都还是会认真看，后面就摆烂直接开启Yes工程师模式了。

但王者也需要注意一些点，grill-with-docs会记录文档，很好的设计，但文档在完成任务之后应该删掉，因为可能会与后续的需求产生冲突。我在WinTProxy（自己搞的一个Win平台透明代理）的重构就遇到了与文档冲突的问题。我想要用ndisapi取代WinDivert做数据包的捕获和改写以支持WSL和HyperV的二层NAT，但原有架构是多个Worker在三层做数据包的处理，当时留了个docs/adr文档，然后切换ndisapi就遭殃了，它工作在二层，然后NAT又会经过几个网卡，然后就重复捕获了好几次。

to-issues

这个技能的其中一个思想是很值得参考的，垂直切片。这要求任务划分是从端到端的划分，而不是层间划分。一个任务需要处理完一个需求从后端到前端的全部实现，有效反馈对于AGENTS来说是提效的一个重点。

diagnose

很好用的debug技能，上面那个问题最后就是用它找的，当然也算是我懒，主要是trace级别日志太多了，也懒得看。不过这个技能本身规范了一整套流程，有点啰嗦的。后来我自己改了一套更个人化的技能库，对这个技能就是砍掉了后面的修改和测试，只报告原因就行了，把修改和测试交给to-issues和tdd。

tdd

另一个王者，AGENTS时代大概tdd是最合适的了，要是再配上rust。什么叫做写完就结项？准确来说不是这个技能是王者，是测试驱动这种思想是王者。

啥我不用

这里列几个我不用的技能，不过mattpocock的技能库里面的engineering基本都很有用就是了。顺带一提，我自己魔改就是engineering剔除了triage，魔改了包括zoom-out在内的其他技能，然后加上了handoff做session交接。

前置配置的Issue tracker

并不是说不好用，只是我认为做本地的文档会方便一点。但Matt pocock原来设计就是维护github上的项目的，所以并没有什么毛病，也就开头配置时候多个选择而已。

triage

这是搭配上面的Issue tracker用的，你如果是本地文档，你大概率不会用这个。因为你不可能先写个文档描述issue，然后再丢目录里面去排序吧！真的有人这样做吗？

zoom-out

这玩意就一句话，直接写提示词都行，没有什么工作流程之类的，所以本质上只是方便一点。魔改的话可以让它做些数据流图啊之类的，更清晰一点。

一般咋用

grill-with-docs → prototype(optional) → to-prd → to-issues → tdd

improve-codebase-architecture → prototype(optional) → to-prd → to-issues → tdd

diagnose → tdd

这里面的prototype一般要新开一个session去完成，前后用handoff交接。

这个to-prd → to-issues很多时候是形影不离的，一开始我认为这两个就该合并，但后来实际开发中发现，有时候不会去写prd的，一个明确的需求就直接拆分任务了。这两个技能拆分是有道理的。

为啥用这

superpowers、trellis等这些其实都用过，有个共同的特点就是流程控制比较强，或者说比较重，穷鬼最喜欢省token了。

示例

举一个简单的例子来走完grill-with-docs → to-prd → to-issues → tdd这一套流程。这里先说明一下，我用的不是原版的matt pocock的技能，我是在他的基础上自己修改了一套，主要是强化了文档的交接等，所以截图中的链路是这样的：clarify → spec → slice → tdd。

grill-with-docs

我自己做了一个简单的翻译小工具TinyTrans，它现在的托盘菜单长这样。我认为它很丑，我想改掉。



于是，我直接来一句经典甲方语录。

“I want to optimize the right-click menu; it looks very ugly right now. Clarify it.”



然后，就开始拷问你了。这里因为是演示，所以我全程一路Accept，全部同意了它的建议。



然后它就问了几个问题。其实这个需求提得很变态，正常来说你稍微有点自己的想法，就会拷问得更多的。

to-prd

一旦拷问完成了，这意味着你和LLM就“达成共识”了，这是前文提到的很重要的一点，也是我认为的grill系列技能的核心。但这个时候，你跟LLM的共识是在当前对话形成的，这其实很有必要形成文档，所以接下来就是形成prd。

接下来的操作我就很傻瓜了，我全程跟着LLM的提示走。

这里也说明了一下，我自己魔改了技能强化了下一步推荐，原版没有这么强的关联性，能力强的模型比如GPT-5.5是能做到，但我自己实测下来，D老师的下一步推荐在原版上不是那么好使。





然后，这里有的佬友就要问啦，哎呀，我这个spec或者prd要不要自己审查一遍啊？

我建议你审！但是我不审，因为我懒。

另外还有一个原因，还是那四个字“达成共识”，本质上这个spec或prd就是你跟LLM对话的总结，我反正是达不到LLM的总结能力的。 ^-^

to-issues

当你审查完了prd，就要开始拆分任务或者原版中的issue了。



这里唯一需要注意的就是，你需要看一下是不是做了垂直切片。当然啊，这个事情还是具体问题具体分析。横向切片也不是完全不能接受的。

tdd

这里就没什么好说了，去干别的事，让LLM这个牛马跑就是了。它自己会RED/GREEN这种方式去鞭策自己的，过不了就自己打回重做了。狠狠地抽陀螺！ ^-^





最后的成品是这样的。额，D老师的品味一言难尽。 ^-^

写在最后

我认为现在的工作流构建什么的始终都是过渡产品。人总是懒惰的，等后续LLM的继续发展，这部分工作肯定是越来越少，希望这个过渡期短一点吧。