跳转到内容
learn-pstack

更新于 2026-10-02

pstack 讲解 · 中文

pstack 的 47 个 skills，一页看懂

结论：pstack 是一个 Cursor 插件。里面是 poteto 每天在 Cursor 写代码用的 skills。它让 agent 先理解、再设计、再构建，最后用真实运行证明结果。

它适合这样的开发者：想让 agent 少写代码、写对代码，并且敢同时跑多个 agent。

  1. /add-plugin pstack 安装
  2. /setup-pstack 选模型
  3. /poteto-mode 交任务

全景图：在哪一步用哪个

24 个工作流 skill 按使用时机分成 7 组。23 条原则不分阶段。

入口先装好，再交任务
/setup-pstack/poteto-mode
① 理解代码改代码之前
/how/why/teach/recall/bro
② 设计写代码之前
/architect/arena/swarm
③ 构建与清理写代码时
/tdd/typescript-best-practices/no-comments/unslop/technical-writing
④ 验证交付之前
/interrogate/blast-radius/create-verification-skill/maintain-verification-skill
⑤ 长任务你要离开时
/figure-it-out/show-me-your-work
⑥ 复盘与定制做完以后
/reflect/automate-me/make-bot-ui
23 条原则贯穿每一步
核心 10架构 6验证 4委派 2元 1

从上往下、从左往右读，是一次改动的顺序。/poteto-mode 在入口接下任务，按 playbook 在每一步调用对应的 skill。你也可以直接输入命令，单独用某一个。点任意 skill 名，跳到它的卡片。

我想……

选一种情况，页面高亮对应的 skill。再点一次取消。

每个 skill 一张卡片

每张卡片写四件事：什么时候用，怎么触发，你会得到什么，以及细节。名字后面是命令，命令保持英文。

入口先装好，再交任务 · 2 个

/setup-pstack

入口
什么时候用
第一次装好 pstack 之后。想换模型或推理预算时，也用它。
怎么触发
输入 /setup-pstack。
你会得到
一条始终生效的 rule：~/.cursor/rules/pstack-models.mdc。它按角色写明每个子代理用哪个模型。
展开细节
  • 它先检测你能用哪些模型，再问推理预算。预算有四档：unlimited、large、medium、small。
  • 它列出每个角色和对应模型，等你确认或修改。
  • 角色设成 inherit-parent 或 auto，子代理就用父聊天的模型。
  • rule 只对新会话生效。装完后新开一个聊天。
  • 0.15.3 之前写的 rule 锁的是旧默认模型。删掉那些角色行，再跑一次。
  • 最后，如果项目里没有验证 skill，它会问一次要不要用 /create-verification-skill 生成。
看中文译文 →

/poteto-mode

入口
什么时候用
任何不算小的任务。这是默认入口。
怎么触发
输入 /poteto-mode，后面写目标和检查办法。进入后它一直开着，直到你说退出。
你会得到
它先匹配一个 playbook，把步骤原样抄进 todo 列表。然后按步骤调用其他 skill。回复里会点名用到的原则，以及它改变了哪个决定。
展开细节
  • 自带 23 个 playbook。常用的有 Investigation、Bug fix、Feature、Refactoring、Perf issue、Babysit、Shipping、Autonomous run。
  • 跳过的步骤留在 todo 里，带一行 skip: <reason>。
  • 任务很大，或没有合适的 playbook，它转到 /figure-it-out。
  • 可逆的工作直接做。以下动作先停下问你：force-push 共享分支、部署、删数据、发给客户的消息。
  • 子代理默认按角色选模型。代码用 grok-4.7-xhigh-fast，正文和判断用 claude-opus-5-5-max。/setup-pstack 可以改。
  • /deslop、control-cli、control-ui 在 cursor-team-kit 插件里，不在 pstack 里。
  • 示例：/poteto-mode the export writes duplicate rows when a retry lands mid-run. repro first, then fix and verify.
看中文译文 →

理解代码改代码之前 · 5 个

/how

理解代码
什么时候用
想知道一段代码或一个子系统现在怎么工作。也用于「这段代码该放哪一层」这类问题。
怎么触发
输入 /how 加问题。 /poteto-mode 会在步骤需要时调用它。
你会得到
一份架构说明，分为 Overview、Key Concepts、How It Works、Where Things Live、Gotchas。
展开细节
  • 问题窄：一个只读子代理边读边解释。
  • 问题大：先并行派 2 到 4 个只读探索者，再由一个子代理汇总。
  • 默认模型：探索者用 grok-4.7-xhigh-fast，解释者用 claude-opus-5-5-max。
  • 要问代码为什么这样写，用 /why。
  • 示例：/how do we cancel runs? do we have an n+1 when we look up every run to cancel?
看中文译文 →

/why

理解代码
什么时候用
想知道代码为什么长成这样：设计理由、回归、事后复盘、某个阈值的来历。
怎么触发
输入 /why 加问题。 /poteto-mode 会在步骤需要时调用它。
你会得到
一份带引用的报告。直接证据和推断分开写。查过的每个来源都列出来，没结果的也列。
展开细节
  • 先用 git blame、git log 和 gh 找到相关提交和 PR。
  • 再发现可用的 MCP，按 7 类证据各派一个调查子代理，并行查。
  • 7 类证据：源码控制、议题跟踪、长文文档、团队聊天、基础设施可观测性、错误跟踪、产品分析数仓。
  • 某一类没有对应的 MCP，报告里要写明这是缺口。
  • 如果你接下来要改这段代码，报告最后给出 Preserve / Change / Avoid / Risk 约束。
  • 要问运行时行为，用 /how。
看中文译文 →

/teach

理解代码
什么时候用
摘要不够，你想真正弄懂一处改动或一个子系统。
怎么触发
输入 /teach 加对象。
你会得到
一份白话说明。先给最小的完整答案，你追问再加深。三个以上部件的系统，用一组逐张加内容的图来讲。
展开细节
  • 它内部跑 /how 和 /why。改动很小时，可能只跑其中一个。
  • /why 的置信度措辞原样保留。
  • 不出测验，不让你复述。
  • 示例：/teach me how this PR changes retries. convince me it fixes the cause and not the symptom.
看中文译文 →

/recall

理解代码
什么时候用
开始或回到一项工作之前，想知道自己做到哪了。
怎么触发
输入 /recall 加话题。
你会得到
一份简报：最多 5 条概要，每条线索一个状态标签，最多 5 个反复出现的问题，一个下一步。
展开细节
  • 默认范围是最近 7 天、当前工作区。不读别的项目的对话记录。
  • 并行子代理挖你的聊天记录。
  • 话题指向某个功能、文件或 bug 时，它还会查共享记录。方法和 /why 一样，查 PR、议题和仍在触发的报错。
  • 它用 git 和 gh 核对 PR 和分支的当前状态。
  • 状态标签例如 [merged #N]、[open PR #N]、[planned, not started]。
  • 要接手某一个具体的聊天，用 Session pickup playbook。
看中文译文 →

/bro

理解代码
什么时候用
回复在技术上很全，你却看不懂它说了什么。
怎么触发
输入 /bro。整条提示词就这一个词。
你会得到
上一条消息的白话版。更短，没有行话。
展开细节
  • 它只做一件事：把上一条消息重说一遍，像一个人跟另一个人说话。
看中文译文 →

设计写代码之前 · 3 个

/architect

设计
什么时候用
要写跨函数边界的代码，想先定下调用方式、类型和模块结构。
怎么触发
输入 /architect。想先看设计再动手，写 /architect with checkpoint。 /poteto-mode 会在步骤需要时调用它。
你会得到
先写调用方的用法，再推出类型草图，函数体是 not implemented。附一份设计理由。然后按草图实现。
展开细节
  • 分五个阶段：Ground、Sketch、Agree、Implement、Scrap。
  • Ground 对相关代码跑 /how。设计会改所有权或分层时，再跑 /why。
  • Sketch 跑 /arena。至少要两个结构不同的候选。
  • 候选要过一份设计红线清单，例如浅模块、信息泄漏、只转发的方法。
  • 默认不停下等你确认，直接实现。
  • 实现时同一种变通写法反复出现，就扔掉草图，重新设计。
看中文译文 →

/arena

设计
什么时候用
一次尝试可能定死错误的形状。你想并行试几次，再挑最好的。
怎么触发
输入 /arena。可以指定数量，例如 /arena this, 5 candidates。 /poteto-mode 会在步骤需要时调用它。
你会得到
一份合成后的产物。附一份说明：基座是哪个候选，嫁接了什么，拒绝了什么，验证结果如何。
展开细节
  • 分六步：Frame、Fan out、Cross-judge、Pick、Graft、Verify。
  • 先定 3 到 6 条评分标准。候选只看到任务，看不到标准。
  • 默认 3 个候选，分别用 claude-opus-5-5-max、gpt-5.6-sol-max、grok-4.7-xhigh-fast。
  • 每个候选写到自己的 worktree 或目录。
  • 一个只读裁判独立打分，尽量用和父代理不同的模型族。
  • 候选结果分歧很大，说明题目没定清。重新定题再跑，不取平均。
看中文译文 →

/swarm

设计
什么时候用
要并行覆盖很多切片，或让几个 worker 赛跑，最后只要一份报告。
怎么触发
输入 /swarm 加范围。 /poteto-mode 会在步骤需要时调用它。
你会得到
一份汇总报告：结果表、每条带证据的问题、缺口和掉队的 worker。
展开细节
  • 三种形状：切片、race、两者混合。race 要事先声明选择规则：first pass、rank all 或 best-of。
  • worker 默认在 cloud 上跑，模型是 grok-4.7-xhigh-fast。
  • 每个 worker 报告 PASS、ISSUES 或 BLOCKED，并附证据。
  • 缺结果算缺口，不算通过。
  • 和 /arena 的区别：/swarm 不选基座，也不嫁接。
  • 示例：/swarm check every package under packages/ against its check.sh. one worker per package. one report.
看中文译文 →

构建与清理写代码时 · 5 个

/tdd

构建与清理
什么时候用
修一个 bug，而且有便宜的本地测试路径。或者你明确要求 TDD、失败测试、回归测试。
怎么触发
输入 /tdd。上下文足够时，/tdd implement 就够了。 /poteto-mode 会在步骤需要时调用它。
你会得到
一个修复前失败、修复后通过的回归测试，以及两次运行的证据。
展开细节
  • 先确认测试因为预期的原因失败，再改代码。
  • 测试要搭大量 harness 或靠脆弱的 mock 时，不硬写。改用最接近的可执行检查。
  • 宁可不加测试，也不加坏测试。
  • 不为迁就错误的实现去改测试。
看中文译文 →

/typescript-best-practices

构建与清理
什么时候用
agent 读或改 .ts、.tsx 文件时。
怎么触发
通常不用你输入。它的 paths 匹配 .ts 和 .tsx，agent 碰到这类文件就加载。
你会得到
一组具体的 TypeScript 规则，把 type-system-discipline 原则落到语法上。
展开细节
  • 用带 kind 字段的可区分联合表示变体，不用一堆可选字段。
  • 给原始类型打品牌，避免混用。在边界校验一次。
  • 外部数据先当 unknown。不用 as 强转，校验之后才转。
  • default 分支写 const _exhaustive: never = x;，新增变体时编译器会报错。
  • 用 satisfies 代替 as。
  • 能跑的就不 mock。发布的代码里不留 console.log。
看中文译文 →

/no-comments

构建与清理
什么时候用
提交 review 之前。把 diff 里的注释交给一个没写过它们的审查者。
怎么触发
输入 /no-comments，例如 /no-comments the diff。 /poteto-mode 会在步骤需要时调用它。
你会得到
清理过注释的 diff。附一份报告：删了多少，恢复了哪些，修了什么，哪些约束还没被代码强制。
展开细节
  • 它启动只读子代理 Comment Sicko。
  • 默认范围是相对 main 的当前 diff，含工作区里的改动。
  • 接受的标记，做范围内最小的根因修复。需要改结构时，先跑一次 /architect 出草图。
  • 注释写着 do not remove 这类约束时，它提议改成类型、运行时检查、测试或 CI lint。你同意后再编码，并删掉注释。
看中文译文 →

/unslop

构建与清理
什么时候用
任何要给人读的文字：回复、文档、PR 描述、日志。
怎么触发
输入 /unslop，或直接说 unslop that, tighten it。 /poteto-mode 会在步骤需要时调用它。
你会得到
改写后的文字。意思不变，AI 腔去掉。
展开细节
  • 它的 description 写着 Must always apply。
  • 规则有固定编号，其他 skill 按编号引用。
  • 例如：AI 常用词（crucial、delve、pivotal）、「Not just X, but Y」、硬凑三项、同义词轮换。
  • 还有：em dash、冒号当连接词、加粗过多、Title Case 标题、装饰性 emoji、客套话、空洞结尾、抽象比喻名词、被动语态、过度压缩。
看中文译文 →

/technical-writing

构建与清理
什么时候用
写或审文档、RFC、readme、PR 描述、提交说明。
怎么触发
输入 /technical-writing，例如 /technical-writing review the readme changes。 /poteto-mode 会在步骤需要时调用它。
你会得到
按四层标准写出的文字。目标是疲倦的工程师读一遍就懂。
展开细节
  • 第一层 Diátaxis：先选文档模式，tutorial、how-to、reference 或 explanation。
  • 第二层 Google developer style：对读者说「你」，用主动语态，条件写在指令前。
  • 第三层 STE：一句一个指令，指令不超过约 20 个词。
  • 第四层 Global English：不留两种读法，不用斜杠，不用习语和比喻。
  • PR 描述和提交说明用后三层，不用 Diátaxis。
  • 它会套用 /unslop。
看中文译文 →

验证交付之前 · 4 个

/interrogate

验证
什么时候用
手上有一份 diff，想让几个不同的模型来找漏洞。
怎么触发
输入 /interrogate，例如 /interrogate review this pr. /poteto-mode 会在步骤需要时调用它。
你会得到
一份 verdict。每条 finding 分到 Act on、Consider、Noted、Dismissed，并注明哪些模型提出。它不会自动改代码。
展开细节
  • 开审前先写一段意图说明。
  • 每个配置的模型一个审查者。默认三个：claude-opus-5-5-max、gpt-5.6-sol-max、grok-4.7-xhigh-fast。
  • 所有审查者拿同一份提示词和评分标准，包括代码质量视角。
  • 两个以上模型独立提出的 finding，信号最强。
  • 最后有一张 Agreement Map，说明模型在哪里一致、在哪里分歧。
  • 官方指南把它放在「设计」一章，用来在交付前审设计和改动。
看中文译文 →

/blast-radius

验证
什么时候用
一处看着很小的改动，你不放心，想知道它会在别处弄坏什么。
怎么触发
输入 /blast-radius，或说 what could this break。
你会得到
一份报告。核心是改动安全所依赖的那一个事实，标为已证明或 unproven。另外列出风险、已排除的项和合并前最便宜的检查。
展开细节
  • 列调用方不是重点，grep 一秒就能做完。重点是 grep 看不到的地方。
  • 例如：库的源码和锁定版本、执行时机、API 返回的 JSON、数据库列、功能开关、下游三跳的代码。
  • 每个关键事实标出确定程度，共 5 级。最低是「你说的」，最高是「在运行的应用里复现」。
  • 它要求写脚本调用真实代码，证明那一个事实。
  • 改动大或范围广时，可以用 /arena 让几个模型一起查。
看中文译文 →

/create-verification-skill

验证
什么时候用
项目里没有脚本化的办法去驱动应用、证明行为。
怎么触发
输入 /create-verification-skill。/setup-pstack 结束时也会问一次。
你会得到
项目本地的 .cursor/skills/verify-<app>/。里面有 Launch、Doctor、Drive、Evidence、Cleanup 各节，以及 features/ 下的 feature map。
展开细节
  • 它先从代码库找答案，只问你代码回答不了的事。
  • 驱动方式先用已有的 harness。没有的话，web 用浏览器和 CDP，CLI 用 tmux 或 PTY，服务用 HTTP。
  • feature map 先覆盖 3 到 5 个主要功能。
  • 交付前把生成的 skill 端到端跑一次：启动、doctor、驱动一个功能、采集证据、清理。
  • 清理之后还要确认证据仍在。没跑通的 skill 只算草稿。
  • 适用于任何语言、框架和平台。
看中文译文 →

/maintain-verification-skill

验证
什么时候用
应用变了，验证 skill 的 feature map 已经对不上。
怎么触发
输入 /maintain-verification-skill，或说 audit the verify skill。
你会得到
三种结果之一：clean，没有要改的；changed，一个已证明的修正 PR；blocked，写明卡在哪里。
展开细节
  • 每个功能派一个只读子代理，并行读源码。
  • 然后协调者亲自做一轮现场驱动，每个功能至少一次。源码看起来没问题也要做。
  • 只改验证 skill 自己的目录，不改产品代码。
  • 发现产品回归就报告，不在文档里掩盖。
看中文译文 →

长任务你要离开时 · 2 个

/figure-it-out

长任务
什么时候用
没有合适的 playbook，或任务很大：大型迁移、多部分改动、你离开后回来再审的工作。
怎么触发
输入 /figure-it-out。/poteto-mode 遇到这类任务会转过来。 /poteto-mode 会在步骤需要时调用它。
你会得到
先交出为这次任务设计的 playbook，再执行。回复里有：这份 playbook、严谨程度和理由、决策日志路径、已验证项、未完成项。
展开细节
  • Frame 阶段写出可证伪的完成条件、量化的范围和严谨程度。
  • 先搭验证 harness，记录改动前的基线。
  • 一次性的设计决定跑 /architect。设计已定的机械工作不跑。
  • 每个单元当一次实验：提出假设，做最小改动，在真实产物上测量。有进展就保留，没有就回退。
  • 结论只有三种：VERIFIED、NOT VERIFIED、INCONCLUSIVE。INCONCLUSIVE 不算通过。
  • 决策用 /show-me-your-work 记录。
看中文译文 →

/show-me-your-work

长任务
什么时候用
长任务、无人值守的任务，或你离开后再审的工作。
怎么触发
输入 /show-me-your-work，例如 /show-me-your-work catch me up on what you did last night。 /poteto-mode 会在步骤需要时调用它。
你会得到
一份 TSV 决策日志，每行一条决策。回复末尾有 Attention 一节，列出值得你细看的地方。
展开细节
  • 列是 ts、phase、decision、why、evidence、result。
  • 默认放在 decisions.tsv，不提交。几个任务同时跑时，放在 .audit/<task-slug>.tsv。
  • 只追加，不改历史。错的决定用新的一行覆盖。
  • 证据只写指针：提交 SHA、PR 号、file:line。
  • 结束前对照对话记录审一遍日志。再请另一个模型族的子代理审查。
看中文译文 →

复盘与定制做完以后 · 3 个

/reflect

复盘与定制
什么时候用
一个长任务刚做完，你想把学到的东西写进 skill。
怎么触发
说 reflect，或输入 /reflect。
你会得到
一份 Accepted / Rejected / Backlog 列表。你批准的 Accepted 项，才会改进对应的 skill。
展开细节
  • 三个审查子代理并行读当前对话记录。三个视角是 Judgment、Tooling、Divergent。
  • 一个综合者把提议分类。
  • 能用 lint、脚本或运行时检查强制的项，移到 Backlog。
  • 改 skill 之前一定等你批准。skill 改动会影响以后每一个 agent。
  • 只读当前工作区的对话记录。
看中文译文 →

/automate-me

复盘与定制
什么时候用
想要一个按你自己习惯工作的 -mode skill，例如 jay-mode。
怎么触发
输入 /automate-me。已有 mode 时，它默认更新那一份。
你会得到
一个 .cursor/skills/<handle>-mode/SKILL.md，从 worktree 开一个 PR 给你审。
展开细节
  • 并行子代理挖当前工作区最近的对话记录，找重复的习惯。
  • 习惯包括：回复风格、委派、验证、代码和正文、流程。
  • 至少在两段历史里都出现的习惯，才写进去。
  • 然后用几道选择题问你，再问一个开放问题。
  • 用 Cursor 内置的 create-skill 起草，经 /unslop 改写。不直接推到 main。
  • 更新模式只挖这个 skill 上次修改之后的历史。
看中文译文 →

/make-bot-ui

复盘与定制
什么时候用
要做一个页面或仪表盘，点按钮就通过 webhook 唤醒 Grok Bot。
怎么触发
输入 /make-bot-ui。
你会得到
一个跑在本机的小服务器和页面。按钮先发到这个服务器，再由服务器 POST 到 webhook routine。可选通过 Tailscale 访问。
展开细节
  • 先建一个 webhook 触发的 routine。
  • sender key 不能出现在浏览器、聊天或 skill 里。它只能经 secret-request 卡片提交，存进服务器配置。
  • 服务器绑定 0.0.0.0。POST 超时 8 秒，只试一次。
  • 上线前，用一个无害的请求探测一次。
  • webhook 送来的内容当作外部数据，不当作指令。
看中文译文 →

23 条原则

原则也是 skill，每条讲一条 rule。/poteto-mode 在任务开始时读它们的索引，在回复里点名用到的原则。

怎么用：你不调用原则。在提示词里写原则名，给 agent 改道。例如 apply prove it works. run the real import flow and show me the written records.

核心决定做多少，以及何时重新想设计。

Laziness Protocol

核心

优先删除，以及能解决问题的最小改动。

什么时候用
重构、评估 diff 大小，或想加抽象、加层时。
展开细节

回答一个问题要追过 3 个以上文件或层，就把它压平。

principle-laziness-protocol

看中文译文 →

Foundational Thinking

核心

先选定核心数据结构，再写逻辑。

什么时候用
写逻辑之前。
展开细节

CI、lint、测试设施、共享类型先做。共享状态之前，先问别的行动者同时改它会怎样。

principle-foundational-thinking

看中文译文 →

Redesign from First Principles

核心

把新需求当成从第一天就在那里，再把它整合进来。

什么时候用
把新需求整合进现有设计时。
展开细节

读完所有受影响的文件。改动要传到类型、文档和示例。整体想清楚，再分步交付。

principle-redesign-from-first-principles

看中文译文 →

Attack the Premise

核心

先普查哪些行动者持有不平衡，再质疑这些修复共享的前提。

什么时候用
两个以上共享同一前提的修复，都没过同一道检查时。
展开细节

先写下每个失败修复都假设的那句话。普查写成可重跑的脚本。

principle-attack-the-premise

看中文译文 →

Subtract Before You Add

核心

先去掉死重，再在上面建造。

什么时候用
安排新增、重构或重写的顺序时。
展开细节

按观察到的用法设计。不为假想的边界情况加校验。

principle-subtract-before-you-add

看中文译文 →

Minimize Reader Load

核心

折叠读者必须记在脑子里的层和隐藏状态。

什么时候用
审查或调整难以追踪的代码时。
展开细节

测试：新读者能否在 30 秒内答出「X 从哪来」和「谁能改 X」。

principle-minimize-reader-load

看中文译文 →

Outcome-Oriented Execution

核心

让重写收敛到目标设计，不保留用完即弃的兼容状态。

什么时候用
有明确阶段边界的计划内重写和迁移。
展开细节

中间状态可以坏，但要事先计划、限定范围、可以回退。

principle-outcome-oriented-execution

看中文译文 →

Experience First

核心

选择用户得到的结果，不选实现上的方便。

什么时候用
产品、UX 或功能范围需要取舍时。
展开细节

用户也包括调用你的库的同事，以及下一个维护者。

principle-experience-first

看中文译文 →

Exhaust the Design Space

核心

做两三个互相竞争的原型，并排比较后再定。

什么时候用
代码库里没有先例的新交互或架构决定。
展开细节

同一形状的变体不算第二个方案。

principle-exhaust-the-design-space

看中文译文 →

Build the Lever

核心

做出能完成或证明工作的脚本，让审查者可以重跑。

什么时候用
任何不算小的工作：编辑、迁移、分析、检查。
展开细节

引用了这条原则，diff 里却没有脚本或生成器，就是没有应用。

principle-build-the-lever

看中文译文 →

架构决定状态、校验和兼容放在哪里。

Model the Domain

架构

把重复的 rule 编进一个结构，不散落成条件判断。

什么时候用
写有状态的逻辑，或代码分支很多时。
展开细节

例如用状态机代替一组布尔值，用查找表代替分散的分支。

principle-model-the-domain

看中文译文 →

Boundary Discipline

架构

在边界上校验，并信任内部类型。

什么时候用
接入校验、错误处理或框架适配器时。
展开细节

边界指 CLI 参数、配置文件、外部 API、网络协议。业务逻辑放在纯函数里。

principle-boundary-discipline

看中文译文 →

Type System Discipline

架构

让非法状态无法被表示。

什么时候用
设计类型、审函数签名，或写静态类型语言时。
展开细节

给语义原语打品牌。外部数据在边界解析。不用强转骗编译器。

principle-type-system-discipline

看中文译文 →

Make Operations Idempotent

架构

让重试收敛到同一个终态。

什么时候用
设计会遇到崩溃、重启、重试的命令或循环时。
展开细节

问三个问题：连跑两次会怎样？上次中途崩溃会怎样？重跑是否收敛？

principle-make-operations-idempotent

看中文译文 →

Migrate Callers Then Delete Legacy APIs

架构

在同一波里迁移调用方，并删除旧 API。

什么时候用
引入新的内部 API，而旧调用方还在时。
展开细节

临时适配器是例外，而且要限时。

principle-migrate-callers-then-delete-legacy-apis

看中文译文 →

Separate Before Serializing Shared State

架构

先去掉共享，再加协调。

什么时候用
并发的行动者可能写同一个文件、分支或键时。
展开细节

给每个行动者自己的文件或分支。只有单一写入者是真正的不变量时，才加锁。

principle-separate-before-serializing-shared-state

看中文译文 →

验证定义什么算证明。

Prove It Works

验证

验证真实产物，不验证替身。

什么时候用
完成任务之后、宣布做完之前。
展开细节

「能编译」不算证据。能写脚本就写脚本，留下可重跑的输出。

principle-prove-it-works

看中文译文 →

Fix Root Causes

验证

改代码之前先复现，并追溯到根因。

什么时候用
调试时。
展开细节

不用空值检查把崩溃消音。重启后才坏，先怀疑持久化的状态。

principle-fix-root-causes

看中文译文 →

Sequence Work into Verifiable Units

验证

每个小单元以一次检查结束，再开始下一个。

什么时候用
多步工作，以及叠放提交和 PR 时。
展开细节

交付顺序本身就是证明：先放失败的测试，再放修复。

principle-sequence-verifiable-units

看中文译文 →

Test Behavior, Not Implementation

验证

按用户的方式调用代码，对字面期望值做断言。

什么时候用
写、改或保留一个测试时。
展开细节

每个导入的函数都返回 undefined 时测试还能过，就改断言或删测试。

principle-test-behavior-not-implementation

看中文译文 →

委派让并行工作保持可控。

Guard the Context Window

委派

把大量阅读交给子代理，把 finding 留在主对话里。

什么时候用
上下文快满时：大输出、长文件、反复读取。
展开细节

常用的模板放进 skill 文件，少一次读取。

principle-guard-the-context-window

看中文译文 →

Never Block on the Human

委派

在可逆的工作上继续前进，并交出结果。

什么时候用
想在可逆的工作上问「要不要做 X」时。
展开细节

不可逆动作仍要确认：force-push、删生产数据、发外部消息。

principle-never-block-on-the-human

看中文译文 →

元把反复出现的纠正变成机制。

Encode Lessons in Structure

元

把重复过两次的建议变成 lint、检查或脚本。

什么时候用
第二次写同一条指示，或同一个纠正反复出现时。
展开细节

选能用的最强机制：编译不过，强于 CI lint，强于运行时检查。

principle-encode-lessons-in-structure

看中文译文 →

小结

  1. 先跑 /setup-pstack，再用 /poteto-mode 交任务。提示词里写目标和检查办法。
  2. 大多数 skill 由 /poteto-mode 按步骤调用。你直接输入命令，是想单独用某一步。
  3. 顺序是：理解代码，设计，构建与清理，验证。长任务加上决策日志，做完以后复盘。
  4. 原则不用调用。在提示词里写原则名，给 agent 改道。
去 pstack.ganhai.cloud 看中文译文和官方指南 →

本页根据 pstack 0.15.5（提交 12d587d）里的 SKILL.md 整理。

本站是非官方的 pstack 中文学习站，和 poteto 没有隶属关系。译文对照的是 cursor/plugins 仓库里的 pstack/ 目录。本站不发行中文版插件。 github.com/cursor/plugins

鲁ICP备2025189036号