Loading
>-
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add amElnagdy/delegate-skills --skill omp-delegate -a cursor -y
>-
omp) as a background implementer, then review its
diff and land it yourself. Use this whenever the user wants to delegate implementation work to
Oh My Pi / omp - phrasings like "have omp implement X", "delegate this to oh my pi", "run it
through omp", "use oh-my-pi to implement/fix/refactor" - or wants to run a queue of coding
tasks through omp while staying the reviewer. DO NOT USE for tasks small enough to do inline,
when the user wants the code written directly without delegating, or when they mean the original
Pi CLI (pi) — that is pi-delegate.
license: MIT
compatibility: Requires the omp CLI installed and authenticated (/login inside omp, or a provider API-key environment variable), Node 18+, and git. The orchestrating agent must be able to run shell commands and read files. Shell examples assume bash/zsh (macOS/Linux, or Git Bash/WSL on Windows).
metadata:
version: 0.5.0You are the orchestrator. Delegate a bounded coding task to a separate implementer - Oh My
Pi (omp) - then review what it produced and land it yourself. You write the brief and own the
judgment; the implementer makes changes in its own session; you verify and commit.
The loop needs only a shell command and file access, so any comparable orchestrator can drive it.
omp, not piOh My Pi is a fork of Pi. This skill drives omp (@oh-my-pi/pi-coding-agent). The original
Pi CLI is a different binary (pi) with a different skill (pi-delegate). If omp is missing but
pi is installed, you have Pi, not Oh My Pi.
omp CLI is not installed or authenticated.pi) — use pi-delegate.--read-only restricts the tool
surface; a write-capable run executes without prompts (--yolo).bun install -g @oh-my-pi/pi-coding-agent (or the install path from
https://omp.sh)./login inside omp for a subscription provider, or an API-key environment
variable for an API-key provider. Credentials live under ~/.omp/.omp --version succeeds.--cd at, the target git repository.Omit --model (and --provider) to use omp's configured default for this project / profile. The
catalog is this install's authenticated providers — not a fixed list in this skill.
To pick another model:
omp --list-models — that flag is
gone and omp treats it as an unknown flag (exit 2). Use the models subcommand:
omp models — every available model, grouped by provideromp models --json — the same catalog, machine-readableomp models find <substring> — filter by provider, id, or name (example:
omp models find sonnet)omp models <provider> — one provider's models--model <pattern> is omp's own --model: a fuzzy match against
the catalog (provider/id, a bare id, or a unique substring). --provider <name> pins the
provider when the pattern is ambiguous.. _ : / -. Glob patterns with * are rejected.--thinking <level> is a separate reasoning dial, not a model id. Allowed values: off, auto,
minimal, low, medium, high, xhigh, max. The relay rejects anything else (including
inherit) before dispatch — omp would otherwise warn and ignore a bad value.
A fleet lane (--lane) can set provider, model, and effort. Lane effort becomes
--thinking; an explicit --thinking / --model / --provider flag wins over the lane.
The relay does not forward --api-key, --smol, --slow, or --plan. Those stay omp's own CLI.
Run these five steps per task. Steps 1, 4, and 5 require judgment; 2 and 3 are mechanical.
Oh My Pi sees only the text you send plus what it can inspect in the workspace - no chat history or
shared context. Include the goal, current state, what to change, what to leave untouched, the
project's actual gates, and a report contract. Tell omp not to commit. Keep one task per brief.
omp auto-loads AGENTS.md/CLAUDE.md context files from the workspace and its parents, so repo
instructions reach it without inlining. See
references/writing-the-brief.md.
For Codex orchestration of background work, install and configure the separate
codex-background support utility first. If its MCP tools or registry are missing, stop and
report the setup requirement; do not silently fall back to model-driven polling. Then invoke its
registered delegate_run MCP tool once in place of the shell example below.
Follow that skill for structured common arguments, unchanged provider flags and reattachment by
runId. Keep the request pending until completion, then continue this skill's review and landing
steps. Other orchestrators keep the shell workflow below.
Use the bundled relay. It pipes the brief to omp --mode json on stdin, captures the JSON event
stream, and writes result.json. (<skill-dir> is the installed folder containing this
SKILL.md.)
node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# list models first: omp models (or: omp models --json)
# choose a model: add --model <id from omp models>
# choose a provider: add --provider <name>
# set thinking level: add --thinking high
# read-only run (review/diagnosis): add --read-only
# trust project .omp resources: add --approve
# resume the most recent session: add --resume-last (delta brief only)
# resume a specific session: add --session <id> (delta brief only)
# hard time limit (watchdog): add --timeout 2h (the 30m default suits short runs; implementation briefs routinely need 1-2h)
# see all options: node .../relay.mjs --help
The child process's cwd pins the workspace. The relay writes artifacts under the system temp dir by default and never commits. See references/dispatch-and-poll.md.
Codex using codex-background keeps the original MCP request pending: no model-driven sleep,
status or log polling. Use delegate_wait only to reattach after an interrupted request.
The relay blocks until omp finishes. Run it with the orchestrator's background-command facility,
or background it in the shell and poll for result.json. A pre-run usage error exits 2 and writes
no result; a missing omp exits 127 and writes status: "omp_unavailable".
Trust process state and the working tree over a progress display. Completion means the process
exited and result.json exists. omp's full report is the finalMessage field in result.json
(also printed in full on stdout between the report markers).
Treat omp's final message and gate claims as claims:
touchedFiles.The implementer edits the working tree; the orchestrator commits. Commit only after the gates
pass and the diff holds. If rework is needed, send a delta brief with --resume-last or
--session <id>, then review again.
Oh My Pi has no sandbox. Print mode has no approval UI, so a write-capable relay run always
passes --yolo (tools.approvalMode: yolo) — otherwise a user's always-ask or write config
would stall until the watchdog. The other controls are:
--read-only restricts omp's callable tools to --tools read,grep,glob. It does not pass
--yolo. Installed extension code still runs with the user's host permissions if project
resources are trusted.--no-extensions --no-skills --no-rules by default, so project .omp
extensions, skills, and rules stay undiscovered. --approve is the explicit opt-in for a
repository the user trusts.touchedFiles and the diff are the record of what changed. Inspect them after every run.Delegation is something the human opts into. Once they have ("run this queue", "proceed"), committing verified, gate-passing work is the agreed contract. Two limits remain: surface, don't absorb (report omp's design decisions, defensible-but-unasked turns, and non-blocking nitpicks) and stop for scope changes (if correct completion needs going beyond the brief, ask instead of expanding the mandate). See references/review-and-land.md.
result.json, polling, and failure recovery.