pstack 安装与初始化指南：从 /add-plugin 到 /setup-pstack 的角色模型配置与首个任务实践-平芜编程栈

pstack 安装与初始化指南：从 /add-plugin 到 /setup-pstack 的角色模型配置与首个任务实践

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins

pstack 是 Cursor 官方插件市场中的一个工程风格插件，它把严格的工程原则打包成一组 skill 与 playbook。本篇以官方指南第一页 Set up pstack 为主体，完整覆盖「安装插件、选择模型、决定是否生成验证 skill、跑通第一个任务」四个环节，并结合仓库内的 setup-pstack 技能定义与 poteto-mode 技能源码，讲清每一步背后实际发生了什么。读完本篇，你可以独立完成 pstack 的初始化配置，理解~/.cursor/rules/pstack-models.mdc规则文件的结构与回退机制，并用/poteto-mode启动第一个带 playbook 路由的真实任务。

安装插件

安装只有一条命令。在 Cursor 的聊天框中运行：

/add-plugin pstack

Cursor 会确认插件已安装。这与 pstack README 中的 install 章节一致：整个插件的入口就是这一条斜杠命令，无需手动克隆或拷贝文件。安装完成后，pstack 带来的是一组斜杠技能（/poteto-mode、/how、/why、/swarm等）、若干 playbook 以及poteto-agent子代理，它们由/poteto-mode按需调度，这也是后文「跑第一个任务」时观察到的路由行为的基础。

用 /setup-pstack 选择每个角色使用的模型

安装完成后，运行：

/setup-pstack

这一步的作用是为 pstack 的各个「角色」（code delegates、judgment、review panels 等）指定模型。结合 setup-pstack 的 SKILL.md，该技能实际按七步执行，比表面的一条命令要精细得多：

检测可用模型：枚举当前会话中能传给Task子代理的模型 slug，这是最可靠的来源；若 Cursor 提供了列出用户可用模型的 API 或 CLI，则优先使用它以保证完整性。检测不到时会要求用户粘贴 slug 列表。关键约束是「绝不写入一个未确认可用的真实 slug」，而inherit-parent与auto两个别名永远有效，无需检测。
加载现状：若~/.cursor/rules/pstack-models.mdc已存在，则读取其中内容作为当前选择；否则从默认映射开始。
映射并确认：列出所有角色及其当前模型，把不在已检测集合中的真实 slug 标记为「需要选择」。提供已检测模型加inherit-parent、auto作为选项，并优先用 AskQuestion 而非自由文本。
校验：写入的每个真实 slug 必须在已检测集合内，inherit-parent和auto直接通过；选到不可用的真实 slug 就停下来重新询问。
写规则文件：见下文的规则文件结构。
确认：告知用户规则已写入、对新会话生效，且重跑该技能会更新规则。
提供验证 skill 选项：见下一节。

规则文件的结构与默认值

/setup-pstack写入~/.cursor/rules/pstack-models.mdc，这是一个alwaysApply: true的规则文件，pstack 的每个 skill 都会读取它。SKILL.md 中给出的完整形状如下：

--- description: pstack per-role model choices (overrides skill defaults) alwaysApply: true --- # pstack model configuration. One line per role. Delete a line to fall back to the skill default. # `inherit-parent` or `auto` as a value: the role runs on the parent chat model (omit Task `model`). Alias entries in a panel list still count toward its fan-out. feature, refactoring: grok-4.6-fast-xhigh bug-fix: grok-4.6-fast-xhigh perf-issue: grok-4.6-fast-xhigh hillclimb: grok-4.6-fast-xhigh judgment and prose: claude-fable-5-1-thinking-max hardest tasks: claude-fable-5-1-thinking-max how explorer: grok-4.6-fast-xhigh how explainer: claude-fable-5-1-thinking-max why investigators: grok-4.6-fast-xhigh why synthesizer: claude-fable-5-1-thinking-max reflect tooling: gpt-5.6-sol-max reflect judgment, divergent, synthesizer: claude-fable-5-1-thinking-max arena runners: claude-fable-5-1-thinking-max, gpt-5.6-sol-max, grok-4.6-fast-xhigh, claude-opus-5-thinking-xhigh arena cross-judge pool: claude-fable-5-1-thinking-max, gpt-5.6-sol-max, grok-4.6-fast-xhigh, claude-opus-5-thinking-xhigh swarm workers: grok-4.6-fast-xhigh architect runners: claude-fable-5-1-thinking-max, gpt-5.6-sol-max, grok-4.6-fast-xhigh, claude-opus-5-thinking-xhigh interrogate reviewers: claude-fable-5-1-thinking-max, gpt-5.6-sol-max, grok-4.6-fast-xhigh, claude-opus-5-thinking-xhigh

从这份模板可以读出几个设计要点：

按角色一行一个，缺省即回退：规则文件覆盖的是「显式写出的行」。没有对应行的角色保持 skill 内置默认值；想恢复默认，删掉那一行即可，或者直接重跑/setup-pstack。这与 poteto-mode SKILL.md 中的子代理默认值相互印证：代码类委托（feature、refactoring、bug-fix 等）默认走快模型grok-4.6-fast-xhigh，prose 与判断类角色默认走claude-fable-5-1-thinking-max。
面板角色的值是列表，列表长度决定 fan-out 数量：arena runners、architect runners、interrogate reviewers等面板角色每列出一次模型就运行一个子代理，因此把一行删成 2 个模型，面板就从 4 席变 2 席。别名条目（inherit-parent/auto）计入列表长度。唯一的例外是arena cross-judge pool：它也是列表，但 Arena 会从中挑选一个与父代理模型家族不同的值，用于交叉评审。
swarm workers是/swarm全体 worker 的默认模型，除非某次 race 或对比为每个臂单独指定了模型。
幂等写入：每次运行整体覆写该文件，保证重复执行不产生漂移。

Auto 用户的行为说明

如果你习惯用 Auto，可以把手动角色设为inherit-parent或auto。这两个值含义相同，且都不是模型 slug：pstack 会省略该子代理Task调用中的model字段，让子代理继承父聊天的模型——这正是指南原文中「Both values mean the same thing, and neither is a model slug」的机制含义。换句话说，Auto 用户设置后仍停留在 Auto 上，不会被锁死到某个具体模型。

验证 skill：接受一次性的生成提议，或跳过

setup 的最后一步是/setup-pstack会检查你的项目里有没有「证明应用行为」的手段：一个verify-*skill，或任何现成的 harness。两者都没有时，它会一次性提议用/create-verification-skill生成一个。

同意：它会写入.cursor/skills/verify-<app>/，这是一个项目本地的 skill，教 agent 以用户的方式驱动你的应用。根据 create-verification-skill 的 SKILL.md，生成物包含 Launch、Doctor、Drive、Evidence、Cleanup、Helpers 等章节，外加一份 feature map（features/README.md加每功能一个文件），并且生成后会先完整跑一遍自己的指令（启动、doctor、驱动一个已映射功能、取证、清理），确认取证产物在清理后仍然存在，才交付。「A generated skill that was never executed is a draft, not a deliverable」是它的硬性要求。
拒绝：setup 直接继续，不纠缠。任何时候都可以自己手动运行/create-verification-skill。

关于「什么时候值得要一个验证 skill」的完整讨论，见指南的 Verify and ship 一节。

最后注意一条时序约束：setup 完成后，开一个新聊天。模型规则对新会话生效，当前会话不会被追溯应用。

跑第一个任务：观察 playbook 路由与 todo 列表

选择一个真实但小的任务，用你平时跟同事描述任务的方式写出来：

/poteto-mode add a --json flag to this command. text output stays byte-identical. verify both.

接下来观察三件事，它们分别对应 pstack 的三个核心机制：

todo 列表的首批条目是被匹配 playbook 的步骤原文。上面这个 prompt 会命中 Feature playbook，feature.md 定义的 8 个步骤（how调研子系统、architect并行设计探索、写吞吐检查点、委托代码子代理、在对的表面验证、rebase 成小的有序提交、必要时interrogate、最后跑 Opening a PR）会被逐字拷贝进 todo 列表。这一步的行为依据在 poteto-mode SKILL.md 的 Playbooks 一节：「Open a todolist whose first items are the matched playbook's steps, copied in verbatim」。
跳过的步骤会留下理由。如果/poteto-mode选择跳过某一步，该步骤不会从列表消失，而是保留并附上skip: <reason>，让你清楚它选择不做什么。Feature playbook 中明确写着，例如architect步骤若跳过「stays asarchitect skipped: <reason>」。这提供了可审计的决策痕迹，而不是静默省略。
模式是 sticky 的。从第一个任务之后，你可以直接输入普通的后续消息，/poteto-mode会保持开启，贯穿整个会话，直到你明确说出要退出。这与 poteto-agent 子代理定义中「resume an existingpoteto-agentfor the conversation rather than spawning a sibling」的语义一致：同一会话内复用同一个模式载体。

另外值得留意的是，这个示例 prompt 本身就演示了 pstack 推荐的表达方式：给出目标（加--jsonflag）+ 给出可检验的完成标准（text 输出保持字节级一致、两种输出都要验证）。指南总览页 The pstack guide 的「If you only remember one thing」一节也是同样的范式：不需要点名 playbook 或 skill，「repro first」加一个可检查的结果就是/poteto-mode路由所需的全部信号。