pstack-claude: named policy forks, a routing hook that needs trust, and four licence files

The port declares named policy forks, so it is not a mirror of upstream

The upstream is not a standalone repository. pstack lives inside the Cursor plugins monorepo at `https://github.com/cursor/plugins/tree/main/pstack`, and this project describes itself as a port that tracks upstream and also carries named policy forks, each declared in `tools/forks.json`.

That single clause sets the terms for everything else here. A faithful port can be diffed against its source. This one is declared to diverge on named points, which means the two artefacts answer the same version question differently and you have to know which fork you are reading before comparing behaviour. The mechanism is a machine-readable file rather than prose, so `tools/forks.json` is the first place to look, not the README.

Two other root files carry the history that a divergence-based port needs. `CHANGES.md` sits next to `CONTEXT.md`, and `CONTRIBUTING.md` is where contributors are told which checks apply and where a change belongs, which in a fork-tracking repository is the question of whether a change belongs upstream, in a local fork declaration, or in neither.

The attribution line adds a third source. Alongside the original pstack, the repository credits imported cursor-team-kit skills to Cursor, which is why a second licence file exists at the root.

With a release cadence this fast, `tools/forks.json` is also the file worth diffing between two tags. It is the one artefact that records declared divergence in a form a diff can read, where `CHANGES.md` records it in prose.

Five harness targets, two install paths written out, three delegated to a reference document

The repository description names five targets: Claude Code, Codex, OpenCode, Gemini, and Prime Agent. The README writes out install commands for two of them.

For Claude Code the fence is marked as text, not shell, because the commands are slash commands typed inside the agent rather than run in a terminal.

/plugin marketplace add michael-denyer/pstack-claude
/plugin install pstack@pstack-claude

For Codex the same two operations are shell commands with a `codex` prefix.

codex plugin marketplace add michael-denyer/pstack-claude
codex plugin add pstack@pstack-claude

Prime Agent, OpenCode, Gemini CLI, and skills-only installs for any harness are all pointed at a shared installation section in the reference documentation instead. So the claim of five supported harnesses rests on two inline recipes plus one deferred link, and the deferred group is the larger one. The skills-only path is the interesting case, because it is the only one that implies the routing hook is optional rather than automatic.

Note also what the install surface is. Both recipes take a GitHub repository path, so distribution is by marketplace reference rather than by a package registry, and there is no version argument in either command. You get whatever the default branch holds at the moment you run it.

The routing hook runs automatically on Claude Code and waits for approval on Codex

The plugin installs a routing hook on both harnesses, and the two behave differently. On Claude Code it is in place after install. On Codex the plugin asks you to trust it through `/hooks` before it runs.

Neither install command mentions this. The Claude Code pair adds a marketplace and installs the plugin; the Codex pair adds a marketplace and adds the plugin. Nothing in either block warns that a hook is being installed, and nothing in either block tells the Codex user that a second approval step is now outstanding.

The consequence is a quiet difference in behaviour between two installs that look identical from the outside. On one harness, telling `poteto-mode` your goal is enough to reach the correct workflow. On the other, the same request may do nothing useful until you open `/hooks` and approve, and the symptom looks like the skill ignoring you rather than like a pending permission.

That is also why the skills-only install path is worth distinguishing from the full plugin install. A harness that only receives the skills has no routing hook to trust, so the dispatch behaviour described in the next section has to be triggered some other way.

What the hook is permitted to do once trusted is not stated in the visible text. You are approving an unnamed capability on Codex, and the approval is per harness rather than per repository, so it is worth looking at what the hook does in `plugins/` before you grant it.

setup-pstack edits model defaults, a per-role effort sheet, and whether routing happens at all

Three distinct settings sit behind one command, which the README refers to as `setup-pstack` and, on Claude Code, `/pstack:setup-pstack`.

The first is model defaults. The second is a reasoning effort assigned per role, given as a sheet line such as `arena runners: opus @xhigh, fable @max`. Claude Code dispatches through agents named `pstack:effort-<level>` or `pstack:poteto-agent-<level>`, so the effort level becomes part of the agent identity rather than a session-wide setting. The fallback is stated too: roles without a level keep the session's effort unless the sheet's `default effort` line names one, which means an unset role silently inherits whatever the session is already using.

The third is automatic routing itself, which can be turned off. Once it is off, dispatch is whatever you type, so the playbooks that assume they were selected for you have to be invoked by hand.

The shape of this interface is a plain text sheet rather than a validated schema, and the example mixes vendor names, effort levels and a role label in one line. That is easy to read and easy to get subtly wrong: a typo in the role name does not error, it just leaves that role on the inherited default.

Four root licence files for three copyright holders

The licence section names three parties and points at two of the documents. This port, including its modifications and additions, is MIT licensed and attributed to Michael Denyer. The original pstack is attributed to Lauren Tan. Imported cursor-team-kit skills are attributed to Cursor, with a link to `LICENSE-cursor-team-kit` and to `NOTICE.md`.

The root of the repository carries four relevant files: `LICENSE`, `LICENSE-cursor-team-kit`, `NOTICE.md`, and `NOTICE-skills.md`. The README's licence paragraph references the first, the second, and `NOTICE.md`. `NOTICE-skills.md` is present in the tree and is not named anywhere in the visible text.

For imported material that gap is the one to care about. If you copy a skill out of this plugin into your own configuration, the file that travels with it is the one that decides your obligations, and there is a second notice file whose scope the visible text does not define.

There is a naming wrinkle upstream as well. The repository description calls the source Poteto's pstack, while the README calls it Lauren Tan's pstack. Poteto also appears throughout the command and agent naming, in `poteto-mode` and `pstack:poteto-agent-<level>`. Both names refer to the same upstream stack; just do not search for one and expect the other.

A VERSION file sits next to release tags that skipped a number

Two version sources exist. A plain `VERSION` file sits at the repository root, and releases are published as tags. Nothing visible in the README says which one is authoritative or that they are kept in step.

The tag sequence also has a gap in it. On 2026-10-01 the three most recent releases are v0.9.54 at 10:22:54, v0.9.55 at 13:10:43, and v0.9.57 at 16:54:48, so the counter moves by two between the second and third release of a single afternoon and v0.9.56 is not among the recent releases.

Three releases in under seven hours, on a repository whose last push is the same 16:54:48 as the newest tag, is a fast cadence for something that also claims to track an upstream monorepo and to carry named policy forks. Practically, that means the tag is a commit marker more than a compatibility statement, and the fork declarations in `tools/forks.json` are what tell you whether behaviour moved.

If you pin, pin a tag and read the fork file at that tag. If you follow the default branch, which is what both install commands do, you are tracking whatever landed most recently, gaps included.

A TypeScript repository with no package manifest at its root

The primary language is TypeScript, and the top-level entries contain no package manifest. There is no package.json in the root listing, alongside `.claude-plugin/`, `.agents/`, `plugins/`, `tools/`, `docs/`, `tests/`, and `assets/`.

So the TypeScript is not a published library. It is machinery that ships inside a plugin, and the distribution channel is the git-hosted marketplace both install recipes reference. There is no `npm install` path, no dependency install step in either documented recipe, and no lockfile in the root listing.

The directory layout explains the dual plugin story. `.claude-plugin/` is the harness-specific manifest location for Claude Code, while `.agents/` is the parallel home for the shared skills that the deferred installation path covers. `plugins/pstack/skills/poteto-mode/SKILL.md` is where the playbooks live, which is the file the getting started example and the playbook list both point at. `tools/` holds the fork declarations. `docs/reference.md` is the single document that the model configuration, runtime support, maintenance scope, and shared installation sections all defer to.

The practical read: the repository is mostly prose, manifests, and skill definitions, with tests and tooling underneath. Two root files support that reading, a `.markdownlint-cli2.jsonc` config and a `.pre-commit-config.yaml`, which are checks aimed at text rather than at a build. Judge it as a configuration project, and read `docs/reference.md` before assuming the README is complete.

No server and no telemetry, but every transcript still goes to the model provider

The data handling note is short and specific. There is no server and no telemetry. Anything the skills ask your agent to read, session transcripts included, goes to your model provider. Scripts run locally, and the pull request tools use your GitHub CLI login.

Three consequences follow directly. First, the privacy boundary is your model provider, not this plugin, so the relevant question is which provider the configured models resolve to and what its retention terms are. Second, the credential in play for anything touching pull requests is your existing GitHub CLI login, which means the plugin inherits whatever scopes that login already has rather than asking for a narrower one. Third, the no-server claim does not mean no egress: transcripts leaving for the provider is egress, and the note is careful enough to say so.

Two root documents cover the rest of the process. `CONTRIBUTING.md` holds the checks and the routing question of where a change belongs, and `SECURITY.md` is the private channel for vulnerability reports rather than a public issue. With two open issues on the repository, the distinction between those two paths is the one to keep straight.

Editorial conclusion

Use pstack-claude if you want the pstack playbooks in Claude Code or Codex and you are willing to read forks.json before assuming behaviour matches upstream, because the port declares its own policy divergences rather than mirroring. Do not treat it as a drop-in for the other three harnesses on the strength of the repository description alone: two install paths are written out and three are delegated to a reference document. Before installing, confirm which of the four root licence files covers the skills you intend to use, check that a VERSION file and a git tag agree, and read the data handling note if your transcripts matter.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. michael-denyer/pstack-claude on GitHub
4. README
5. Releases