介绍一下joye博客最新的关于pstack的内容，讲述她的skills具体有那些作用

提问

介绍一下joye博客最新的关于pstack的内容，讲述她的skills具体有那些作用

回答

joye 博客里关于 pstack 的是笔记《先让 agent 自证，再用代码做计划：pstack》，2026年10月21日发的，是他读完 Lauren Tan（@poteto）两篇 pstack 文章后的整理。她待过 Meta、Netflix、Cursor，也在 React 核心团队。

先交代背景：pstack 是一组遵循 Agent Skills 开放标准的开源 skill，入口是 /poteto-mode。你给它目标，再加上“怎么算做完”，它从一组 playbook 里挑一个，把步骤原样抄进待办，再按步骤去调其他 skill。joye 笔记里的主线不是“skill 有多少个”，而是验证优先。

各 skill 的作用，按 joye 笔记的顺序说：

一，创建验证地基。跑 /create-verification-skill，给项目生成一个本地验证 skill，含两样东西。一个给 agent 用的小 CLI，能开会话、点击、截图、录性能 trace、开关 feature flag，输出机器可读的 JSON，破坏性命令带 --dry-run，报错要告诉你下一步怎么改。一份 Feature Map，用几份 markdown 记录每个功能是什么、用户从哪走到、对应哪几条 CLI、有哪些坑。她把这份地图叫“物化的记忆”，是代码库的压缩版，省的是上下文。配套 /maintain-verification-skill 负责日常校准，她建议至少每天跑一次，否则地图会过期。这是整套东西的地基：agent 不能自己证明做完了，人就得整天盯着。

二，先复述，再动手。她不把解法直接交给 agent，而是让它用自己的话把问题和根因说回来。这一步同时压掉对话里的噪音、在写代码前拦住误解，也防止你自己的假设先把路堵死。

三，建心智模型。/how 追一段代码现在怎么跑，子系统跨多目录时会并行去读；/why 追当初为什么这么设计，翻 git、PR、工单、文档，而不是只读当前代码；/teach 建在两者之上，讲清系统是什么、怎么跑、为什么长这样；/recall 从过去的对话里把当前状态收成一份短说明，免得新开一轮又从零讲。

四，设计和选型。/architect 分阶段：先 /how 加 /why 摸清归属和约束，再让不同模型并行出草图，草图里写调用方式、核心类型、公开函数；然后换模型交叉评审；再按草图实现。实现时如果到处打补丁、加意料之外的参数，就把这版设计整份扔掉重来。原型也是同一思路：做两三个可切换的变体丢进应用，用验证 skill 去点、去截图、去量，用代码做计划，而不是在纸上磨长计划。

五，并行和批量。/arena 把同一个任务发给多个模型，各自在独立 worktree 里做，协调者建私有 rubric，另找一个模型评判，最后选一个作底再吸收别人的好点子。/swarm 拆独立切片（比如每个包跑一次检查），等所有 worker 回一份报告。她区分得很清楚：arena 比方案，swarm 铺覆盖面。

六，多模型评审。/interrogate 把同一份 diff、意图和评审规则发给多个模型，靠模型多样性拿不同视角，而不是给人设。主评审合并重复项、标注哪些模型意见一致，并把每条结论分成要改、可考虑、记下、驳回四组，被驳回的部分也写出来，让你能推翻它的判断。

七，计划和长任务。/poteto-mode 里有多阶段计划 playbook，把定下来的设计拆成小 PR，每步的完成标准是跑过、验过，不是测试文件存在。另有 autonomous run、autopilot 这类长任务 playbook，适合过夜跑，但前提是“做完”这件事可以被检查。还有 session pickup 和 pause safely，用来从上一轮 agent 的 transcript、分支、决策日志里恢复状态，或者停在原子边界写下 resume note。

八，一堆小 skill：/architect 之外的还有 blast-radius 查改动会不会破坏 diff 之外的地方，tdd 先写失败测试，typescript-best-practices，figure-it-out 给没有现成 playbook 的大迁移现做一个，show-me-your-work 留一份决策日志（一行决策一条记录，写时间、阶段、理由、证据、结果）。另有一个没有斜杠命令的原则库，比如懒汉原则、先减后加、证明它真的能跑、修根因而非修症状、按可验证单元切分工作。它们是拿名字去引导当前这一轮，不是在命令。使用时你点名原则，它必须说出这条原则改变了哪个决定，光重复名字不算数。

joye 自己的结论有四条，我认同，也是这篇笔记真正有价值的地方：第一，先有验证，并行才不会放大未检查的改动；第二，验证 skill 就是小 CLI 加 Feature Map，每天维护一次才不会过期；第三，计划用代码做，先复述再建模型、再用两三个原型拿证据来选，抽象计划写得越长越像进度、越可能没实质；第四，第一周只证明一件事：一个小改动能自己跑通并留下证据，多模型多 agent 全放在这之后。

顺带一句：joye 的笔记本身是转述 Lauren Tan 的用法，数字类细节（比如 23 个 playbook 是那会儿 0.15.0 版本的数）会随版本变，照着用之前看眼仓库 README。