Repository navigation
pstack: Claude Code and Codex mapping for Cursor-specific instructions #601
Description
I run pstack in Claude Code and Codex rather than Cursor. #537 adds Codex packaging but deliberately leaves Cursor-specific tools and agent orchestration alone. I adapted those, and the result is public in case any of it is useful upstream:
https://github.com/MaxFabian25/pstack-harness-adaptations (branch upstream is pstack 0.15.19 as released; main is the adapted tree, so git diff upstream main shows every change).
What it does:
- Adds one map,
skills/poteto-mode/references/harnesses.md, with the Claude Code and Codex equivalent of each Cursor concept: theTaskparameters (readonly,environment: "cloud", model slugs),pstack-models.mdc,agent-transcripts/,AskQuestion,/loop, custom modes,cursor-team-kitskills, routines and webhooks. Skills point to the map instead of repeating harness details. - Keeps the multi-model panels (interrogate, arena, architect) cross-family by running the second seat through the other harness's CLI (
codex execfrom Claude Code,claude -pfrom Codex). - Replaces the
.mdcrule with a shared~/.config/pstack/models.mdthat has one section per harness, written by/setup-pstack. - Ships Codex custom agents for
poteto-agent,comment-sickoand a read-only reviewer.
Verified: /interrogate ran end to end in both harnesses with a native reviewer plus a cross-family seat. make-bot-ui was exercised against a Claude Code routine API trigger and a local codex exec server. Nothing in the adaptation is removed, and it touches about 70 files.
No PR here because it changes a lot of Cursor-facing prose, and the right shape for upstream (a separate map, conditional sections, or a per-harness build step) is your call. Happy to open a PR in whatever shape you prefer, or to keep it as an external adaptation.
Activity
deanrie commentedon Oct 14, 2026
Hey @MaxFabian25, thanks for publishing the adaptation with the
upstreambranch kept as a clean baseline, that makes the diff easy to read. The shape question you raise (a separate harness map, conditional sections, or a per-harness build step on top of what #537 did for Codex packaging) is the pstack maintainer's call, so I'll leave the decision there rather than suggest one; the issue is on their list as a proposal. If any single piece is self-contained enough to stand alone, for example theharnesses.mdmap on its own without the prose changes, that would be the easiest thing to review first.