Skip to content
Closed
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion AGENTS.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
29 changes: 26 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -400,6 +400,23 @@ Recommended companion for richer blocking questions:
pi install npm:pi-ask-user
```

### oh-my-pi (omp)

oh-my-pi (omp) installs this repository directly because the repo ships native `package.json#pi` package metadata plus the Claude marketplace catalog — omp reads both, so no conversion step is needed:

```text
omp install https://github.com/EveryInc/compound-engineering-plugin
```

Or use the marketplace flow:

```text
omp plugin marketplace add EveryInc/compound-engineering-plugin
omp plugin install compound-engineering@compound-engineering-plugin
```

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`. For local development from a checkout, use `omp plugin link "$PWD"`. 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:
Expand Down Expand Up @@ -565,6 +582,12 @@ Restart OpenCode after changing `opencode.json`.
pi -e "$PWD"
```

**oh-my-pi (omp)**

```bash
omp plugin link "$PWD"
```

**Antigravity CLI (`agy`)**

```bash
Expand All @@ -582,7 +605,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.

Expand Down
2 changes: 1 addition & 1 deletion docs/skills/ce-compound.md
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ Most teams solve the same problem twice — sometimes with the same person — b

### 1. Two modes — Full vs Lightweight, agent-selected

**Full mode** runs three research subagents in parallel (Context Analyzer / Solution Extractor / Related Docs Finder), plus an automatic session-history probe that searches your prior sessions across Claude Code, Codex, and Cursor for related context. Cross-references existing docs, detects duplicates, runs specialized reviews.
**Full mode** runs three research subagents in parallel (Context Analyzer / Solution Extractor / Related Docs Finder), plus an automatic session-history probe that searches your prior sessions across Claude Code, Codex, Cursor, Pi, and oh-my-pi (omp) for related context. Cross-references existing docs, detects duplicates, runs specialized reviews.

**Lightweight mode** writes the same solution-doc artifact type in a single pass, with no subagents or cross-referencing. It is lower overhead, but it also skips overlap detection, session-history research, and semantic grounding validation.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
84 changes: 84 additions & 0 deletions docs/specs/omp.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
# oh-my-pi (omp) Spec (Plugins and Skills)

Last verified: 2026-08-05 against omp 17.2.7

## Primary sources

```
https://github.com/can1357/oh-my-pi/blob/v17.2.7/README.md
https://github.com/can1357/oh-my-pi/blob/v17.2.7/docs/skills.md
https://github.com/can1357/oh-my-pi/blob/v17.2.7/docs/marketplace.md
https://github.com/can1357/oh-my-pi/blob/v17.2.7/docs/session.md
https://github.com/can1357/oh-my-pi/blob/v17.2.7/docs/config-usage.md
https://github.com/can1357/oh-my-pi/blob/v17.2.7/docs/environment-variables.md
https://github.com/can1357/oh-my-pi/blob/v17.2.7/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, with `extensions` (`./.pi/extensions/compound-engineering.ts`) and `skills` (`./skills`) arrays — the same pi package metadata Pi already consumes.
- The Claude marketplace catalog at `.claude-plugin/marketplace.json`, which omp reads as a fallback when `.omp-plugin/marketplace.json` is absent. omp prefers `.omp-plugin/marketplace.json` only when that file is present; Compound Engineering deliberately ships only the Claude catalog for cross-host parity.

A dry run of `omp install` against this repository confirms both 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.

## Install commands

Direct install from a path or Git URL (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"
```

Marketplace flow (marketplace name `compound-engineering-plugin`, plugin name `compound-engineering`, both from `.claude-plugin/marketplace.json`):

```text
omp plugin marketplace add EveryInc/compound-engineering-plugin
omp plugin install compound-engineering@compound-engineering-plugin
```

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 use the shape `<scope>-<sanitized-basename>-<sha256hex-of-canonical-cwd>`, where `scope` is `home`, `tmp`, or `abs`. Legacy unmigrated buckets also appear as `-<home-relative>` and `--<abs>--` shapes. 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.
4 changes: 2 additions & 2 deletions skills/ce-babysit-pr/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ Once a signal appears on the current head, it starts an **incomplete review life

**Mutation envelope (what running this authorizes):** on the active target PR's head the loop fixes failing checks, commits, pushes, replies to and resolves review threads, refreshes a stale PR description, and performs Step 2's bounded routine branch-currency maintenance — autonomously, as its normal operation. When that owned work pushes a target in a **confirmed managed stack**, preserving the manager's linear chain is part of the same authorization: the loop performs the manager-owned upstack maintenance in Step 2. Mutating review/CI work on a *different* PR is semantic scope, so it begins only after the user explicitly requested the whole managed stack or accepted Step 1's one-time stack-wide continuation offer. It **never** merges the PR, approves a gated CI run, changes stack structure, rebases the active target onto trunk/its parent, runs raw `git rebase`/`git push --force`, or rewrites a manual dependency chain. Being asked to babysit the PR is what authorizes this envelope — see Step 2's pre-authorization and the bounded scope it passes to the skills it delegates to.

**Asking the user:** When this skill says "ask the user", use the platform's blocking question tool: `AskUserQuestion` in Claude Code (call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded), `request_user_input` in Codex, `ask_question` in Antigravity CLI (`agy`), `ask_user` in Pi. Fall back to presenting the question in chat only when no blocking tool exists or the call errors. Never silently skip the question.
**Asking the user:** When this skill says "ask the user", use the platform's blocking question tool: `AskUserQuestion` in Claude Code (call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded), `request_user_input` in Codex, `ask_question` in Antigravity CLI (`agy`), `ask_user` in Pi, `ask` in oh-my-pi (`omp`). Fall back to presenting the question in chat only when no blocking tool exists or the call errors. Never silently skip the question.

**Invoking another skill:** When this skill says "invoke `ce-resolve-pr-feedback`" or "invoke `ce-debug`", use the platform's skill-invocation primitive (the `Skill` tool in Claude Code, the equivalent elsewhere). These are separate skills with their own engines — do not reimplement their work inline. They run non-interactively here: anything either one cannot safely decide comes back as a `needs-human` result, which you surface and route around (never block the loop waiting on it).

Expand Down Expand Up @@ -69,7 +69,7 @@ Once accepted, that one decision authorizes sequential semantic babysitting thro

Then establish **how the watch sustains itself** — a skill can't be re-invoked by magic once its turn ends, so *you* set up the loop. **The default is a self-sustaining, in-session watch: you do not do one tick and hand back a resume command.** Read `references/watch-loop.md` for the mechanics, then:

**User-runnable resume syntax.** Whenever this skill prints or copies a resume invocation, default to `/ce-babysit-pr <url>`. Use `$ce-babysit-pr <url>` only when the active host is Codex or explicitly documents dollar-prefixed skill invocation. Render only the invocation as inline code and output one form only.
**User-runnable resume syntax.** Whenever this skill prints or copies a resume invocation, default to `/ce-babysit-pr <url>`. Use `$ce-babysit-pr <url>` only when the active host is Codex or explicitly documents dollar-prefixed skill invocation. Use `/skill:ce-babysit-pr <url>` when the active host is oh-my-pi (`omp`). Render only the invocation as inline code and output one form only.

- **Self-sustaining in-session watch (default).** Start a cheap deterministic background change-detector — `pr-snapshot watch` (Step 2 has the invocation) — which polls the PR with **no agent tokens** and prints a single wake sentinel *only* when there's work to inspect or a stop condition. Then **stay in this session and wait for that sentinel**, using whatever background-and-wake capability your harness exposes. You need exactly one capability: *run a background process and be woken when it emits a line, without ending your turn* — reach for whatever your harness gives you (examples, not a fixed list: Claude Code's background `Bash` + a `Monitor`/wait, Cursor's `Shell` background + `notify_on_output`, Grok's `get_command_or_subagent_output`, `ScheduleWakeup` under `/loop`). On each wake, run **one tick** (Step 2's ordering invariant), persist, then go back to waiting (Step 5). The detector *only* flags that something changed — every tick's judgment (resolve comments, debug CI, decide merge-ready) is agent reasoning plus a sub-skill call, so re-enter *this* agent each wake; **do not collapse the loop into a shell script that greps and acts on its own** (`pr-snapshot watch` loops internally, which makes that substitution tempting — it cannot do the reasoning the tick requires). Staying in-session keeps everything decided in *this* conversation — declined nits, a reviewer judged wrong, your mid-run steering — and spends reasoning only when something actually changed. Continue until a Step 3 stop condition. **Describe the capability and use your own tool for it — do not ask the user to type a slash command; a skill drives tool calls, not keystrokes.**
- **Checkpoint (the honest floor).** Only when the harness genuinely exposes **no** background-and-wake capability (some sandboxed GUI apps): run **exactly one tick**, persist, report, and print the exact re-run command. Monitoring is *paused* — say so plainly. Never fake a loop with a foreground `sleep` (Claude Code blocks it) or by "just continuing" (nothing wakes the next tick).
Expand Down
2 changes: 1 addition & 1 deletion skills/ce-babysit-pr/references/watch-loop.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ The needed capability is generic — *run a background process and be woken when
| Codex (CLI) | a runtime-owned background exec that re-runs the tick (a detached `nohup` is **reaped** when the tool call ends) | No (session-bound) |
| GUI apps / headless / unknown | none reliable → **checkpoint** | — |

**User-runnable resume syntax.** Whenever this reference tells the skill to print or copy a resume invocation, default to `/ce-babysit-pr <url>`. Use `$ce-babysit-pr <url>` only when the active host is Codex or explicitly documents dollar-prefixed skill invocation. Render only the invocation as inline code and output one form only.
**User-runnable resume syntax.** Whenever this reference tells the skill to print or copy a resume invocation, default to `/ce-babysit-pr <url>`. Use `$ce-babysit-pr <url>` only when the active host is Codex or explicitly documents dollar-prefixed skill invocation. Use `/skill:ce-babysit-pr <url>` when the active host is oh-my-pi (`omp`). Render only the invocation as inline code and output one form only.

**Checkpoint (the floor):** when no background-and-wake capability exists, run one tick, persist, report, and print the exact host-rendered re-run invocation — monitoring is *paused*, say so plainly. Because every tick is disk-resumable, checkpoint is the same loop hand-cranked; the in-session watch only automates the crank. Never fake a loop with a foreground `sleep` (blocked on Claude Code, discouraged elsewhere) or a detached `nohup` (reaped/unsupported on several harnesses).

Expand Down
Loading