OMP

Setup is harness-agnostic — see the quickstart for creating a hall and opening your first session. This page covers what is specific to OMP once you're there.

For the end-to-end flow with this harness across repos, see Use OMP with multiple repositories.

What lands in .omp/

An OMP session materialises a .omp/ directory at the view directory's root, alongside the promoted repos:

.omp/commands/ holds the ivar-*.md command templates; ivar sync gitignores them, and the extension below registers them with OMP. .omp/skills/ carries every skill from both roots — the hall's committed skills and your personal ones — materialised under its bare id; the directory itself is gitignored because each child is a derived symlink back into .ivar/. AGENTS.md is the provider-native instructions file OMP reads at startup. .omp/mcp.json configures the hall's MCP servers under the mcpServers key.

Pre-tool hook

The read-only guard is enforced by .omp/hooks/pre/ivar.js.

OMP discovers .omp/hooks/pre/*.js and loads each in-process as an ES module whose default export is a factory receiving the hook API. The handler registers on tool_call and blocks by returning { block: true, reason }, where reason becomes the tool error the model sees.

The hook does not evaluate policy itself: it shells out to ivar guard --provider omp and translates a non-zero exit into the structured verdict, reading the reason from stdout. See guards for the policy rules.

Memory hooks

.omp/hooks/pre/ivar-memory.js spawns ivar memory capture --provider omp for each event and appends it to the hall's capture spool. .omp/hooks/pre/ivar-brief.js runs ivar memory brief --provider omp on the first before_agent_start of the process and hands the open handoffs to the agent as a hidden ivar-brief message. A reload of the hook shows the brief again.

When memory.capture is false in ivar.json, ivar sync writes no capture hook; while capture is on, ivar doctor reports a missing one as provider.capture_hook_missing. See Hall memory.

Extension

.omp/extensions/ivar.js registers the /ivar-* commands and completes feature names.

OMP discovers .omp/extensions/*.js and loads each in-process as an ES module whose default export is a factory receiving the extension API.

Commands

OMP's own command discovery skips gitignored files, and ivar sync gitignores .omp/commands/ivar-*.md. So the extension registers every ivar-*.md in the .omp/commands/ next to it through pi.registerCommand, using the file's frontmatter description. Running /ivar-<name> <args> re-reads the file, drops the frontmatter, replaces $ARGUMENTS with <args> (or appends them when the template has no placeholder) and sends the result as your message.

Extension commands take precedence over file commands of the same name, so a hall whose .gitignore still lets OMP see the files never lists a command twice. A missing or unreadable command file is skipped; the rest still load.

Feature-name completion

When the user types the argument of a shipped /ivar-* command that takes an existing feature, the extension offers candidates from ivar feature list --json.

In a session already bound to a feature (IVAR_FEATURE set), or on any line that does not match those commands, it delegates entirely to the live current provider — every method is forwarded so normal file and command completion is uninterrupted.

Session projections

Every provider projects its command catalog into the session's config directory. OMP additionally projects .omp/hooks/pre → hooks/pre and .omp/extensions → extensions because OMP discovers those directories inside the session.

MCP servers

ivar writes MCP servers under the mcpServers key of .omp/mcp.json. Canonical http transports remain http; canonical local transports map to stdio.

Every http server gets an auth block with type: "oauth" and credentialId: "mcp_oauth_ivar:<hall>-<server>", the per-hall id under which ivar mcp auth stores the credential. When the server's OAuth metadata has a token_url, the block also carries clientId, clientSecret (formatted as ${VAR} when a secret environment variable is configured), tokenUrl, and optional resource, so omp can refresh the token. Deep MCP setup lives at MCP provider reference.

Add it to an existing hall

The quickstart covers ivar init. If the hall already exists with a different provider, add OMP alongside it:

ivar provider add omp