feat(omp): add native Oh My Pi (OMP) extension - #2390

This PR targets the dev branch.

Who is submitting this PR? (required)

What problem are you trying to solve?

Superpowers has no OMP entry point, so OMP loads the Pi extension (pkg.omp ?? pkg.pi). On OMP that extension only delivers the bootstrap in the first run of a process: it clears its flag at agent_end and nothing re-arms it until the next session_start or session_compact.

I reproduced this on OMP 18.3.2 with upstream dev (c5cc551) installed in a clean HOME. Over RPC, one process received "Let's make a react todo list" followed by a second prompt asking whether its context contained the <EXTREMELY_IMPORTANT> / "You have superpowers." message:

• Turn 1 loaded skill://brainstorming correctly.
• Turn 2 answered NONE in 3/3 runs: from the second prompt on, the bootstrap is gone.
• Removing it also moves every later message, so the Anthropic prompt cache falls back to the system prefix. Turn 2 read 6,522 cached tokens and wrote 11,594; with this branch, turn 2 read 19,106 and wrote 347.

What does this PR change?

Adds a native OMP extension (.omp/extensions/superpowers.ts) declared through package.json#omp, with tests in tests/omp/ and OMP install notes in the README and porting guide. It adds the using-superpowers bootstrap plus an OMP tool mapping (skill://, task, todo) to every model request, after compaction and branch summaries, without persisting it in the session. .pi/ is unchanged.

Is this change appropriate for the core library?

Yes. It is harness support for every Superpowers user on OMP, with no new dependencies and no skill changes. OMP already discovers the package-root skills/ directory natively; only the bootstrap needed an OMP entry.

What alternatives did you consider?

• Keep using the Pi extension on OMP. It loses the bootstrap after the first run, as shown above. Fixing that in the shared Pi extension (as fix(pi): persist bootstrap for prompt caching #2308 does) would still leave OMP on Pi-shaped assumptions.
• Persist the bootstrap as a hidden session message (fix(pi): persist bootstrap for prompt caching #2308's approach for Pi). On OMP this is not needed for caching: OMP's context hook runs on every provider request, so adding the same bytes at the same position keeps the cached prefix stable. I verified with a before_provider_request dump that the request prefix is byte-identical across runs and across a resumed process. Not persisting avoids storing a stale copy in session files and needs no dedup against compaction.
• A shared, harness-neutral bootstrap core (feat(omp): add native oh-my-pi harness support #1996). It rewrites the Pi extension, and its OMP adapter keeps the Pi lifecycle (injected at session_start/session_compact, cleared at agent_end), which is the behavior reproduced above. This PR keeps each harness self-contained, like the other entries in the porting guide's harness table.
• Moving the bootstrap into the system prompt. Rejected for the same reasons the repository already gives (Superpowers consume a lot of tokens in Opencode with Codex #750, Opencode: multiple system messages in request break compatibility with qwen3.5 models #894).

Does this PR contain multiple unrelated changes?

No. The extension, its manifest entry, tests and install docs are one harness-support change.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: feat(omp): add native oh-my-pi harness support #1996 (open, native OMP support), fix(pi): persist bootstrap for prompt caching #2308 (open, Pi bootstrap persistence), docs: add docs/README.pi.md and README Pi detailed-docs link #1740 (closed, Pi docs only), feat(hermes): Hermes Agent harness support — eval-verified pre_llm_call bootstrap #2025 (merged, Hermes harness).

This overlaps #1996's goal. The difference is the lifecycle: #1996 delivers the bootstrap until agent_end, which is the defect reproduced above, and it refactors the Pi extension. This PR does not touch .pi/, so it neither conflicts with #2308 nor depends on it. Searches: omp, oh-my-pi, oh my pi across open and closed PRs.

Environment tested

New harness support (required if this PR adds a new harness)

Clean HOME (no user config, rules, or other plugins), omp plugin install github:andrebrait/superpowers#6194c2e60c71c3f456217eaad8f1f42d453de261, then omp --model anthropic/claude-sonnet-5 -p "Let's make a react todo list" in an empty directory. Brainstorming loaded before anything else; no files were written. The session file contains no copy of the bootstrap.

[user] Let's make a react todo list

[assistant] Using brainstorming to shape the React todo list before writing code.

[assistant → read] {"path": "skill://brainstorming", "i": "Loading brainstorming skill instructions"}

[toolResult] ---
name: brainstorming
description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
---

# Brainstorming Ideas Into Designs

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by classifying how muc
… [17057 more characters of tool output]

[assistant] Classification: this is a new project (no existing todo-list flow in this repo to extend) → **architectural** path, per brainstorming's own red-flag guidance ("a new project has no existing flow — it is architectural"). I'll follow: explore context → clarifying questions → approaches → design → spec → writing-plans.

[assistant → bash] {"command": "ls -la /tmp/sp-final/work 2>&1 | head -50 && echo --- && find /tmp/sp-final/work -maxdepth 2 -type f 2>&1 | head -50", "i": "Checking current project state"}

[toolResult] total 8
drwxr-xr-x 2 root root 4096 Sep 26 14:57 .
drwxr-xr-x 5 root root 4096 Sep 26 14:57 ..
---


Wall time: 0.17 seconds

[assistant] Empty directory — confirmed new project, no existing flow to extend.

One question to start: what's this todo list for — a learning/demo exercise, a personal tool you'll actually use daily, or a starting point for something bigger (e.g., will it need accounts/backend later)?

Evaluation

• Initial prompt: "Native OMP integration from the ground up", after comparing feat(omp): add native oh-my-pi harness support #1996 and fix(pi): persist bootstrap for prompt caching #2308 against the local OMP adapter we had been running.
• Eval sessions after the change: 3 acceptance sessions (all loaded skill://brainstorming first and wrote nothing), 3 two-turn RPC runs, and 3 resumed sessions checked for prompt-cache reuse.
• Before/after: with upstream dev, turn 2 had no bootstrap in 3/3 runs and fell back to a 6,522-token cache read. With this branch, turn 2 had the bootstrap in 3/3 runs and read 19,106 cached tokens. Two of three resumed sessions read the full cached prefix, with request payloads confirmed byte-identical apart from cache_control placement. The first resume read only the 6,522-token system prefix; I could not reproduce that.

Rigor

• If this is a skills change: I used superpowers:writing-skills and completed adversarial pressure testing (paste results below) — not a skills change
• This change was tested adversarially, not just on the happy path
• I did not modify carefully-tuned content (Red Flags table, rationalizations, "human partner" language) without extensive evals showing the change is an improvement

node --test tests/omp/test-omp-extension.mjs tests/pi/test-pi-extension.mjs: 15/15. The OMP tests cover later runs without a new before_agent_start, compaction and branch summaries, skill updates between runs, missing and empty SKILL.md (one visible warning per failure and per session), quoted bootstrap text, and session changes during an in-flight load. Each of these behaviors was mutated in turn and made at least one test fail. tsc --strict passes against the OMP 18.3.2 extension types. A separate adversarial review pass found no remaining code or test issues.

Human review

• A human has reviewed the COMPLETE proposed diff before submission