Matt Pocock 推荐的三位 skill maker，分别在教 agent 什么

Matt Pocock 最近推荐了三位 skill maker：Lauren Tan（@poteto）、Dex Horthy（@dexhorthy）和 Emil Kowalski（@emilkowalski）。原话很短：

My top 3 skill makers:

• @poteto
• @dexhorthy
• @emilkowalski Always learn a ton from reading their skills.

我把三人的上游仓库和 SKILL.md 都翻了一遍。最直观的结论是：他们不是在做同一种 skill。Lauren 在教 agent 怎么做工程判断，Dex 在教团队怎么把 agent 变成可控的持续流程，Emil 在教 agent 怎么把界面做得像一个有经验的人。

先看 Lauren Tan 的 pstack：把“怎么工作”写成系统

Lauren Tan 的官方 pstack 在 poteto/plugins。README 的态度很明确：AI 写了太多 slop code，想快一点，应该先深入，而不是单纯追求行数。pstack 的目标是少写、更高质量，并让经过验证的 agent 可以放心并行。

它的总入口是 /poteto-mode。你给它一个任务，它先打开 todo，读取原则索引，再把任务路由到 playbook。仓库当前列了 investigation、bug fix、perf、runtime forensics、feature、prototype、visual parity、eval、autonomous run、session pickup、multi-phase plan 等 15 个 playbook。

这个设计解决了一个常见问题：每次对话都重新发明一套工作方法。任务不再只是“改一下这个文件”，而是先判断这是调查、修 bug、性能问题，还是一项需要长时间运行的迁移。

几个值得直接读的 skill

/how 解决“我知道文件在哪里，但不知道整个系统怎么走”的问题。简单问题由一个 agent 探索；跨多个模块的问题会拆成 2 到 4 个探索角度，再由 explainer 汇总。它甚至有 critique 模式，让多个模型独立找架构问题。见 pstack/skills/how/SKILL.md 和独立仓库 poteto/how。

/why 则专门查设计动机。它会枚举可用的证据源，覆盖 git、工单、长文档、团队聊天、观测、错误追踪和产品分析。这个区别很重要。代码能告诉你“现在怎么跑”，通常不能单独证明“当初为什么这样设计”。

/architect 要求先写调用方用法、类型、签名和模块边界，再实现。/arena 对同一个任务并行生成多个候选，交叉评审后选一个 base，再把其他候选的好点子 graft 进去。/interrogate 则让多个模型用同一个 rubric 来拆 diff，最后区分共识、单点意见和误报。

这套 stack 还很在意“做完之后留下什么”。/show-me-your-work 用 TSV 记录决策、理由、证据和结果。/tdd 在测试路径便宜时先写失败的回归测试。/unslop 处理 AI 腔，不只删掉废话，也要求文字有判断、有具体细节。

Noodle、brainmaxxing 和验证示例

Lauren 的仓库不止 pstack。

• Noodle 是 skill-based agent orchestration。skill frontmatter 里的 schedule: 决定它是否进入自动调度；没有 schedule: 的 skill 还是手动调用。调度器读的是自然语言条件，例如“backlog 有新条目”或“一个 session 完成之后”，而不是一堆脆弱的 cron 表达式。
• brainmaxxing 是一个放在 brain/ 里的 Markdown 记忆库。/reflect 记录会话中的经验，/ruminate 从历史对话里挖漏掉的模式，/meditate 清理过期或互相矛盾的记忆，/plan 和 /review 使用这些原则做结构化工作。
• verification-skill-example 是一个明确写着 “Private reference” 的虚构示例。它展示如何为大型桌面应用建立按 feature 划分的行为地图，要求 agent 记录入口、驱动方式、常见陷阱和证据。它不是一个真实的 Atlas 产品，也没有提供实际 CLI。

如果你想读一套“工程方法论”，先读 pstack；如果你想理解自动调度、持久记忆和行为级验证，再读 Noodle、brainmaxxing 和 verification example。

Dex Horthy 的 HumanLayer skills：把 agent 放进控制回路

Dex Horthy 的集合来自 humanlayer/skills。安装方式是：

npx skills add humanlayer/skills --skill SKILLNAME

它和 pstack 的差别在于关注点。HumanLayer 更关心“一个 agent 任务怎样变成可重复、可观测、可被人校准的流程”。最典型的词是 control loop：set point、sensor、controller、actuator，以及代码库之外的 disturbances。

show-me：解释也要有形状

plugins/show-me/skills/show-me/SKILL.md 要求选择最小的视觉表达：算法用伪代码，运行时用 call tree，组件关系用 component tree，数据流用 Mermaid；太密的 UI 或状态比较，再生成一个聚焦的 HTML 文件。

它修的是解释方式的问题。很多 agent 的回答并不是事实错，而是把所有东西写成一段长 prose。show-me 强迫回答者把所有权、顺序和边界露出来，而且只展示当前问题需要的那一小块。

design-control-loop：先测量，再自动化

design-control-loop 不提供一套固定脚本。它先读仓库，再和用户一起定义：

• set point：想把什么属性推到什么目标；
• sensor：如何稳定测量当前差距；
• controller：每轮选多大的下一步；
• actuator：哪个 coding agent 和 repo-local skill 执行；
• disturbance / dampener：什么会让目标倒退，是否需要回归门禁。

这个顺序很实用。没有 sensor 的“自动修质量”只是愿望，没有 controller 的定时任务会一次改太多，没有 dampener 的循环会被队友的并行提交轻易冲掉。

build-iterated-agentic-loop：让每一轮都能被 review

build-iterated-agentic-loop 把上面的思路落成文件：repo-local SKILL.md、GitHub Actions workflow、agent-memory、prompt 和 references。它要求先让 sensor、controller、actuator 在本地分别跑通，再接 CI。

它还建议每个 loop 默认最多保留一个开放 PR。定时任务遇到已有 PR 就 no-op，手动 dispatch 可以绕过限制。这个小规则解决了很现实的问题：自动化速度超过 review 速度，最后仓库里积的是未读 PR，不是质量。

其他很具体的技能

narrow-react-prop-types 只认真实生产调用点，不因为 Storybook、测试或 mock 方便就保留 optional props。它会把 onRename?.(...) 这类潜在空操作收紧为必需回调，同时删掉只为宽类型存在的 ?? []、?? 0。修的是“类型描述了一堆线上根本不存在的状态”。

visual-pr 用结构化视图写 PR，不鼓励逐文件 changelog。improve-claude-md 则用 <important if="..."> 把条件规则包起来，保留项目地图和命令，把 linter 能保证的样式规则删掉。两者都在做同一件事：减少 reviewer 和 agent 的阅读负担。

Emil Kowalski 的 skills：把设计品味写成可执行规则

Emil 的 skills 仓库 面向 designers 和 engineers。README 直说，agent 没有很好的 taste，容易在 easing、border、shadow、组件库和微交互上做出“能用但不对”的选择。

这是一套很窄但很深的技能。它不负责帮你拆一个后端迁移，而是把最终用户看到的那几百个小判断写成规则。

animate：先判断该不该动

skills/animate/SKILL.md 的第一步不是挑曲线，而是判断动画的频率和目的。每天触发上百次的键盘动作不该动画；偶发的 modal、drawer、toast 才有标准动画预算。说不出这是 feedback、spatial consistency、state indication、preventing a jarring change、explanation 还是 rare-tier delight，也不要写动画。

后面的规则同样具体：优先 CSS transition，再考虑 @starting-style、CSS animation、WAAPI 和 Motion；尽量只动 transform 与 opacity；进场不用 ease-in；不要 scale(0)；UI 动画通常保持在 300ms 内；reduced motion 和 hover gating 必须和实现一起交付。

这套规则修的是“动画是装饰”的误解。它把动效当作信息设计和性能问题来处理。

review-animations、improve-animations、find-animation-opportunities

• review-animations 用严格清单审查已有动效，抓 transition: all、ease-in 进场、scale(0)、缺少 reduced motion 等问题。
• improve-animations 只读扫描整个代码库，输出带精确参数和文件路径的优先级计划。它明确不改源代码，避免“审计者自己修自己”。
• find-animation-opportunities 同时找“值得加动画”和“明确不要动画”的位置，防止团队把动得更多当成体验更好。

Web 之外的设计判断

animate-expo 把同一套标准带到 React Native / Expo，但多了一条硬约束：动画要留在 UI runtime，不能在手势或滚动里每帧 setState。它还覆盖 Reanimated、gesture handler、haptics、safe area 和真实设备验证。

pick-ui-library 防止 agent 手搓 toast、dropdown 这类组件。prototype 要求做多个版本再用切换器比较。mobile-native 处理 100vh、tap highlight、输入框缩放和 safe area 这些网页在手机上经常漏掉的小问题。

三套东西放在一起看

你在解决什么	更适合先看谁	代表入口
复杂工程任务怎么调查、设计、实现、验证	poteto	/poteto-mode、/how、/architect
重复任务怎样每周自动跑，又不淹没 review	HumanLayer	/design-control-loop、/build-iterated-agentic-loop
动画和交互为什么总有一点廉价感	Emil	/animate、/review-animations
生产类型为什么比 Storybook 更宽	HumanLayer	/narrow-react-prop-types
需要同时比较多个 UI 方案	poteto 或 Emil	/arena、/prototype
需要留下可审计的决定轨迹	poteto 或 HumanLayer	/show-me-your-work、agent-memory + PR

相同点

三套集合都把经验写成可复用文件，都拒绝“代码生成成功就算完成”，也都把不该做什么写得很具体。它们还都在控制上下文成本：poteto 用 playbook 和 reference，HumanLayer 把长期反馈放进 memory，Emil 把动画 recipe 和 audit 分开。

不同点

poteto 的单位是“一次工程任务”。HumanLayer 的单位是“一轮可重复的控制回路”。Emil 的单位是“一个用户能感知到的界面决策”。

所以它们是互补的。一个实际组合可以这样排：先用 poteto-mode / how 搞清楚代码和数据流；如果这类改动会反复发生，再用 HumanLayer 把测量、agent 和 PR 流程接成 loop；如果改的是 UI，最后用 Emil 的 animation review 或 mobile-native 规则做体验门禁。

不要一口气全装。先选一个入口，看它产生的 artifact 有没有真的进入团队流程。没有被 review、被复用或被维护的 skill，只是多了一个 Markdown 文件。

我的选型建议

• 你是工程负责人，最怕 agent 乱改架构，先读 poteto 的 poteto-mode、how、architect 和 interrogate。
• 你已经有 CI，想把重复性修复变成小步 PR，先读 HumanLayer 的 design-control-loop 和 build-iterated-agentic-loop。
• 你在做产品界面，想让 agent 少犯“细节上不对”的错误，先读 Emil 的 animate、review-animations 和 pick-ui-library。
• 你想建立长期记忆，读 brainmaxxing；你想把经验变成按状态自动运行的 loop，读 Noodle。

Matt 的推荐有意思，正因为这三个人的 skill 不是三份同样的 prompt。它们分别把工程判断、运行控制和设计品味变成了可以阅读、调用、审查和继续修改的东西。

参考链接

• Matt Pocock 的推荐推文
• Lauren Tan 的 pstack
• poteto/noodle
• poteto/how
• poteto/brainmaxxing
• poteto/verification-skill-example
• HumanLayer skills
• HumanLayer: show-me skill
• Emil Kowalski skills