pstack 与 Matt Pocock skills 深度对比：一个把工程流程编成 23 个剧本，一个坚持每条技能只写 7 行

最近有两个研发技能库被反复提起：pstack 和 Matt Pocock 的 skills。它们都挂着「反对 AI 写 slop 代码」的旗号，都被叫作「给真正工程师的技能」，所以经常被放在一起问「哪个更好」。

我把两个仓库都拉下来读了原文（2026-10-20 的快照，cursor/plugins 在 ddf824a，mattpocock/skills 在 5beb35b，都是 --depth 1 拉的最新 main）。读完之后我的结论是：这两个东西不适合用「哪个更好」来问，因为它们在每一个关键分岔上都选了相反的方向。pstack 把一整套工程流程编成了技能，让技能替你选路线；Matt Pocock 把技能刻意做小，坚持路线必须由工程师自己拿。前者是「把流程交出去」，后者是「把流程攥在手里」。

先纠正一个流传的说法。很多地方（包括我最初看到的描述）说 pstack 的 README 自称 “Skills for Real Engineers”。实际上这句话只出现在 mattpocock/skills 的 README 标题里，我去 cursor/plugins 全仓库 grep 过，Real Engineer 一次都没出现。pstack 自己的标语是 “if you want to go fast, go deep first”。两个东西确实像，但别把口号也串了。

说明

本文的 star 数、版本号、贡献者数都是 2026-10-20 当天的读数。这类数字变得很快，看结论就好，别记数字。

它们分别是什么

pstack：一个资深工程师的工作方式，被编成了可执行剧本

pstack 的作者是 Lauren Tan（poteto），React core team 成员，参与维护 React Compiler，此前在 Meta、Netflix、Cursor 工作过。仓库位置是 cursor/plugins 里的 pstack/ 目录，它不是独立仓库，而是 Cursor 官方插件仓库里的一个插件（插件表里归类 Developer Tools）。

它的自我定位很直接：AI 写的代码太多了，而且质量不行。原话是「throughput without quality is not a goal i aspire to」，并且明确说目标不是提高代码行数，恰恰相反，pstack 的目的是让你写更少但更好的代码，然后给你「fearless parallelism」：当你敢把一件事交给一个 agent 并信任它的产出时，你才有资格谈并行。

规模上，skills/ 下有 56 个技能目录，其中 24 个是 principle-* 原则类技能；核心技能 poteto-mode 单独带了 23 个 playbook；agents/ 下还有 2 个 subagent（poteto-agent 和 comment-sicko）；另外有一个休眠的 automations 包（benny）。插件版本 0.15.28，MIT 许可（注意：MIT 是 pstack 插件自己的 LICENSE，cursor/plugins 仓库根目录没有 license 文件，仓库里其他插件不一定同样宽松）。

入口有三个：

• /setup-pstack：先跑一次，选推理预算（unlimited / large / medium / small），并给每个角色指定模型。它会写一份 ~/.cursor/rules/pstack-models.mdc 之类的 always-applied 规则。
• /poteto-mode：日常入口。你把任务丢给它，它读你的请求、挑一个 playbook、把 playbook 的步骤抄进 todo list，然后按步骤调用其他技能。
• /poteto-help：不知道用哪个技能时问它。

安装：Cursor 里 /add-plugin pstack；Claude Code 里 /plugin marketplace add cursor/plugins 然后 /plugin install pstack@cursor-plugins。Claude Code 用的是从 harness/pstack/ 生成的副本，由 CI 校验是否与源同步。

Matt Pocock skills：工程基本功，被拆成能改能组合的小文件

mattpocock/skills 是 Matt Pocock（Total TypeScript 作者，newsletter 约 6 万订阅）的独立仓库。体量上它是个庞然大物：297,563 star / 24,986 fork，只有 8 位贡献者，MIT 许可，2026-02-03 建仓，最新版本 1.3.1（用 changesets 管理）。

它的 README 花了很大篇幅讲「为什么要做这些技能」，而且是从四个失败模式倒推的：

1. agent 没做我想要的 → 用 /grill-me、/grill-with-docs 做前置对齐；
2. agent 话太多 → 用共享语言（GLOSSARY.md）压缩表达；
3. 代码跑不起来 → 补反馈回路（静态类型、浏览器、自动化测试，其中 TDD 的红绿循环是关键）；
4. 我们造了一坨泥球 → 把设计（深模块）放回每一天。

它最锋利的一段自我定位在 README 里：「GSD、BMAD、Spec-Kit 这类方案试图通过接管流程来帮你，但在这个过程中它们拿走了你的控制权，还让流程里的 bug 变得难以排查。这些技能刻意做小、易于修改、可组合，不绑定任何模型。」

目录上，它把技能分成 engineering/、productivity/、misc/、in-progress/、deprecated/ 五个桶。一共 38 个 SKILL.md，其中 27 个随插件发布（engineering 20 个 + productivity 7 个），misc/（4 个）和 in-progress/（7 个）刻意不发布。

入口是 /ask-matt（路由，告诉你哪个技能适合你现在的处境）和 /setup-matt-pocock-skills（每个仓库跑一次，配置 issue tracker、triage 标签、文档位置）。安装方式覆盖 Claude Code、Codex、GitHub Copilot、Gemini CLI，以及 npx skills 手动复制到任意 harness（Cursor、opencode、Devin、Windsurf、Amp、pi）。

一张表看清差距

维度	pstack	Matt Pocock skills
作者	Lauren Tan（poteto），React core team	Matt Pocock，Total TypeScript
仓库形态	cursor/plugins 里的一个插件目录	独立仓库 mattpocock/skills
热度（2026-10-20）	13,066 star（整个 cursor/plugins，pstack 无独立仓库）	297,563 star / 24,986 fork
许可	插件 MIT，仓库根无 license	MIT
技能规模	56 个技能目录（含 24 条原则、23 个 playbook）	38 个 SKILL.md（27 个发布）
入口	/poteto-mode	/ask-matt
谁决定流程	技能：mode 挑 playbook	人：技能是零件，流程自己拼
模型策略	按角色分工，默认 grok 写码 / opus 判断	显式模型无关
harness	Cursor 原生，Claude Code 走适配表	5 个 harness 原生支持，外加手动复制
版本节奏	插件 0.15.x，迭代很快	changesets，1.3.1，公开 PR 上千

方法论：把什么编码成了技能

pstack：一个「风格」（mode），加一套可命名的原则

pstack 的核心机制不是「一堆技能」，而是一个 mode。/poteto-mode 的 SKILL.md 开头就写了几条不可协商的规则，其中最重要的两条方法论信号是：

第一，playbook 是强制的骨架。 任务开始时要匹配一个 playbook，把它的步骤逐字抄进 todo list；某个步骤你决定不做，也必须留在列表里，并写一行 skip: <理由>。这让一次 agent 运行变成「按剧本走的、可审计的流程」，而不是模型自由发挥。

第二，原则是要被引用的。 回复里必须说出「哪个原则影响了这个决定，以及它具体改变了什么选择」，而且只能引用本次会话你真正读过的那些 principle-* 文件的原文。这条规则在防一件很具体的事：模型把原则名字当装饰品贴上去。24 条原则按组分成 core / architecture / verification / delegation / meta，名字本身就能当指令用，你可以中途甩一句 “apply principle-subtract-before-you-add” 让它换方向，这就是 README 里说的「用原则名来掌舵」。

在这两条之上，pstack 把验证和分工写成了默认值：

• 验证优先：principle-prove-it-works（对着真实产物验证，不是「能编译」）、principle-explain-the-number（在相信一个数字之前先找出它到底在测什么）、/benchmark-checklist（限速器、调参、误差、重复跑、端到端相关性）、以及两个会生成项目本地验证技能的命令（/create-verification-skill 和 /create-formal-verification-skill，后者做模型检查/形式化验证）。
• 分工优先：代码类委派默认给 grok-4.7-xhigh-fast，prose 和判断给 claude-opus-5-5-xhigh；/interrogate 的多模型对抗明确说「对抗信号来自模型多样性，而不是分配到的人设」；/arena 是同一任务开多个候选、选一个底座、把败者的强项移植过来；/swarm 是扇出 N 个 worker、收干、只回一份报告。
• 上下文纪律：principle-guard-the-context-window，把体量丢给子代理，主线程只留摘要。

Matt Pocock skills：一条主流程，加一张能撒谎的路由地图

Matt 的方法论更像「工程基本功 + 一台台小机器」。/ask-matt 的 SKILL.md 把整条路径画了出来：idea → ship 的主流程，加两条 on-ramp。

主流程是：/grill-with-docs（对齐）→ 需要可运行的答案就绕道 /prototype（用 /handoff 双向衔接）→ 多会话的活走 /to-spec → /to-tickets 拆成 tracer bullet 工单（每张声明 blocking edge）→ 用 /implement 逐张做（每张之间 /clear）或用 /implement-spec 一次做完整个 spec → /code-review → /pr → /retro 收尾。

这里有几个非常具体的工程约束，能看出它和「氛围编程」的距离：

• grilling 是设计树的遍历。 它把决策画成一棵树，每轮只问「前置已经定下来」的那批问题（frontier），一次问完，每题附上推荐答案，答完再算下一轮 frontier，直到 frontier 为空才算聊清楚。事实由 agent 自己查（派子代理），决策留给人。
• 上下文有硬纪律。 1 到 3 步必须待在同一个不被打断的 context window 里（别 compact、别 clear），直到 /to-tickets 之后；之后每张工单开新上下文。它还引了一个概念叫 smart zone（大约 150k token 以内模型还能锋利推理）。
• 工单是垂直切片，不是横切。 每张工单穿过所有层（schema、API、UI、测试），能独立演示或验证，尺寸正好塞进一个新上下文。宽重构是例外，走 expand → migrate → contract，并且声明「只有在最终的 integrate-and-verify 工单上才承诺绿灯」。
• 测试先谈 seam。 tdd 明确规定：写测试前先把要测的 seam 写下来跟人确认，没确认的 seam 不写测试。它点名三个反模式：实现耦合（重构就红，行为没变）、同义反复（断言是照代码重算一遍，等于用代码验证代码）、横向切片（先写所有测试再写实现，结果测的是想象出来的形状）。
• review 是双轴的。 /code-review 从固定点开始看 diff，Standards（这个仓库自己写的编码规范，外加一套 Fowler 气味基线）和 Spec（是否忠实实现了源头的 issue/spec）两轴各开一个并行子代理跑，避免互相污染上下文。仓库里写明的规范永远压过基线。
• 设计有自己的词汇表，而且带「已否决」清单。 /codebase-design 提供 module / interface / depth / seam / adapter / leverage / locality 这套词，给了三条判据（deletion test：删掉它复杂度是消失还是扩散到 N 个调用方；接口就是测试面；一个 adapter 是假缝，两个 adapter 才是真缝），并且在 “Rejected framings” 里直接否掉了 Ousterhout 把 depth 定义成「实现行数除以接口行数」的做法，改用 depth-as-leverage。
• 收尾改的是环境，不是代码。 /retro 输出的是导航指针、自动检查、编码规范、steering 文件、工具经济性。它的分类很干脆：机械违规变成确定性检查（lint、pre-commit、CI），只有真正的判断题才写进 CODING_STANDARDS.md。

两家共同的赌注，两种相反的下注

两边都相信同一件事：AI 编程的问题不是能力不够，而是没有纪律。区别在于纪律放在哪：

• pstack 把纪律放进技能里。你说目标，mode 选剧本，技能替你把步骤排好、把子代理派好、把模型分好。
• Matt 把纪律放进词汇表和工作流里。技能只提供一台台各司其职的小机器，串起来的那根线必须由你来牵，所以他先给你一张地图（/ask-matt）和一次配置（/setup-matt-pocock-skills）。

技能怎么组织：目录结构本身就是产品

这一节是全文最「工程」的部分，也是两个仓库差别最大的地方。它们都把技能的组织方式当成产品的一部分在设计，只是设计哲学完全不同。

维度	pstack	Matt Pocock skills
目录	单层 skills/*	五个桶：engineering / productivity / misc / in-progress / deprecated
层级语言	principle-<名字> 前缀 + 23 个 playbook 文件	桶 + promoted / 非 promoted 的发布等级
命名风格	动词或短命令：how、why、correct、unslop、swarm	工作名：to-spec、to-tickets、implement、wayfinder
调用权限	大范围 disable-model-invocation: true，由 mode 路由调用	user-invoked / model-invoked 是一等设计轴，两种 harness 各配一个开关
维护契约	guide 10 篇教程 + harness 适配表 + 生成副本的 CI 校验	AGENTS.md 规定发布义务：README 条目 + plugin.json + docs 页 + ask-matt 路由
版本与治理	插件版本号 + CI 同步检查	changesets + SCOPE.md 门槛 + .out-of-scope/ 记录拒绝项
附带代码	真带 TS 脚本（编排器、PR 监视器、计划校验器、bun.lock）	带 scripts/link-skills.sh 符号链接安装、scripts/list-skills.sh
分发	Cursor 插件市场；Claude Code 走适配表手工映射	Claude Code / Codex / Copilot / Gemini / npx skills 手动复制

几个值得单拎出来的点：

pstack 的「原则是控制接口」。 24 条原则每条一个文件，但平时不单独调用，poteto-mode 在开头把整份原则索引内联读一遍。这个设计的妙处在于：原则名成了一个你可以随时喊出来改方向的控制面，而全文又保证了可查证（只准引用会话里读过的原文）。

pstack 的技能会写代码。 poteto-mode/scripts/ 下有 orch.ts（编排状态）、watch-pr/ 一整套带测试的 PR 监视器、check-plan.mjs，还有 bun.lock。这不是「一堆 prompt」，而是一套会跑脚本、会盯 CI 的运行时附件。

Matt 的「谁可以调用」是硬契约。 他单独写了一篇 invocation.md：user-invoked 的技能只能由人打字触发，要在 frontmatter 里写 disable-model-invocation: true，并在 Codex 侧同时写 agents/openai.yaml 的 policy.allow_implicit_invocation: false，而且 description 是给人看的一句话，不允许写 trigger 列表；model-invoked 的相反。这是把「技能该不该被模型自己拿去用」上升成了一个必须显式声明的设计决策。

Matt 的文档是发布条件，不是附带品。 他的 AGENTS.md 规定：进 engineering/ 或 productivity/ 的技能必须在顶层 README 有链接、必须在 .claude-plugin/plugin.json 的 skills 数组里、必须有 docs/<bucket>/<name>.md 文档页（固定四节：What it does / When to reach for it / Common questions / It’s working if）、必须被 ask-matt 路由到。并且特别声明一条：ask-matt 是会撒谎的路由，任何一个技能改名、增删、改变用法，不更新它，就等于给用户一张错地图。

Matt 的治理反过来写「不做什么」。 SCOPE.md 立了一个门槛：一个想法要留下，必须同时满足「描述了一次真实会话里发生的失败」和「符合现有哲学」；假想出来的改进（「如果能…会更好」）不收，配置项、harness 特例、为某一个人的工作流做的微调也都不收，那些属于你自己的 AGENTS.md 或 fork。更狠的是新技能提案直接关闭：能由已有技能组合出来的行为，不给新技能，因为每个技能都是永久的维护面。而每个被拒绝的概念，在 .out-of-scope/ 里都有一个文件写清楚为什么拒绝。

特色与适用范围

pstack 适合谁

• 你在 Cursor 里工作（或者愿意按 docs/harness/claude-code.md 那张映射表，手工把 Cursor 名字换成 Claude Code 的名字）。
• 你的工作方式是给目标 + 给验收标准，而不是逐步微操。README 自己说的：「给 agent 一个目标和一种检查它的方式」就够了，不需要点名 playbook。
• 你需要并行和无人值守：swarm、arena、autopilot-*、orchestrate 这些 playbook 是专门为「一次开一堆 agent」「我去睡了，早上要全部合进去」设计的。
• 你愿意接受多模型分工：代码走 Grok，最难的改动、prose、判断走 Opus。默认面板就是 opus 5.5 / grok，/setup-pstack 可以改。
• 你的流程已经有 PR、CI、worktree、gh 这些基础设施，因为 babysit / shipping / autopilot 都假设它们存在。

Matt Pocock skills 适合谁

• 你要跨 harness：同一个技能库在 Claude Code、Codex、Copilot、Gemini 里都能用，甚至可以直接 npx skills 拷成可编辑文件。
• 你要保留流程控制权：什么时候对齐、什么时候拆工单、什么时候实现、什么时候 review，都由你决定，技能不接管。
• 你要能改：每条技能都短，改起来没有心理负担。grill-me 全文只有一行正文，wait-what 只有一段话，grill-with-docs 只有一句「调用 grilling 和 domain-modeling」。
• 你愿意被 grilling：这是它最被推荐、也最需要你在场的技能。interview-first 意味着前置沟通成本，而不是省掉它。
• 你愿意先做一次配置：/setup-matt-pocock-skills 要问你用哪个 issue tracker、triage 打什么标签、文档放哪。

一句话选择

你要的是杠杆（并行、多模型、无人值守、一套被验证过的剧本），选 pstack；你要的是控制权（流程留在手里、跨工具、技能可改可组合），选 Matt。 两家都不适合「装完就自动出活」的期待，也都要求你先给出一个可验证的完成标准。

反直觉的、值得盯住的要点

这一节是我建议你真正花时间看的部分。这些设计里有很多和「主流 AI 编程框架」的直觉相反。

pstack 这边

1. 它明着反规划。 README 里专门开了一节 “why are there no planning skills?”，原话是：Cursor 已经有很好的 plan mode，但我个人不相信规划，最好的 spec 就是代码。这直接和 Spec-Kit 那一派「先写规格再动手」对立。它当然也能做计划（有 multi-phase-plan playbook），但那不是默认路径。

2. TDD 默认是关的。 pstack 的 /tdd 描述写得很克制：只有在用户明确要求、或者这个 bug 有一条便宜的本地方测试路径时才用；测试路径不清楚、贵、重集成、或者没人要求，就跳过。这和 Matt 把 TDD 放在主流程核心位置恰好相反。pstack 把「验证」的重心放在了「跑真实产物」和「生成项目本地验证技能」上，而不是「先写一个失败的测试」。

3. 它默认不问你。 principle-never-block-on-the-human：可逆的事情直接做，做完把结果给你，让你事后纠偏；只有不可逆操作（强推共享分支、部署、删数据、给客户发消息）才停下来。这跟很多框架「关键步骤必须人类确认」的默认相反。

4. 「事实不该问人」。 更细的一条：如果你正要问一个人「用哪种方案 / 这个该怎么表现」，先分类。如果答案是可以跑一下观察出来的事实（行为、时序、布局、输出、性能，甚至「这个 eval 能不能区分两种情况」），那这个问题就不属于人，应该搭个 prototype 让结果自己回答。只有真正的产品判断或偏好，才值得占用人一分钟。

5. 目标函数是「更少代码」。 第一条原则就叫 laziness protocol，明确写着「候选方案里，倾向删除，倾向做最小的改动」，「行数少胜过『优雅』的样板」。README 也说得很直白：不是为了最大化 LOC。

6. 注释默认有罪。 /no-comments 会派一个只读的 Comment Sicko 去审注释，默认行为是删。保留的唯一理由是「这是一条我们改不了的约束」（比如 do not remove、talk to X before changing），而且要你拿出证据。更妙的是，它对这类约束的建议不是「留着注释」，而是把它编码成类型、runtime 检查、测试或 CI lint，然后删掉注释（这就是 principle-encode-lessons-in-structure：当你第二次写同一条指令时，把它变成结构，而不是更多文字）。

7. 多模型不是「可选项」，是默认架构。 代码类委派给 grok，最难的改动、prose 和判断给 opus；/interrogate 说得很清楚：对抗性来自模型多样性，而不是给每个模型分配一个人设。这意味着你要为两种模型的额度付钱。

8. 子代理类型不能随便换。 派子代理时必须用 subagent_type: "poteto-agent"。这个包装子代理干的第一件事是完整读一遍 poteto-mode 的 SKILL.md（包括内联的原则索引），然后才开始干活。换成 generalPurpose 会跳过这次读取，作者的说法是会「漂移」。这是一个很硬的细节：技能的效果依赖一次强制的上下文装载。

9. 无人值守跑完必须交一份「Attention」。 /show-me-your-work 会维护一份决策 TSV（每行一条决定：是什么、为什么、证据、结果），跑完之后必须派一个不同模型家族的子代理去读这份日志和 transcript，指出你该注意的地方。输出末尾固定有一个 Attention 段，第一行是 reviewed by <model>。No flags 是合法输出，不写模型名不行。

10. 连文风都是可执行的清单。 /unslop 列了 30 多条要删的 AI 痕迹：em dash、抽象隐喻名词（substrate、wedge、north star、flywheel）、AI 常用词（delve、tapestry、pivotal、underscore）、“not just X, but Y”、强行凑三点、同义词轮换、装饰性 emoji、客套话、以及「说感觉不说机制」的句子。

Matt Pocock 这边

1. 技能可以只有 7 行。 /grill-me 的正文是「Call the Skill tool with “grilling”.」；/grill-with-docs 的正文是「调用 grilling 和 domain-modeling 两次」。这不是偷懒，是设计：技能是指针，不是文档，真正的知识只有一份，放在被指向的地方。这种方式的好处是改一处生效多处，代价是你得理解这套指向关系才能读懂仓库。

2. 「谁可以调用」是被强制声明的设计轴。 见上文，user-invoked 要同时改 Claude 的 frontmatter 和 Codex 的 agents/openai.yaml。绝大多数技能库都不区分这件事。

3. 它拒绝 harness 的提问 UI。 .out-of-scope/native-question-tool.md 明确拒绝把 grilling 接到 AskUserQuestion 这类结构化提问上。理由很值得一读：结构化选择器会把模型推向「带预设答案的多选题」，而 grilling 的价值恰恰是开放问题、用你自己的话回答、一次解决决策树的一个分支。它还顺便拒绝给子代理递归加护栏，理由是「那应该由 harness 负责，写在技能里既只覆盖一个技能，又每次都要花 token，还依赖模型自觉遵守」。

4. 不收新技能提案。 SCOPE.md 直接关闭：新技能提案和贡献不受理，哪怕你带着分支来。理由是能组合出来的行为不该变成新技能。这是很罕见的立场，大多数开源技能库都在拼命收 star 和 PR。

5. 文档是发版的一部分，路由是「会撒谎的」。 见上文。仓库 AGENTS.md 里给 ask-matt 定了一句判词：一个它从没提过的新技能，或者一个它还在指向的旧技能，都是一个会撒谎的路由。这句话值得所有写技能库的人抄下来。

6. review 的对象是「agent 的环境」。 /retro 不改代码，它改的是下次 agent 工作的环境：导航指针、自动检查、编码规范、steering 文件、工具经济性。判断标准是「机械错误变成确定性检查，判断题才写进规范」。

7. 全仓库禁用破折号，是写进 AGENTS.md 的硬规则。 注意这和 pstack 的 unslop 第 13 条（完全避免 em dash）殊途同归：两个以「反对 AI slop」为旗号的仓库，都不约而同地把 em dash 当成了 AI 的味道。

8. 设计词汇表带「已否决」清单。 /codebase-design 里有一节 Rejected framings，公开否掉 Ousterhout 的 depth 定义（实现行数 / 接口行数），理由是那会奖励「给实现注水」。一个技能库敢在正文里写「我们不用某个业界权威的定义」，说明它把词汇表当契约在维护。

9. wayfinder 只做决定，不做交付。 它把「大到一次会话装不下」的工作画成 tracker 上的决策票（每张票是一个要做的决定，不是一段要执行的建设），一张一张解决到「路看清了」。原话是 “plan, don’t do”，并且提醒：想直接动手的冲动，通常标志着你已经到了地图边缘，该交接了。

10. 名字优先于编号。 wayfinder 要求所有人类可读的地方都必须用 issue 的标题引用它，而不是编号，理由只有一句：「#42、#43、#44 堆一墙是看不懂的，名字一眼就能读。」

两边都反直觉的

同名技能大面积撞车，但只有两个真的重名。 我逐条比过：tdd 和 teach 是唯一的两个同名技能，但概念上重叠得厉害（两边的 prototype、retro 对 reflect、pr 对 opening-a-pr、code-review 对 interrogate + no-comments）。更要注意的是同名不同义：pstack 的 /tdd 是「有便宜测试路径才用」，Matt 的 /tdd 是主流程核心。所以别把两套混装到同一个 harness。Matt 自己在 README 里给过一条通用经验：安装方式二选一，都装等于每个技能出现两份。

两家对上下文的纪律方向相反，但都在打同一个敌人。 pstack 用子代理隔离、主线程只留摘要；Matt 用「smart zone 大约 150k」加阶段性的 clear。一个往外甩，一个往里收，目标都是别让上下文退化。

两家的元数据都在承担产品功能。 pstack 用 principle- 前缀让原则可以被按名调用；Matt 用 disable-model-invocation 让「谁能触发」变成契约，用桶和 plugin.json 让「哪些技能正式发布」变成可校验的事。

泼几盆冷水

写到这里都是「设计得很聪明」。但两个东西都有明确的代价，选之前应该知道。

pstack 的坑：

• Cursor 强耦合。 它假设了一堆 Cursor 独有的东西：Task 子代理、cloud 环境、Bugbot、automations。Claude Code 不是不能跑，但要读一张映射表，而且 Cursor-only 的步骤会被跳过（适配文档里明确要求「跳过就写一行说明，不要停、不要问、不要重试」）。
• 模型 slug 会打翻默认表。 默认分工写死了具体模型名。作者自己在 README 里提醒：默认值变了之后，早先写下的规则仍然会把旧默认钉住，你得手动删掉那几行再跑 /setup-pstack。模型更新的节奏有多快，这条维护成本就有多真实。
• 技能面很大。 56 个技能 + 24 条原则 + 23 个 playbook，还要配一份模型规则。入门的真实成本不是「装个插件」，而是「接受一种新的工作方式」。
• 自治纪律全靠操作者。 「默认不问、先做后报」只有配上一条清晰的不可逆边界才安全。边界写得很清楚（强推、部署、删数据、发给客户），但把什么划进这条线，取决于你自己。

Matt Pocock skills 的坑：

• 小技能 = 你要自己当流程编排器。 ask-matt 给的是地图不是司机。你如果指望它像 pstack 那样「丢个目标就自动跑」，会失望。
• 没有多模型杠杆。 模型无关的另一面就是不会替你在 Grok 和 Opus 之间分配角色。要用多模型，得你自己配。
• grilling 需要你在场。 它是最有价值的技能，也是最需要投入时间的技能。想完全 AFK 的人用不了这条路。
• 你不能往里加技能。 提案被政策关闭。这对「想共建」的人是硬伤，对「想自己改」的人没问题（fork 或 npx skills 拷贝成可编辑文件）。
• 规范成本落在你身上。 issue tracker、triage 标签、GLOSSARY.md、ADR、CODING_STANDARDS.md，这些都不是自动长出来的，得你在 /setup-matt-pocock-skills 之后真的维护。

两边共同的冷水：

• 都不解决「你不知道自己要什么」。两家都把这当成前提，pstack 用「给目标 + 给验收标准」，Matt 用 grilling 前置对齐。
• 都假设你有成套的工程基础设施：git 分支、PR、CI、issue tracker。没有这些，两套流程都会空转。
• 都是英文语境的技能库。里面大量判断靠语言细节（unslop 的词表、Matt 的协议措辞），换到中文项目里，效果需要自己验证。

怎么选，以及能不能两个都装

我的建议是按你在哪一层要杠杆来分：

• 如果你的瓶颈是**「一件事做不完，我要它自己跑很久还能信」**，选 pstack。它的 playbook、子代理分工、决策留痕、Attention 复检，都是为长时程和无人值守设计的。
• 如果你的瓶颈是**「我总在跟 agent 讲不清楚，而且它写出来的东西越改越乱」**，选 Matt Pocock。grilling 治第一个，深模块和双轴 review 治第二个。

至于能不能两个都装：方法论上可以，实践上要隔离。 两边在哲学上其实不冲突（pstack 也认为「骨架式流程」应该存在，Matt 也认为「子代理和并行」是工具），真正会打架的是同名技能和默认行为的假设。最稳的做法是让它们住在不同的 harness 里：pstack 装在 Cursor 那边负责干活、并行、盯 PR；Matt 的技能装在 Codex / Claude Code 侧负责对齐、拆工单、设计 review。我自己的机器现在就是后面这种状态：~/.agents/skills 里躺着大约三十个 Matt 的技能（ask-matt、code-review、codebase-design、diagnosing-bugs、grilling、tdd、wayfinder 这些都在），而 pstack 还没装，等着哪天真的开始用 Cursor 跑长任务再上。

最后说一句两边都同意的话，也是我最想抄下来的一句，来自 pstack 的 README：如果你想快，先往深里走（if you want to go fast, go deep first）。两个人用完全相反的方式在说同一件事，这大概就是这两个仓库值得放在一起读的原因。

事实来源与读数

• pstack：github.com/cursor/plugins 的 pstack/ 目录，克隆快照 ddf824a（2026-10-20）。pstack/plugin.json 版本 0.15.28，MIT（Copyright 2026 Lauren Tan）。skills/ 56 个技能目录、24 个 principle-*、poteto-mode/playbooks/ 23 个 playbook、agents/ 2 个 subagent。仓库整体 13,066 star / 1,283 fork / 30 贡献者，2026-01-23 建仓。
• Matt Pocock skills：github.com/mattpocock/skills，克隆快照 5beb35b（2026-10-19）。297,563 star / 24,986 fork / 8 贡献者，MIT，2026-02-03 建仓，版本 1.3.1。38 个 SKILL.md，其中 27 个（engineering/ 20 + productivity/ 7）随插件发布。
• 本文引用的原话都出自上述快照里的 README、AGENTS.md、SCOPE.md、.out-of-scope/*.md、.agents/invocation.md、docs/guide/*.md 和各技能的 SKILL.md。