你好呀，我是歪歪。
这篇文章想给大家分享一套我最近一直在使用的 skills。
这套 skills 关于怎么把一个想法更好的通过 AICoding 的方式落地。
这套 skills 在 github 上已经有 176k 的 star 了，算的上是经过市场验证的明星产品：
这个仓库是一个叫做 mattpocock 的哥们搞出来的。
我看到这个哥们照片的时候就感受到了一股浓烈的强者气息：
这个哥们在 youtube 上有自己的视频账号：
围绕着这个仓库，他也录制了很多视频。
他的很多视频也被搬运到了 B 站。
这个哥们在前两天也专门录制了一期叫做“mattpocock/skills: A complete AI Coding workflow, end-to-end（一套完整的 AI 编程工作流程，端到端解决方案）”视频，对这个仓库进行了介绍。
这个视频是 7 月 16 日上传的，当时介绍的时候还是在 skills.sh 上有 750w 的下载：
我写这篇文章的时候，是 7 月 18 日。
下载数据量已经来到了 960w：
说不定等你看到这篇文章的时候已经突破 1000w 了。
安装
关于如何获取和安装这个 skills 仓库，在 github 上已经说的很清楚了，我就不赘述了。
主要提醒几个视频里面提到了，但是 github 上没有的事情。
比如，你通过 npx 命令安装这个 skills 的时候，会遇到一个问题：
npx skills add mattpocock/skills
除了主要的 Mattpocock Skills 技能外，你会看到还有一个 other 分组：
这个 other 分组是作者正在尝试使用的一些技能，将来可能会被删除，所以你可以先不关注这一组 skills：
安装完成之后，这一套 skills 在 context 里面只占用了 660 tokens。
这个占比和其他的 skills 比起来已经算是超级小的体量了：
从视频中这个哥们傲娇的小表情来看，对于这个事情，他觉得挺骄傲的。
最后这一步 /setup-matt-pocock-skills 别忘记了：
这一步可以做一些与开发相关的设置，比如以什么形式进行问题跟踪、哪些关键词可以触发相关的技能等等。
这一步需要在具体的项目里面执行。
比如，我在一个空目录下执行，那么它就会给我产生这些文件：
组合拳
这个仓库里面有很多的 skill，其中用户主动触发的是这些：
这些 skill 每个都能单独使用。
但是当这些 skill 形成一套 AI Coding 组合拳，用起来就更加有威力了。
作者给出的组合拳套路是这样的：
这一套组合拳其实已经是 v1.1 版本了。
你可以看一下 v1.0 版本的组合拳是这样的：
我就是从 v1.0 阶段开始使用的，当时觉得已经很好用了。
v1.1 版本，是 7 月初发布的。
我使用了两周时间，我觉得这个版本确实更加厉害，使用起来也更加顺手。
接下来介绍一下这一套组合拳里面，每个 skill 的功能。
grill-with-docs
使用这个技能，就是和 AI 进行多轮对话，AI 通过“拷问”的方式，把需求聊的明明白白。
同时，在这个过程中可以进一步明确各种术语的含义，然后会及时更新到 CONTEXT.md。
过程中如果有涉及到架构决策相关的讨论也会留下，也会记录下来。
正式术语叫做 Architecture Decision Record，简称 ADR。
如果想要工程性的使用 AICoding，那么 ADR 是非常重要的一部分，因为 AI 在写代码之前，还需要掌握历史决策、设计原因、不能随便改变的约束，以及一些不能从代码中推导出来的业务背景。
grill-with-docs 的“前身”叫做 grill-me。
当我第一次接触到 grill-me，看到它的完整内容的时候，我整个人都惊呆了。
震惊程度是属于我甚至想单独为它写一篇文章的程度。
现在的版本，这个 skill 的全部内容，一共也才八句话：
而我第一次使用这个技能的时候，两三个月前吧，那个时候，这个技能总共只有三句话：
在当时一众特别“臃肿”的 skills 中，它就是一股清流。
极简的同时，还挺好用，它真的可以通过一步步追问的方式，帮你把问题或者需求梳理清楚。
这叫啥玩意？
这玩意就叫做大道至简。
给你看一下实际使用场景。
我用之前写 openSpec 时候的音乐节的案例，来进行演示。
首先，我直接把之前的问题搬运过来：
/grill-with-docs 我要做一个网站，网站可以生成“看过的乐队演出”的海报。在网站上可以输入具体的音乐节名称，时间，以及有哪些乐队，然后生成一张具有设计感的海报。比如，我2026 年5月看了草莓音乐节，有这些乐队：棱镜，马赛克，夏日入侵企画，DOUDOU，梅卡德尔，声音碎片，逃跑计划，痛仰。
grill-with-docs 或者 grill-me 的核心工作准则之一就是一次只会问一个问题。
每问出一个问题，它还会给出自己的推荐答案以及推荐理由。
比如它问出的第一个问题是这样的：
其实我的本意是想要选择一次展示多个乐队的，但是我又想起我也看过一些乐队的专场，所以我选择了“两种都支持”。
接着第二个问题是这样的：
询问我用户范围，到底是单用户还多用户。
它推荐选择单用户，并给出了三个理由。
于是我选择了单用户这个选项。
第三个问题是：海报怎么"生成"
按照它的建议，我选择了方案 C。
然后，它会提示我出现了一个冲突：
你刚才选了"零后端"，但 C 方案里"AI 生成主视觉"通常需要调用外部图像 API（比如 DALL-E、Flux）
它需要我的决策来帮它解决冲突。
我这里选择了“模板为主 + AI 可选（自带 key）”的方式。
接着来到了第四个问题，确认海报上展示的字段：
按照它提出的问题，我依次回答了
performers 有顺序、支持自定义 mood 色板、只记"我去的那天"的乐队、用户可以上传一张自己拍的现场照
后续的问题我就不一一展示了。
只展示一些我觉得值得体现一下的问题。
比如第八个问题，它要把 “AI 主视觉”这个模糊的词聊透。
要让它明白 AI 到底要承担海报里面的哪些部分：
第 15 个问题，问的是我关于“日期格式 + 时间精度”的问题：
在问我要给这个产品取什么名字的时候，我写的是“歪歪和 Max 的音乐记忆”。
这个时候它敏锐的察觉到了这是两个人，和最开始的单用户出现了冲突。
于是它再次让我进行冲突解决：
最后，经过 20 个问题的“拷问”后，我们完成了需求的确认：
这就是 /grill-with-docs 的功能演示。
在所有问题问完之后，你再去看项目中的文件，你会发现有了一些变化。
比如，CONTEXT.md 文件中多了“术语”解释：
ADR 目录下也多了几个“架构决策”：
/to-spec
接下来就是组合拳的第二招“to-spec”的表演时间了。
直接调用 /to-spec 技能，它就会基于我们前面讨论的需求，自动整理成一份结构化的 Spec 文档。
规范文档放在这个路径下： .scratch\music-poster\spec.md
整个文档好几百行，分为这几个章节：
这几个章节的内容，总结起来就是这样的：
- Problem Statement：描述要解决的问题，以及为什么需要这个功能。
- Solution：描述整体解决方案和功能流程。
- User Stories：使用用户故事的形式明确具体需求，让 AI 理解“谁、要做什么、为什么做”。
- Implementation Decisions：记录技术实现方案，包括架构设计、技术选型、数据模型以及关键设计约束。
- Testing Decisions：明确测试范围、测试策略以及核心测试边界。
- Out of Scope：明确当前版本不做什么，避免 AI 自行扩展需求。
- Further Notes：补充优先级、风险以及未来演进方向。
简单来说，/to-spec 做的事情就是把已经讨论明确的需求，转换成一份结构化、可执行的软件开发规范。
后续就可以基于这份 Spec 完成代码实现。
现在有了明确的计划，接下来上场的就是 /to-tickets，把计划拆分为详细的任务。
/to-tickets
直接调用 /to-tickets 就可以把我们的 spec.md 拆分为一个个具体的任务。
一共拆成了 12 个小任务：
每个任务里面都有多个小任务：
/to-tickets 还会贴心的告诉你，这些任务之间的依赖关系，哪些任务可以并行启动：
把任务拆分好之后，接下来就到了代码实现环节。
也就是该 /implement 上场表演了。
/implement
在执行 /implement 之前，还有一个小技巧。
也是我在这个哥们的视频里面学到的：
当你有了详细的任务之后，在进入编码实现之前，你可以做一次 /clear 的操作，把当前的上下文给清空，给后续的编码实现环节留下足够的上下文。
执行完 /clear 操作之后，可以使用 /implement 去逐个实现每个 issues：
也可以一把都给到 /implement 让它逐个实现：
剩下的就是让它慢慢跑着。
从 github 上看，/implement 其实是一个组合技能：
里面使用了 /tdd 做代码实现和 /code-review 做代码评审。
也就是说在 /implement 搞完之后，你不需要再主动调用 /code-review 做代码评审了。
它闷着头搞了一个多小时后，最后成品的核心功能就长这样：
如果我要修改，比如我想要在输入表演者的地方支持批量输入，以逗号进行分割。
再次从 /grill-with-docs 开始使用即可：
在这个过程中，如果有值得记录下来的技术决策，它也会主动提醒落下来：
最终又会在 .scratch 目录下新生成一个目录，里面新生成一套 spec 和 issues：
/wayfinder
如果说前面 /grill-with-docs 是 /grill-me 的升级版。
那么 /wayfinder 就是再次升级版本。
作者自己也非常喜欢这个命令，甚至为这个命令单独录制了一期视频：
那么 /wayfinder 和 /grill-with-docs 之间的区别是什么呢？
根据作者表达的意思来说，/wayfinder 是帮你找到正确路线，是一个探索和规划的动作。
/grill-with-docs 是审问你已经有的方案，确保方案和已有项目知识一致，属于验证和沉淀。
而且作者在视频里面的一句话提醒了我，大概意思是他在一些非技术的场景也会使用这个命令去探索实施路径。
基于他的这个提醒，我也计划用它来探索一个和技术无关的事情，跑步。
/wayfinder 我现在10km能跑45分钟，想要在3个月后跑进40分钟，我应该怎么做？
首先，它对我进行了一些基础询问，比如目前的跑量和跑步经验，让它知道我是小白还是老手。
还询问了每周能跑几天，方便制定具体的计划：
另外，你可以在输出内容里面看到 grill 关键词。
收集到这些基础信息之后，它给出了一个“整体路径”的路线图：
我们先看看它现在给我们的输出。
这是 map.md 的内容：
里面有一个章节是“not yet specified”，即尚未明确的内容。
生成的这 7 个子任务，就是围绕这些尚未明确的内容展开：
从前面的路线图我们可以知道，01 和 04 是整个任务的起点。
所以我们可以分别看一下这两个子任务。
01 是对用户的一些基础信息的进一步询问：
04 是依据什么模型，推导出配速区间：
站在我多年的跑步经验上来看，01 和 04 之间确实没有直接的关联关系。
接着我从 01 开始继续 /wayfinder，它会继续追问我一系列问题：
甚至是细到了跑鞋服役公里数的维度：
01 询问完成后，它也会主动去更新对应的 md：
基于前面跑鞋的问题，我选择的是大于 600km，于是它给我追加了一个换鞋的任务：
在用 /wayfinder 执行“换鞋”任务的时候，它基于我的选择，给我推荐了几双跑鞋。
还建议我不要买碳板竞速鞋。
最后，经过了一轮又一轮的对话，不断深入的掌握了我当前的情况和对最终目标的明确，在 31 个问题之后：
它给出了这三个月，一共 12 周的完整训练计划：
以及对应的恢复计划与营养安排：
此外，还有很多其他的关键输出，比如配速区间、进度观察等，由于篇幅原因，我就不一一截图了。
此时，我们再去看 map.md，你就会看到：
之前所有的待定点都完成了：
而上面产生的所有的文档，都是从这个模糊的问题开始：
/wayfinder 我现在10km能跑45分钟，想要在3个月后跑进40分钟，我应该怎么做？
所以，思路打开，遇事不决，就用 /wayfinder 来帮你梳理思路。
可以是技术上的思路。
但是也不止于技术上的思路。
它解决的其实不是“答案在哪里”，而是“我应该如何一步步找到答案”。
希望这个案例也能打开你的思路。
如果你感兴趣的话，不妨找一个小需求，打一遍这套组合拳。
好了，收工。
