Proposal: add native oh-my-pi (omp) support #1224

Would you be open to supporting oh-my-pi (omp) as a native Compound Engineering harness?

I've been using OMP and wanted to work out what support would actually involve before proposing a PR. My first assumption was that, since OMP is a Pi fork and this repo already has a Pi converter, it might be little more than an alias. After comparing both installed tools and reading OMP's v17.0.5 source, I don't think that is the right model.

The good news is that CE already gets surprisingly far. This checkout is recognized by:

$ omp --version
omp/17.0.5

$ omp install --dry-run --json "$PWD"

That dry run found the existing package.json#pi manifest, the CE extension, and the skills. OMP deliberately falls back to Pi package metadata and also understands Claude marketplace metadata, so I don't think this needs a new converter, writer, manifest, catalog, or copied skills tree.

The part that does need explicit support is the runtime. OMP uses ~/.omp/agent and project .omp/ roots, has built-in ask and task tools, invokes skills as /skill:<name>, handles MCP natively, and stores sessions under its own profile-aware roots. Treating it as an alias for the current pi target would write to the wrong places and teach several skills the wrong tool and invocation syntax.

That gap is in CE's own harness-specific instructions, not OMP's package loader. For example, several current skills explicitly send Pi-like hosts to ask_user, and some user-facing handoffs use a slash-command form that OMP does not understand. OMP cannot safely translate prose like that on CE's behalf.

Why I think OMP is worth supporting

OMP is a particularly good match for what Compound Engineering is trying to do. CE is most useful when the host can do more than run a single chat loop, and OMP has the relevant pieces built in:

• task can fan work out to specialist agents, isolate them in worktrees, and return schema-checked results;
• ask gives workflows a structured way to stop for a real decision;
• model roles, an advisor model, review, checkpoints, todos, and optional memory support the plan/review/learn loop directly;
• LSP, DAP, browser, MCP, structural editing, and GitHub/PR tooling give those workflows somewhere useful to run;
• it supports many model providers rather than tying CE support to one model vendor.

Those aren't just a long feature list. They overlap with the parts of CE that are hardest to make portable: parallel research and review, explicit decision points, cross-model work, and durable learning after the work is done. OMP can run those ideas natively rather than through a pile of compatibility shims.

It also seems large enough that support would serve a real audience, not just my setup. In a GitHub API snapshot on July 21, 2026, OMP's public repo had 18,982 stars, compared with 10,509 for Kimi CLI, which CE already supports. I know stars are not installs or active users, but they are a useful public-interest signal, and the comparison suggests OMP is already in the range of agents this project chooses to support.

The project docs that informed this are the README, skills documentation, task-agent discovery, and marketplace compatibility.

What I would put in the PR

A first PR could stay fairly bounded:

• document the existing native install path and add a short OMP target spec;
• detect OMP and have --to all explain that it uses the native plugin install instead of attempting conversion;
• fix the places where CE gives harness-specific instructions so OMP gets built-in ask, built-in task, and /skill:<name> user-facing invocations;
• recognize OMP's session roots for session-history workflows while keeping the platform identity as omp;
• add focused tests for those contracts, plus an isolated install/update/uninstall smoke test and a few representative skill evals.

I would not add a --to omp converter, reuse the Pi writer, introduce .omp-plugin metadata, or create a separate release component.

The installation change itself is small. The compatibility pass is not just a metadata tweak: most of it is localized prose, but session attribution and cross-model host handling need some judgment and regression coverage. I have already audited the affected files, but I wanted to ask before sending a fairly broad-looking diff for a harness the maintainers may not have evaluated yet.

I also realize that adding a harness to the supported list creates follow-up work when its contracts change. This research is pinned to OMP 17.0.5, so I would rerun it against the current release before opening the PR. If this direction sounds useful, I'm happy to prepare the PR, include the empirical results, and help with OMP-specific compatibility follow-up rather than treating this as a drive-by addition. Before calling it supported, I would verify an isolated remote install, installation and discovery of the complete current skill inventory, representative ask and task workflows, session discovery, update/uninstall, bun test, and the release validators.

Two questions:

1. Is native OMP support something you would be willing to maintain upstream?
2. If so, does the boundary above look right, or would you prefer to start with a docs-only compatibility note?