pstack-claude: Making AI Agent Workflows Portable Across Harnesses

The Scenario: One Workflow, Six AI Assistants

Suppose you've built a set of workflows in Cursor called pstack—it defines how to fix bugs, do code reviews, and plan features. Switch to Claude Code, and the workflows are gone. Switch to Codex, and you configure everything from scratch. Every AI coding assistant has its own "skills" format, and none are interoperable.

What pstack-claude does is simple: it translates Cursor's workflow primitives into formats understood by Claude Code, Codex, Pi, OpenCode, Gemini, and Prime Agent. One workflow definition, runnable on six AI assistants.

This sounds like a simple "translator" project, but it points to a deeper trend: AI agent workflow definitions are becoming portable artifacts—assets that, like code and config files, can move across platforms.

What Is pstack?

pstack began as a skill stack Lauren Tan (poteto) created for Cursor. It defines rigorous agent workflows—not simple prompt templates, but complete methodologies with roles, processes, and verification steps.

For example, pstack's bug-fix workflow is:

1. Reproduce the failure: confirm the bug is stably reproducible 2. Investigate the how and why: understand the root cause, not just the symptom 3. Delegate the fix: let the agent implement it 4. Rerun the failing case: verify the fix works 5. Bring in the architect across function boundaries: if the fix touches multiple functions, run an architecture review first

This is not a prompt—it's a process definition. It has state (which step you're on), conditional branches (crossing function boundaries?), and role switches (implementer → architect).

The Core Challenge of Translation

Translating pstack from Cursor to other harnesses is not simple text substitution. Each harness differs in:

• Skill format: Cursor uses .mdc files, Claude Code uses SKILL.md, Codex has its own format
• Invocation: Cursor slash commands, Claude Code /command, Codex @skill
• Context management: each harness handles session context differently
• Tool interfaces: each exposes different tool APIs

pstack-claude's approach: keep workflow semantics constant, adapt the invocation interface. The "fix-a-bug process" has identical semantics in every harness—reproduce, investigate, fix, verify. Only invocation is harness-specific—/pstack:fix in Claude Code, @pstack fix in Codex.

This resembles the POSIX philosophy: POSIX defines the semantics of open(), read(), write(); different operating systems (Linux, macOS, FreeBSD) implement them, and programs just target the POSIX interface. pstack defines the "interface" of agent workflows; different harnesses provide the "bindings."

Poteto Mode: Automatic Workflow Routing

pstack-claude introduces an interesting concept called poteto-mode. You don't need to remember "use /pstack:fix for bugs, /pstack:review for code reviews." You just state your goal:

> "Fix the search filter resetting when I switch pages"

poteto-mode recognizes this as a bug-fix task and invokes pstack's fix workflow. A feature request routes to the feature workflow; a performance issue routes to the performance workflow.

This is a routing layer—an abstraction between user intent and workflow definitions. Users don't need to know which workflows exist; they just describe the goal, and the agent routes itself. It mirrors LLM routers: an LLM router routes prompts to the best-suited model, poteto-mode routes goals to the best-suited workflow. Both add an intelligent middle layer between caller and callee.

Policy Forks: Variants of the Same Workflow

pstack-claude has a mechanism called policy forks. Different teams may have different policy preferences for the same workflow:

• Team A's code review requires two human reviewers
• Team B allows one human reviewer + one AI reviewer
• Team C is fully automated

pstack-claude lets each team maintain its own policy fork while tracking upstream pstack updates—like a Git fork: you fork, make your changes, and can rebase upstream updates.

It's a clever design. It acknowledges that there is no single correct workflow—teams differ in staffing, risk tolerance, and automation level, so one workflow definition must support variants. Policy forks make variant management tractable instead of forcing every team to redefine workflows from scratch.

Formal Verification: More Than Prompts

The most unusual aspect of pstack-claude is its inclusion of formal verification:

• TLA+ model checking: define the workflow as a state machine in TLA+, verify there are no deadlocks and all paths reach terminal states
• Lean proofs: prove key workflow properties (e.g., "verification after a fix cannot be skipped")

This is rare in AI agent tooling. Most agent tools are prompt + scripts with no formal guarantees. pstack-claude treats the workflow as a system requiring verification—like distributed systems, compilers, or OS kernels, whose correctness must be mathematically proven. It reflects a belief: as AI agents make more critical decisions, workflow correctness cannot rest on "try it and see." TLA+ and Lean are the tools for that proof.

No Server, No Telemetry

pstack-claude's data policy is clean:

> "pstack has no server or telemetry. Anything its skills ask your agent to read, including session transcripts, goes to your model provider. Scripts run locally, and PR tools use your GitHub CLI login."

No server, no telemetry. Everything skills read (including session transcripts) goes directly to your model provider (Anthropic, OpenAI, etc.). Scripts run locally; PR tools use your own GitHub CLI login. Your workflow definitions, code, and session records stay on your machine and with your model provider. pstack-claude is only a translation and routing layer.

The Bigger Trend: Workflow Definitions as First-Class Citizens

pstack-claude points to a trend bigger than the project itself: AI agent workflow definitions are shifting from "configuration attached to a specific tool" to "portable first-class citizens."

The analogy with programming language ecosystems:

1. Early: every editor had its own macro language (Emacs Lisp, Vim script), mutually incompatible 2. Middle: LSP (Language Server Protocol) emerged, making language analysis portable—one language server could serve any editor 3. Now: every AI agent has its own skills format, mutually incompatible 4. Future: a "workflow definition protocol" emerges, making workflows portable—one workflow can run in any agent harness

pstack-claude is an early instance of this trend. It's not a protocol—it's a specific translation of a specific workflow (pstack). But it proves translation is feasible and that workflow definitions really can move across harnesses.

If the trend continues, we may see an "Agent Workflow Protocol"—to agent workflows what LSP was to editors. Any harness implementing it could run any conforming workflow definition, and translation projects like pstack-claude would become unnecessary—the interface would be unified.

Until that day, pstack-claude is a practical bridge: it keeps the workflow expertise you've built in Cursor from being locked into Cursor.

Conclusion

What pstack-claude does looks simple—translating workflow definitions. But the problem it points to runs deep: once agent workflow definitions become portable, your choice of agent becomes an implementation detail rather than an architectural decision. You can use Claude Code today, switch to Codex tomorrow, try Gemini the day after—your workflows come with you.

It's the same value as code portability: not to make switching tools easier, but so that tools serve you, not the other way around. When workflow definitions are portable, tool competition returns to "who implements workflows better," not "who locks in more users."

Project: https://github.com/michael-denyer/pstack-claude