feat(omp): add native marketplace and skill support

.github/release-please-config.json

@@ -47,7 +47,8 @@
         ".kimi-plugin/marketplace.json",
         ".claude-plugin/marketplace.json",
         ".cursor-plugin/marketplace.json",
-        ".grok-plugin/marketplace.json"
+        ".grok-plugin/marketplace.json",
+        ".omp-plugin/marketplace.json"
       ],
       "extra-files": [
         {
@@ -85,6 +86,11 @@
           "path": ".devin-plugin/plugin.json",
           "jsonpath": "$.version"
         },
+        {
+          "type": "json",
+          "path": ".omp-plugin/marketplace.json",
+          "jsonpath": "$.plugins[0].version"
+        },
         {
           "type": "json",
           "path": "plugin.json",

.omp-plugin/marketplace.json

@@ -0,0 +1,29 @@
+{
+  "name": "compound-engineering-plugin",
+  "owner": {
+    "name": "Kieran Klaassen and Trevin Chow"
+  },
+  "metadata": {
+    "description": "Plugin marketplace for Claude Code and Codex extensions"
+  },
+  "plugins": [
+    {
+      "name": "compound-engineering",
+      "description": "Brainstorm, plan, debug, review, and compound learnings with AI agents",
+      "version": "3.21.4",
+      "author": {
+        "name": "Kieran Klaassen and Trevin Chow"
+      },
+      "homepage": "https://github.com/EveryInc/compound-engineering-plugin",
+      "tags": [
+        "ai-powered",
+        "compound-engineering",
+        "workflow-automation",
+        "code-review",
+        "quality",
+        "knowledge-management"
+      ],
+      "source": "./"
+    }
+  ]
+}

AGENTS.md

@@ -124,7 +124,7 @@ That field guide is the canonical reasoning layer for outcome-first authoring, m
 
 ### User-Facing Skill Invocations
 
-Keep agent-to-agent or skill-to-skill routing semantic: format formal skill names as inline code (for example, `ce-plan`) and invoke the named skill through the active harness's callable skill mechanism. When a skill prints or copies a user-runnable invocation, default to `/skill-name`; use `$skill-name` only when the active harness is Codex or explicitly documents dollar-prefixed skill invocation. In prose, render only the invocation as inline code; use a fenced block only when the command stands alone. Output exactly one form. Do not apply this rendering rule to built-in commands such as `/goal`.
+Keep agent-to-agent or skill-to-skill routing semantic: format formal skill names as inline code (for example, `ce-plan`) and invoke the named skill through the active harness's callable skill mechanism. When a skill prints or copies a user-runnable invocation, default to `/skill-name`; use `$skill-name` only when the active harness is Codex or explicitly documents dollar-prefixed skill invocation; use `/skill:<name>` (for example `/skill:ce-plan`) when the active host is oh-my-pi (`omp`). In prose, render only the invocation as inline code; use a fenced block only when the command stands alone. Output exactly one form. Do not apply this rendering rule to built-in commands such as `/goal`.
 
 At runtime, put the smallest self-contained rendering rule immediately before the smallest section that contains all affected user-copy seams. Do not repeat it in every step; repeat it only in a separately loaded reference that independently owns output.
 

README.md

@@ -95,15 +95,15 @@ Remove the obsolete Compound Engineering Codex tool-map block from my Codex home
 
 Re-running the Bun convert/install CLI for Codex also strips the block if it is still present; it no longer inserts it.
 
-**Another editor or CLI?** Kimi Code CLI, Cline, Grok Build CLI, Devin CLI, GitHub Copilot, Factory Droid, Qwen Code, OpenCode, Pi, and Antigravity CLI are all supported — see [More install options](#more-install-options).
+**Another editor or CLI?** Kimi Code CLI, Cline, Grok Build CLI, Devin CLI, GitHub Copilot, Factory Droid, Qwen Code, OpenCode, Pi, oh-my-pi (omp), and Antigravity CLI are all supported — see [More install options](#more-install-options).
 
 ---
 
 ## Philosophy
 
 **Each unit of engineering work should make subsequent units easier -- not harder.**
 
-Invocation syntax: this README uses `/skill-name` examples for slash-skill hosts. In Codex, invoke installed skills with `$skill-name` (for example, `$ce-plan` and `$lfg`); `/goal` remains a Codex built-in command.
+Invocation syntax: this README uses `/skill-name` examples for slash-skill hosts. In Codex, invoke installed skills with `$skill-name` (for example, `$ce-plan` and `$lfg`); in oh-my-pi (omp), invoke installed skills as `/skill:<name>` (for example, `/skill:ce-plan`); `/goal` remains a Codex built-in command.
 
 Traditional development accumulates technical debt. Every feature adds complexity. Every bug fix leaves behind a little more local knowledge that someone has to rediscover later. The codebase gets larger, the context gets harder to hold, and the next change becomes slower.
 
@@ -400,6 +400,38 @@ Recommended companion for richer blocking questions:
 pi install npm:pi-ask-user
 ```
 
+### oh-my-pi (omp)
+
+oh-my-pi (omp) installs Compound Engineering through its marketplace flow. The repo ships a native `.omp-plugin/marketplace.json` catalog whose plugin entry carries a release-managed `version`, so omp's update checker can see each new CE release:
+
+```text
+omp plugin marketplace add EveryInc/compound-engineering-plugin
+omp plugin install compound-engineering@compound-engineering-plugin
+```
+
+To stay current automatically, enable auto-update:
+
+```bash
+omp config set marketplace.autoUpdate auto
+```
+
+The default `notify` mode only writes update availability to the debug log — it does not prompt — so without `auto` you will not hear about new releases. To upgrade by hand instead, run `omp plugin upgrade compound-engineering@compound-engineering-plugin`.
+
+<details>
+<summary>Other install paths (pin-style and contributor development)</summary>
+
+`omp install https://github.com/EveryInc/compound-engineering-plugin` installs the repository as an npm-style plugin. That path has **no update mechanism** — treat it as pinning a snapshot, not as the recommended install.
+
+For local development from a checkout, use a live symlink instead:
+
+```bash
+omp plugin link "$PWD"
+```
+
+</details>
+
+Run `/reload-plugins` or start a new omp session after installing so the skills load. omp invokes installed skills as `/skill:<name>` (for example `/skill:ce-plan`), not `/skill-name`. See [`docs/specs/omp.md`](docs/specs/omp.md) for details.
+
 ### Antigravity CLI (`agy`)
 
 Google has replaced the consumer Gemini CLI with [Antigravity CLI](https://antigravity.google) (`agy`), which still runs on Gemini models. Install Compound Engineering directly from GitHub — no clone step required:
@@ -565,6 +597,12 @@ Restart OpenCode after changing `opencode.json`.
 pi -e "$PWD"
 ```
 
+**oh-my-pi (omp)**
+
+```bash
+omp plugin link "$PWD"
+```
+
 **Antigravity CLI (`agy`)**
 
 ```bash
@@ -582,7 +620,7 @@ See [`.agy/INSTALL.md`](.agy/INSTALL.md) for remote install and pinning examples
 
 ## Limitations
 
-OpenCode and Pi use native package/plugin loading from this repository. The Bun CLI remains for repository development and converter maintenance, not normal installation.
+OpenCode, Pi, and oh-my-pi (omp) use native package/plugin loading from this repository. The Bun CLI remains for repository development and converter maintenance, not normal installation.
 
 Release versions are owned by release automation. Routine feature PRs should not hand-bump plugin or marketplace manifest versions.
 

docs/solutions/skill-design/portable-agent-skill-authoring.md

@@ -158,7 +158,7 @@ Evaluate activation separately from execution with a few positive triggers, adja
 
 ### Render user invocations at the output boundary
 
-Keep agent-to-agent routing capability-first: format formal skill names as inline code (for example, `ce-plan`) and invoke the named skill through the active harness's callable skill mechanism. Exact command spelling belongs only where the skill prints or copies a user-runnable invocation. At that output seam, default to `/skill-name`; use `$skill-name` only when the active harness is Codex or explicitly documents dollar-prefixed skill invocation. In prose, render only the invocation as inline code; use a fenced block only when the command stands alone. Output exactly one form. Built-in commands such as `/goal` are separate capabilities, not evidence that slash-prefixed skill names are callable in Codex.
+Keep agent-to-agent routing capability-first: format formal skill names as inline code (for example, `ce-plan`) and invoke the named skill through the active harness's callable skill mechanism. Exact command spelling belongs only where the skill prints or copies a user-runnable invocation. At that output seam, default to `/skill-name`; use `$skill-name` only when the active harness is Codex or explicitly documents dollar-prefixed skill invocation; use `/skill:<name>` (for example `/skill:ce-plan`) when the active host is oh-my-pi (`omp`). In prose, render only the invocation as inline code; use a fenced block only when the command stands alone. Output exactly one form. Built-in commands such as `/goal` are separate capabilities, not evidence that slash-prefixed skill names are callable in Codex.
 
 An authoring guide cannot supply runtime behavior to an installed skill. Put the smallest self-contained rendering rule immediately before the smallest section that contains all affected user-copy seams. Do not repeat it in every step; repeat it only in a separately loaded reference that independently owns output. Use a focused contract test when independently edited skills must preserve the same handoff, without duplicating the rationale or a harness matrix.
 

docs/specs/omp.md

@@ -0,0 +1,110 @@
+# oh-my-pi (omp) Spec (Plugins and Skills)
+
+Last verified: 2026-08-05 against omp 17.2.9
+
+## Primary sources
+
+```
+https://github.com/can1357/oh-my-pi/blob/v17.2.9/README.md
+https://github.com/can1357/oh-my-pi/blob/v17.2.9/docs/skills.md
+https://github.com/can1357/oh-my-pi/blob/v17.2.9/docs/marketplace.md
+https://github.com/can1357/oh-my-pi/blob/v17.2.9/docs/session.md
+https://github.com/can1357/oh-my-pi/blob/v17.2.9/docs/config-usage.md
+https://github.com/can1357/oh-my-pi/blob/v17.2.9/docs/environment-variables.md
+https://github.com/can1357/oh-my-pi/blob/v17.2.9/docs/task-agent-discovery.md
+```
+
+## Plugin loading
+
+omp discovers plugins natively. Two committed metadata surfaces in this repository cover it:
+
+- The `package.json#pi` manifest — the same pi package metadata Pi already consumes. omp's shared plugin loader accepts `package.json.omp || package.json.pi`, so the existing `pi` field is the discovery gate that marks this repository as a plugin package.
+- The native omp marketplace catalog at `.omp-plugin/marketplace.json`, which omp reads first. `.claude-plugin/marketplace.json` remains as the Claude Code copy and as omp's fallback when `.omp-plugin/marketplace.json` is absent; the two coexist, and omp ignores the Claude copy when both are present (verified 2026-08-05: discovery output and the cached catalog both come from the `.omp-plugin` copy).
+
+Skill loading is structural, not extension-driven: omp's skill providers scan the plugin package's root `skills/` directory (`omp-plugins` provider for npm/link installs, `claude-plugins` provider for marketplace installs). The bundled extension `.pi/extensions/compound-engineering.ts` is a **no-op on omp** — it registers skill paths through the `resources_discover` hook, and omp implements `ExtensionRunner.emitResourcesDiscover(...)` with no `AgentSession` callsites. The extension still matters in one narrow way: install validates that every declared `extensions` entry resolves and imports to a factory function, and rolls the install back if it does not. So the `pi` block is a discovery gate and an install-time validation risk, but it is not what surfaces the skills.
+
+A dry run of `omp install` against this repository confirms the metadata surfaces resolve. No CE converter, writer, or `--to omp` CLI target exists or is planned: per CONCEPTS.md "Native plugin surface", omp support lives in platform metadata, docs, and release validation instead of a new Converter and Writer.
+
+## Updates
+
+omp's update checker (`checkForUpdates()`) compares the installed plugin version against the **catalog plugin-entry `version`** and permanently skips entries that lack one:
+
+```ts
+catalogVersion = catalog.plugins.find(p => p.name === parsed.name)?.version;
+if (!catalogVersion || catalogVersion === installed.version) continue;
+```
+
+`.omp-plugin/marketplace.json` therefore carries a release-managed `version` on the plugin entry, bumped by release-please through the root component's `extra-files` (`$.plugins[0].version`). This is what makes `omp plugin upgrade`, the 24h catalog refresh, and `marketplace.autoUpdate` (`off` / `notify` / `auto`) see CE releases at all. Note the default `notify` mode writes update availability only to the debug log — it shows no user-facing notification — so `omp config set marketplace.autoUpdate auto` is the setting that actually keeps an install current. Verified end to end on 17.2.9: with the catalog version bumped, `omp plugin upgrade` reinstalls into a new version-keyed cache directory and repoints the `node_modules` symlink; without it, the same change reports "up to date".
+
+Only the marketplace install path has an update story. `omp install <git-url>` (npm-style plugin install) has none — treat it as pinning a snapshot.
+
+## Install commands
+
+Marketplace flow — the recommended install (marketplace name `compound-engineering-plugin`, plugin name `compound-engineering`, both from `.omp-plugin/marketplace.json`):
+
+```text
+omp plugin marketplace add EveryInc/compound-engineering-plugin
+omp plugin install compound-engineering@compound-engineering-plugin
+```
+
+Stay current:
+
+```bash
+omp config set marketplace.autoUpdate auto   # or: omp plugin upgrade compound-engineering@compound-engineering-plugin
+```
+
+Pin-style direct install from a path or Git URL (no update mechanism; user scope by default):
+
+```text
+omp install https://github.com/EveryInc/compound-engineering-plugin
+```
+
+Local development link from a checkout:
+
+```bash
+omp plugin link "$PWD"
+```
+
+Verify an install plan before applying it:
+
+```text
+omp install <path-or-git> --dry-run --json
+```
+
+`/reload-plugins` refreshes skills and slash commands in a live session; restart omp for tools, hooks, or extension changes to apply.
+
+## Runtime contracts CE skills rely on
+
+| Contract | omp behavior |
+| --- | --- |
+| User skill invocation | `/skill:<name>` — one command per discovered skill; NOT `/skill-name` and NOT `$skill-name` |
+| Blocking questions | Built-in `ask` tool |
+| Subagent dispatch | Built-in `task` tool, with worktree isolation and schema-checked results |
+| Task tracking | Built-in `todo` tool |
+| MCP | Native MCP server support |
+| Bundled skill files | `skill://<name>/<path>` URL resolution |
+
+## Instruction files
+
+omp auto-loads `AGENTS.md`, walking ancestors from the current working directory. This repo's root `AGENTS.md` is already the canonical project instruction file for omp, so no CE action is needed.
+
+## Session storage
+
+omp writes sessions as JSONL under a session root resolved in this order:
+
+1. `$PI_CODING_AGENT_SESSION_DIR` — direct override; files are stored flat in it.
+2. `$PI_CODING_AGENT_DIR` — agent-dir override, honored for the default profile only; sessions land in `<agentDir>/sessions/`.
+3. `$HOME/${PI_CONFIG_DIR:-.omp}/agent/sessions/` — default location.
+
+Named profiles (`OMP_PROFILE` or `PI_PROFILE`) relocate the root to `$HOME/${PI_CONFIG_DIR:-.omp}/profiles/<name>/agent/sessions/`.
+
+Inside the session root, per-project buckets come in two shapes. omp 17.2.9 restored the legacy project-scoped naming scheme and removed its automatic migration ([#7646](https://github.com/can1357/oh-my-pi/issues/7646)), so both shapes occur in the wild and discovery must scan both:
+
+- Raw (current again since 17.2.9): `-<home-relative>` for cwds under the canonical home, `-tmp-<tmp-relative>` for cwds under the temp root, and `--<abs>--` otherwise, with path separators and `:` encoded as `-` and the basename kept verbatim (spaces included).
+- Hashed (intermediate releases): `<scope>-<sanitized-basename>-<sha256hex-of-canonical-cwd>`, where `scope` is `home`, `tmp`, or `abs` and the basename is sanitized (`[^a-zA-Z0-9._-]+` runs become `-`, edge dashes stripped, capped at its last 80 chars, empty falls back to `project`).
+
+Each bucket holds `<timestamp>_<sessionId>.jsonl` files.
+
+Every session JSONL physically begins with a fixed-width 256-byte `{"type":"title","v":1,...,"pad":"..."}` slot line, followed by a pi-shaped `{"type":"session","version":3,...,"cwd":...}` header. This title-slot-first shape distinguishes omp session files from pi session files, which start directly with the `type:"session"` header.
+
+Known gap: XDG-relocated roots (`$XDG_DATA_HOME/omp`) are not scanned by CE's session-discovery script.