pstack-claude：把 Cursor 工作流带到 Claude Code 等智能体环境
给Claude Code等智能体复用Cursor pstack工作流，靠poteto-mode自动路由并提供验证证据。
GitHub michael-denyer/pstack-claude 更新 2026-11-03 分支 main 星标 3.8K 分叉 347
TypeScript 智能体工作流 poteto-mode Claude Code TLA+ Lean

🧭 决策指南

为什么现在热： 无法从材料判断

适合，如果你

  • 你使用Claude Code 2.1.292+，希望让poteto-mode自动路由修复、重构或调查任务。
    README的“Install”和“Configure”章节要求Claude Code 2.1.292+，并说明SessionStart hook会指向poteto-mode。
  • 你的问题包含测试难覆盖的并发错误或不变量，并需要TLA+、Lean或Kani工作流。
    README开头说明/create-formal-verification-skill用于并发错误和不变量，并列出TLA+、Lean与Kani。
  • 团队在Codex、Pi、GitHub Copilot或Muse之间切换，需要同一套pstack技能。
    README的“Install”章节分别提供Codex、Pi、GitHub Copilot和Muse安装方式。
  • 你希望脚本在本地运行，并接受会话内容发送给模型提供商。
    README的“Data handling”章节说明没有服务器或遥测，脚本本地运行，但技能要求读取的内容会发送给模型提供商。

不适合，如果你

  • 你的环境低于Claude Code 2.1.292，无法满足README列出的安装版本。
    README的“Install”章节明确写明Run in Claude Code 2.1.292 or later。
  • 你依赖Copilot 1.0.92中的copilot -p非交互会话调用插件技能。
    README说明Copilot 1.0.92缓存computer-use实验分配后，copilot -p会列不出插件技能并返回Skill not found。
  • 你要求OpenCode或Gemini CLI自动路由到poteto-mode，而不愿添加名称调用或standing instruction。
    README的“Configure”章节说明其他harnesses没有hook，需要按名称请求poteto-mode或添加standing instruction。
  • 你的组织禁止把技能读取的session transcripts发送给模型提供商。
    README的“Data handling”章节明确说明这类内容会发送给model provider。

前置条件

  • Claude Code 需为2.1.292或更高版本。
  • Codex需通过/hooks信任其hook；Muse需运行muse plugins approve pstack。
  • GitHub Copilot构建已在Copilot CLI 1.0.87至1.0.92测试。
  • OpenCode、Gemini CLI、Prime Agent及skills-only Codex需要使用~/.agents/skills/。
  • PR工具使用GitHub CLI登录；技能读取的内容会发送给模型提供商。

第一步命令（README 原文）

/plugin marketplace add michael-denyer/pstack-claude

要注意

  • Claude Code第三方Marketplace安装后不会自动更新，需在Marketplaces中开启Enable auto-update或运行claude plugin update。
    README的“Install”章节明确说明第三方marketplace默认关闭自动更新，并给出手动更新命令。
  • Codex只有在通过/hooks信任hook后才会执行自动路由。
    README的“Configure”章节说明Codex runs the hook only after you trust it through /hooks。
  • Muse安装后还要执行muse plugins approve pstack，否则SessionStart hook和agent definitions不会运行。
    README的Muse安装段落说明这些功能仅在批准后运行。
  • 共享skills安装使用符号链接，更新时需在clone目录执行git pull并重新运行for循环。
    README的“Other harnesses”段落给出了git pull和for循环更新流程。

替代方案

  • Cursor upstream pstack：你直接使用Cursor，并希望使用Lauren Tan的原始Cursor skill stack而不是其他harness的移植版。
    README开头的pstack说明
  • agent-formal-verify：你需要比/create-formal-verification-skill更深入的形式化验证方法指导，包括TLA+ model checking、Lean proofs和Rust的Kani。
    README开头的formal verification说明

材料未说明

  • README所链接的Models and dependencies章节具体列出的模型名称、版本和依赖未提供。
  • README没有给出pstack工作流的运行耗时、token消耗或修复成功率。
  • README没有说明OpenCode、Gemini CLI和Prime Agent的具体兼容版本。
  • README没有提供5个版本之间的变更范围或0.9.120的发布说明。
  • README没有给出10位贡献者对应的维护分工或响应时效。

💡 深度解析

6
不适合 我维护包含并发错误和状态不变量的代码，常规测试无法覆盖关键属性；希望代理选择 TLA+、Lean 或 Kani 并留下可重复的项目技能，pstack-claude 是否适合替代常规测试？
适合读者： 维护并发、状态机或协议代码，并希望用 TLA+、Lean 或 Kani 验证测试难以覆盖的不变量的开发者

不适合把它当作常规测试的替代品；它适合为高风险属性增加形式化验证工作流，而不是证明整个系统没有缺陷。

  • /create-formal-verification-skill 会从代码中挑选最有风险的属性，并匹配合适工具，再留下供后续代理重跑的项目技能。
  • README 明确把 TLA+、Lean 和 Kani 定位为并发错误与测试难以触达的不变量验证工具。
  • 项目另有 agent-formal-verify 插件，提供 TLA+ 模型检查、Lean 证明和 Rust 的 Kani，说明形式化验证是专门工作流，不是普通测试框架。
  • 验证结论受属性选择、模型边界、工具支持和代码抽象影响；README 也强调形式化验证不能等价于整个系统无缺陷。
  • README opening: “For concurrency bugs and invariants that tests cannot reach”
  • README opening: “/create-formal-verification-skill picks the riskiest property ... and leaves a project skill the next agent reruns”
  • README opening: “guided TLA+ model checking, Lean proofs, and Kani for Rust”
  • 项目洞察 / usage limitations: “形式化验证并不等价于证明整个系统无缺陷”
材料未说明：README 未说明你的具体语言、并发模型和代码规模是否能被 TLA+、Lean 或 Kani 有效抽象。；README 未说明生成的验证技能会产生何种模型边界、证明覆盖范围或运行时间。
适合 我正在 Claude Code 2.1.292+ 中维护一个项目，希望输入一个搜索筛选器缺陷后，代理能自动复现失败、调查原因、实施修复并给出通过证据；pstack-claude 是否适合？
适合读者： 使用 Claude Code 2.1.292 或更高版本、希望让缺陷修复自动经过复现与回归验证的个人开发者

适合，因为 Claude Code 是项目明确支持的宿主，而且 poteto-mode 的缺陷流程正好覆盖复现、调查、修复和再次验证。

  • README 要求 Claude Code 版本为 2.1.292 或更高，并提供原生 marketplace 安装方式。
  • Claude Code 安装前会把上游 Cursor skill 名称翻译好，避免运行时映射带来的额外 token 和调用错误。
  • 缺陷 playbook 会使用 how 和 why 调查；若修复跨越函数边界，还会先引入 architect。
  • SessionStart hook 会把任务引导到 poteto-mode，但第三方 marketplace 默认不自动更新，版本更新需要显式开启或手动执行。
  • Install / Claude Code: “Run in Claude Code 2.1.292 or later”
  • Built for Claude Code: “translates upstream's Cursor skills for Claude Code before installation”
  • Getting started: “it reproduces the failure, uses how and why to investigate, delegates the fix, then reruns the failing case”
  • Install / Claude Code: “auto-update off for third-party marketplaces”
/plugin marketplace add michael-denyer/pstack-claude
材料未说明：README 未说明该流程对你的具体测试框架、构建系统和模型配额的实际耗时与成功率。；README 未说明 SessionStart hook 是否会与你现有的 Claude Code 插件发生上下文冲突。
视情况 我使用 Copilot CLI 1.0.87–1.0.92，并希望 Copilot CLI 和 GitHub Copilot app 共用 `~/.copilot`；我们的自动化还会调用非交互式 `copilot -p`，pstack 是否适合直接投入使用？
适合读者： 在 Copilot CLI 1.0.87–1.0.92 上工作的团队成员，需要让 Copilot CLI 与 Copilot app 共用 pstack 配置

视情况：交互式 Copilot 使用基本匹配，但依赖 copilot -p 的自动化不宜直接假定可用。

  • README 明确说插件同时安装到 Copilot CLI 和 Copilot app，共用 ~/.copilot，新安装后要启动新会话。
  • Copilot CLI 1.0.87–1.0.92 是项目测试范围；这些版本通常能把 routing hook 上下文带入会话。
  • README 特别指出 1.0.92 在缓存 computer-use 实验分配后，copilot -p 可能不显示插件技能，并返回 Skill not found；交互式会话、hook 和 agents 不受影响。
  • Copilot 没有默认 pstack 模型，首次需要模型的技能会运行 setup-pstack，从账户列出的模型中选择。
  • Install / GitHub Copilot: “This installs pstack for the Copilot CLI and the GitHub Copilot app, which share ~/.copilot”
  • Install / GitHub Copilot: “tested on Copilot CLI 1.0.87 through 1.0.92”
  • Install / GitHub Copilot: “copilot -p sessions list no plugin skills and a skill call returns ‘Skill not found’”
  • Install / GitHub Copilot: “Copilot ships no default pstack models”
copilot plugin marketplace add michael-denyer/pstack-claude
材料未说明：README 未说明 1.0.92 之后的 Copilot CLI 是否已经修复 `copilot -p` 的 Skill not found 问题。；README 未说明账户列出的模型是否满足每个 pstack 角色的推理能力或组织合规要求。
适合 我在 Muse 中希望使用 `/poteto-mode`，但团队规定插件的 SessionStart hook 和 agent 定义必须先审批；pstack-claude 的安装和会话行为是否符合这个约束？
适合读者： 使用 Muse，并要求插件的 SessionStart hook 和 agent 定义经过显式审批后才进入团队会话的开发者

适合，因为 Muse 的安装流程把插件安装与 hook、agent 定义的审批分开，符合显式授权约束。

  • README 要求先 clone 项目，再执行 muse plugins install ./plugins/pstack 安装原生插件包。
  • 随后必须运行 muse plugins approve pstack；Muse 只有在批准后才运行其 SessionStart hook 和 agent definitions。
  • 启动新会话后，可以用 / 调用技能，例如 /poteto-mode，并且 Muse 会列出可由用户调用的技能。
  • 该宿主的自动路由依赖审批状态；如果只完成安装而没有 approve，不能假定 poteto-mode 会在会话启动时自动接管任务。
  • Install / Muse: “muse plugins install ./plugins/pstack”
  • Install / Muse: “muse plugins approve pstack”
  • Install / Muse: “Muse runs only after approval”
  • Install / Muse: “Invoke a skill with / (for example /poteto-mode)”
git clone https://github.com/michael-denyer/pstack-claude
材料未说明：README 未说明 Muse 的审批是否能按项目、用户或组织范围细分。；README 未说明已批准的 hook 与团队现有 SessionStart 扩展发生冲突时的处理顺序。
适合 我使用 OpenCode CLI，不支持 routing hook，只能从 `~/.agents/skills/` 读取技能；我是否仍能使用 `poteto-mode`，以及安装后哪些行为不会自动发生？
适合读者： 使用 OpenCode、Gemini CLI 或 Prime Agent，并只能通过 `~/.agents/skills/` 共享目录加载技能的开发者

适合，但只能获得共享技能目录的能力，不能获得带 routing hook 的自动任务分发。

  • README 将 OpenCode CLI、OpenCode desktop app、Gemini CLI 和 Prime Agent 列为共享安装支持对象，技能从 ~/.agents/skills/ 读取。
  • 提供了从 clone、创建目录到逐个符号链接技能的完整命令；更新时需要在 clone 中执行 git pull，再重新运行链接循环。
  • 这些宿主没有 routing hook，因此必须明确要求 poteto-mode，或在宿主 instruction 文件中添加 standing instruction。
  • 符号链接依赖本地 clone 路径；删除 clone 或改变目录会使链接失效。这样适合愿意管理本地技能目录的用户，不适合期待插件安装后完全自动接管会话的人。
  • Other harnesses: “OpenCode ... Gemini CLI, Prime Agent ... read skills from ~/.agents/skills/”
  • Other harnesses: “These installs have no routing hook, so ask for poteto-mode by name or add a standing instruction”
  • Other harnesses: “To update, run git pull in the clone, then run the for loop again”
  • User experience / common pitfalls: “deleting the clone or changing the directory will make ... links fail”
git clone https://github.com/michael-denyer/pstack-claude
材料未说明：README 未说明 OpenCode、Gemini CLI 和 Prime Agent 对 slash command、agent 委派及模型选择的具体差异。；README 未说明共享技能目录与这些宿主既有技能同名时的覆盖或优先级规则。
视情况 我在 Codex CLI 中同时处理修复、规划和 PR 维护，希望会话启动时自动把任务路由到 `poteto-mode`；但我们要求显式审批 hook，这个项目是否适合？
适合读者： 使用 Codex CLI、需要在信任 hook 后统一处理修复、规划和 PR 维护任务的工程师

视情况：适合接受 /hooks 信任流程的 Codex 环境，不适合要求所有会话默认零审批的环境。

  • README 提供 Codex marketplace 安装命令，并明确列出规划、PR 维护、发布和长期项目等 playbook。
  • Codex 的 routing hook 只有在通过 /hooks 信任后才运行；未信任时，自动路由不会按预期生效。
  • poteto-mode 统一接收用户目标，再选择具体工作流，适合把多类工程任务纳入同一入口。
  • 代码和会话内容仍会交给配置的模型提供商；项目本身没有服务器或遥测，但这不等于 Codex 链路没有数据治理要求。
  • Install / Codex: “codex plugin marketplace add michael-denyer/pstack-claude”
  • Configure: “Codex runs the hook only after you trust it through /hooks”
  • Getting started: “Other playbooks cover planning, features, refactoring, performance issues, investigations, prototypes, PR maintenance, shipping, and longer projects”
  • Data handling: “pstack has no server or telemetry”
codex plugin marketplace add michael-denyer/pstack-claude
材料未说明：README 未说明 Codex 当前版本要求，也未说明 `/hooks` 信任策略能否由组织策略集中管理。；README 未量化自动路由相对直接调用技能增加的模型调用次数和成本。

✨ 核心亮点

  • poteto-mode按任务自动选择pstack工作流并复跑失败案例
  • create-formal-verification-skill支持TLA+、Lean与Kani验证
  • 覆盖Claude Code、Codex、Pi、Copilot与Muse
  • 社区规模为3,801星、347 forks和10位贡献者

🔧 工程化

  • SessionStart hook把Claude Code任务路由到poteto-mode
  • bug流程用how、why调查并返回失败与通过证据
  • setup-pstack可切换路由、模型默认值和角色推理强度
  • 无服务器和遥测，脚本本地运行，PR工具使用GitHub CLI登录

⚠️ 风险

  • Claude Code需2.1.292或更高版本才能安装
  • Copilot 1.0.92的copilot -p可能找不到插件技能
  • 第三方Marketplace默认关闭自动更新，需手动开启
  • OpenCode与Gemini CLI没有routing hook，需手动调用poteto-mode

👥 适合谁？

  • 使用Claude Code 2.1.292+并希望复用Cursor pstack的团队
  • 需要TLA+、Lean或Kani处理测试难覆盖不变量的开发者
  • 同时使用Codex、Pi、Copilot或Muse的多智能体环境