Skip to content

feat(omp): add native oh-my-pi harness support#1996

Open
lucasmedeirosleite wants to merge 1 commit into
obra:devfrom
lucasmedeirosleite:feat/add-omp-support
Open

feat(omp): add native oh-my-pi harness support#1996
lucasmedeirosleite wants to merge 1 commit into
obra:devfrom
lucasmedeirosleite:feat/add-omp-support

Conversation

@lucasmedeirosleite

Copy link
Copy Markdown

Who is submitting this PR? (required)

Field Value
Your model + version gpt-5.6-sol
Harness + version Pi 0.80.7 on Linux
All plugins installed See plugin list below
Human partner who reviewed this diff Lucas Medeiros (@lucasmedeirosleite)

Installed plugins:

  • pi-configuration@0.1.0
  • @aretw0/git-skills@0.7.0
  • pi-extension-manager@0.8.2
  • @aliou/pi-guardrails@0.15.0
  • pi-mcp-adapter@2.11.0
  • pi-mermaid@0.3.0
  • @haispeed/pi-obsidian@0.1.1
  • pi-playwright@0.1.1
  • @ifi/pi-pretty@0.5.1
  • pi-subagents@0.34.0
  • pi-hermes-memory@0.8.1
  • pi-web-access@0.13.0
  • @zenobius/pi-worktrees@0.5.1

What problem are you trying to solve?

Oh-my-pi users currently do not get a first-class Superpowers integration. The plugin can ship skills, but a clean omp session does not get the using-superpowers bootstrap injected at session
start, so the skills are present without the behavior that makes them auto-trigger.

This addresses #1941.

What does this PR change?

Adds a native oh-my-pi adapter through package.json#omp.extensions, backed by a shared harness-neutral bootstrap controller used by both pi and omp. Pi keeps its existing live
resources_discover behavior; OMP uses its native package-root skills/ discovery and registers only the lifecycle hooks omp actually emits.

Also adds omp install/verification docs, harness-porting guidance, and contract tests for the shared controller, pi adapter, omp adapter, and omp docs.

Is this change appropriate for the core library?

Yes. This is new harness support for a general-purpose agent runner, which is the same kind of core integration this repo already ships for other harnesses. It does not add a domain-specific
skill, project-specific configuration, or a third-party runtime dependency.

The shared controller is deliberately narrow: it owns only harness-neutral bootstrap policy — arm/disarm, message placement, deduplication, frontmatter stripping, caching, and fail-soft
diagnostics. The Pi and OMP adapters still own their own manifests, lifecycle hooks, discovery boundaries, logging, and tool mappings.

What alternatives did you consider?

  • Reuse the Pi adapter in omp. and rejected. It would blur the harness boundary and keep omp on pi-shaped assumptions. The final adapter uses omp's native manifest, omp lifecycle APIs,
    skill:// skill reads, lowercase task, and lowercase todo.
  • Put all logic in the omp adapter. and rejected. Pi and omp need the same bootstrap semantics, and duplicating placement/dedup/fail-soft behavior would make the two integrations drift.
  • Use omp's typed resources_discover event. and rejected after checking omp 16.5.2 source. The type exists, but there are no runtime emit callsites. omp's actual native skill discovery for
    extension packages scans the plugin root's conventional skills/ directory, so the omp adapter does not register a dormant hook.
  • Document marketplace install as the native path. and rejected. omp marketplace installation does not load omp.extensions; the docs use omp's Git installer and local omp plugin link path
    instead.

Does this PR contain multiple unrelated changes?

No. The changes are all part of one harness-support slice: shared bootstrap policy, the native omp adapter, the pi refactor needed to share that policy safely, docs, and tests.

Existing PRs

Searches used: omp, oh-my-pi, oh my pi, native omp, and 1941 across open and closed PRs.

Environment tested

Harness (e.g. Claude Code, Cursor) Harness version Model Model version/ID
omp 16.5.2 GPT 5.6 gpt-5.6-sol
Pi 0.80.7 GPT 5.6 gpt-5.6-sol

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

Clean-session transcript for "Let's make a react todo list"
Session:
- OMP version: omp/16.5.2
- Model: openai-codex/gpt-5.5
- CWD: /tmp/superpowers-omp-acceptance.hmii0M
- Install command: omp plugin link /home/lucasmedeiros/Development/projects/superpowers
- Prompt: Let's make a react todo list

User:
Let's make a react todo list

Assistant tool calls:
1. read skill://brainstorming/SKILL.md
2. read skill://test-driven-development/SKILL.md
3. read skill://typescript/SKILL.md
4. read skill://interface-design/SKILL.md

Tool results:
- brainstorming SKILL.md loaded.
- test-driven-development SKILL.md loaded.
- typescript SKILL.md loaded.
- interface-design SKILL.md loaded.

Assistant tool call:
todo init
- phase: Brainstorming
- items:
  - Explore project context
  - Offer visual companion if helpful
  - Ask clarifying questions
  - Propose implementation approaches
  - Present design for approval
  - Write approved design document
  - Self-review design spec
  - Get user spec review
  - Transition to implementation plan

Tool result:
Remaining items (9):
  - Explore project context [in_progress] (Brainstorming)
  - Offer visual companion if helpful [pending] (Brainstorming)
  - Ask clarifying questions [pending] (Brainstorming)
  - Propose implementation approaches [pending] (Brainstorming)
  - Present design for approval [pending] (Brainstorming)
  - Write approved design document [pending] (Brainstorming)
  - Self-review design spec [pending] (Brainstorming)
  - Get user spec review [pending] (Brainstorming)
  - Transition to implementation plan [pending] (Brainstorming)

Assistant tool calls:
1. read .
2. glob package.json;src;app;components;pages;vite.config.*;next.config.*;tsconfig.json;README*;.interface-design/system.md
3. bash "git log --oneline -5"

Tool results:
- read .: empty directory
- glob: no project files found
- git log: fatal: not a git repository

Assistant tool call:
todo done "Explore project context"

Tool result:
Remaining items (8):
  - Offer visual companion if helpful [in_progress] (Brainstorming)
  - Ask clarifying questions [pending] (Brainstorming)
  - Propose implementation approaches [pending] (Brainstorming)
  - Present design for approval [pending] (Brainstorming)
  - Write approved design document [pending] (Brainstorming)
  - Self-review design spec [pending] (Brainstorming)
  - Get user spec review [pending] (Brainstorming)
  - Transition to implementation plan [pending] (Brainstorming)

Assistant tool call:
todo done "Offer visual companion if helpful"

Tool result:
Remaining items (7):
  - Ask clarifying questions [in_progress] (Brainstorming)
  - Propose implementation approaches [pending] (Brainstorming)
  - Present design for approval [pending] (Brainstorming)
  - Write approved design document [pending] (Brainstorming)
  - Self-review design spec [pending] (Brainstorming)
  - Get user spec review [pending] (Brainstorming)
  - Transition to implementation plan [pending] (Brainstorming)

Assistant:
Using brainstorming to shape the React todo list before implementation.

Project context: `/tmp/superpowers-omp-acceptance.hmii0M` is empty, not a git repo, and has no React/Vite/Next files yet.

One question: should I create a new standalone React app here, or do you have an existing project path you want me to add the todo list to?

Session exit:
normal

Acceptance checks:
- first tool call read `skill://brainstorming/SKILL.md`
- native lowercase `todo` used
- no `write` calls
- no `edit` calls
- stderr empty
- final response asked a brainstorming question instead of writing code

Evaluation

  • Initial prompt for the implementation work: add first-class native OMP support for Feature request: First-class oh-my-pi (OMP) support via native extension #1941 while preserving Pi support, using OMP's native manifest/APIs/tools instead of a Pi compatibility
    fallback.
  • Eval sessions after the change: one clean OMP acceptance session with the exact prompt required by the PR template, plus contract test suites for the shared bootstrap core, Pi adapter, OMP
    adapter, and OMP docs.
  • Before/after:
    • Before: Superpowers had no native OMP adapter, so a clean OMP plugin session did not have a real native bootstrap path that made brainstorming auto-trigger before code.
    • After: the clean OMP 16.5.2 session loaded skill://brainstorming/SKILL.md as its first tool call, used native lowercase todo, made zero write/edit calls, and stopped in brainstorming with
      a clarifying question.

Verification run:

  node --experimental-strip-types --test tests/integrations/test-bootstrap-core.mjs tests/pi/test-pi-extension.mjs tests/omp/test-omp-extension.mjs
  node --test tests/omp/test-omp-docs.mjs
  git diff --check
  npm pack --dry-run --json

Results:

  • shared/Pi/OMP contract tests: 20/20 passing
  • OMP docs tests: 4/4 passing
  • npm dry-run package: 177 files, includes the native OMP adapter, shared bootstrap controller, and bundled skills; excludes generated acceptance evidence
  • branch is current with upstream/dev and contains one commit

Rigor

  • If this is a skills change: N/A — this does not modify skill behavior-shaping content
  • 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

Adversarial checks included:

  • OMP adapter dependency direction: no import from Pi adapter
  • Pi adapter dependency direction: no import from OMP adapter
  • OMP registers only live runtime hooks: session_start, session_compact, context, agent_end
  • OMP does not register the dormant typed resources_discover event
  • OMP native package-root skills/ discovery is asserted by tests and verified in the real acceptance session
  • bootstrap injection deduplicates existing string and multipart markers
  • bootstrap injection happens after all leading compaction summaries
  • missing bootstrap file fails soft and reports one structured warning
  • diagnostic callback failures do not break session injection
  • Pi's existing live resources_discover behavior is preserved

Human review

  • A human has reviewed the COMPLETE proposed diff before submission

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant