Panoply

Install once, for every project on the machine:

npx panoply init --global

Or run it inside a single project to scope it there:

npx panoply init

Either way it detects whether you're on Claude Code, opencode, or Cursor, installs the commands there, and stops. It never overwrites a command you wrote yourself.

--global writes to the user-level directory each agent already merges with your project's — ~/.claude/commands/, ~/.config/opencode/commands/, ~/.cursor/commands/ — so the commands are simply there, in every repo, with no per-project step. MCP servers are merged into the matching global config, skipping any server you'd already set up; the previous file is kept alongside as .panoply-bak.

In Claude Code you can install it as a plugin instead, which keeps it updatable:

/plugin marketplace add fordaaaa/panoply
/plugin install panoply@panoply

Using something else? Open prompts/, copy a file, replace {{ARGUMENTS}}, paste it in.

Nothing is configured on install. Every command starts in local mode — reports on screen, files nothing, touches git never — and asks about anything more only when you first ask for it.

> /cr-run standard

  Reviewing 84 files with 3 subagents (correctness · performance · security).
  Estimated ~180k input tokens. Continue? y

  🔴  src/auth/session.ts:142   Session token compared with ==, not timing-safe
                                → use crypto.timingSafeEqual
  🟠  src/api/upload.ts:67      Unbounded read into memory; 2GB upload OOMs the worker
                                → stream to disk, cap at configured limit
  🟡  src/db/pool.ts:23         Pool never drained on SIGTERM; deploys drop in-flight queries

  Verified 3 of 5 reported — dropped 2 I couldn't confirm at the cited line.
  Local mode: nothing filed. Want me to fix any of these, or start filing?

The repo is the memory; context is disposable. Every command either writes a durable artifact or reads one a sibling wrote. Nothing of value dies when the context window compacts, the session ends, or you switch tools.

They compose through files, not calls — /map feeds /spec, /spec feeds /verify, /cr-run feeds /cr-fix — and each one still works standalone if the file it likes isn't there.

This is a collection, not a fixed product — it's meant to grow into everything you actually use. Drop a markdown file in commands/, add a server to mcp/servers.json, run node build.mjs, and it exists in every agent you work in. No runtime, no plugin API, no rewriting the same prompt in four dialects.

The bar for anything you add is in CONTRIBUTING.md: it has to beat a plain prompt through structure — parallel subagents, a durable artifact, a verification loop, or a cheaper model. Everything else is just a paragraph you could have typed.

Worth knowing before you install something that can open pull requests.

• It won't merge without earning it. autoclose defaults to off. Turning it on still requires five conditions to hold at once: a real test suite that covers the change and passes, issues authored by a maintainer, no foreign commits on the branch, and a genuinely mergeable PR. It never passes --admin — branch protection exists because someone wanted a human there.
• It won't treat your repo as instructions. Issue bodies, comments, and source text are data. A review that reads an issue and a fix that merges to your default branch is a prompt-injection path straight to production; every command carries an explicit rule against following text it finds. Issue-driven fixes never touch CI config, workflows, lockfiles, or credentials.
• It won't publish your vulnerabilities. Security findings are never auto-filed — a 🔴 filed as a public issue is a zero-day with no fix shipped. You get it on screen, and an offer to open a private advisory.
• It won't spend without asking. /cr-run deep is 5–8 subagents reading real source. It prints the file count and cost estimate and waits.
• It won't assume. Not that you have tests, not that your default branch is main, not that your working tree is clean, not that gh is pointed at the repo you think it is.

Subagents self-score confidence 1–10 and report only 8+. Then the main thread opens every cited file:line and drops anything it can't confirm itself. A false positive in your tracker costs more than a missed bug.

Two questions, asked the first time you want something filed, saved to .panoply/config.md:

filing: local         # local | high-only | all
autoclose: off        # off | on

filing: local is a real escape hatch, not a demo mode: nothing is filed, committed, or pushed, and fixes land uncommitted in your working tree for you to keep or throw away. Say "reconfigure" to change any of it, or just edit the file.

One server ships on by default — GitHub, pinned to the issues,pull_requests,repos toolsets. The unpinned server exposes ~90 tools and costs 15–25k tokens of context in every session before you've run anything; pinned, it's 5–7k. gh is the supported fallback and covers everything these commands need, so nothing breaks if you skip MCP entirely.

That server's OAuth doesn't support dynamic client registration, so the in-agent OAuth flow fails. Authenticate with a token in the Authorization header instead — the generated configs read it from GITHUB_MCP_TOKEN:

# ~/.bashrc, or wherever your shell exports live
command -v gh >/dev/null 2>&1 && export GITHUB_MCP_TOKEN="$(gh auth token)"

Two ways this bites you, both surfacing as the same unhelpful HTTP 400 on connect or reconnect:

• The variable isn't set in the launching process. ${GITHUB_MCP_TOKEN} is expanded by the agent at load time; unset, it goes out to GitHub as that literal string and comes back error="invalid_token". A shell you opened before adding the export won't have it, and neither will a GUI or IDE launch that never sources your shell config. Check with echo ${#GITHUB_MCP_TOKEN} — you want 40, not 0 — and start the agent from a shell that passes.
• The token went stale. gh auth token is snapshotted once at shell startup, and gho_ tokens rotate. A long session can connect fine and then fail to reconnect hours later; restart from a fresh shell to re-snapshot. If you'd rather not think about it, use a long-lived fine-grained PAT with repo scope instead of the gh token.

Three more are available opt-in, because a server you don't use is a permanent tax on your context window:

npx panoply init --with context7,playwright,sentry

All of it comes from one file — mcp/servers.json — rendered into .mcp.json, .cursor/mcp.json, and opencode.json by the build. Hand-maintaining those three is what let one of them go missing.

Edit commands/ and mcp/servers.json only; everything else is generated by node build.mjs. See CONTRIBUTING.md for the house style and the bar a new command has to clear.

commands/                  ← the only files you edit
├── _bootstrap.md          ← shared partials, pulled in via {{INCLUDE:_name.md}}
├── _preflight.md
├── _severity.md
├── _untrusted.md
└── cr-run.md, cr-fix.md, map.md, spec.md, verify.md, debug.md, prompt.md
      │
      │   node build.mjs
      ▼
.claude/commands/  .opencode/commands/  .cursor/commands/  prompts/
.mcp.json          opencode.json        .cursor/mcp.json

The parallel-subagent review structure and the severity/confidence scoring grew out of Anthropic's MIT-licensed claude-code-security-review.