How to create a personal OMP marketplace for shared agent configuration

Agent configuration starts small. One instruction file here, a few skills there, a TypeScript extension to fix one workflow. Across several computers, it turns into symlinks, manual copies, and files that only work on the machine where they were created.

OMP solves a different part of that problem: it can install extensions as versioned plugins. A marketplace is the catalog that lists plugins; the plugin is the package OMP installs and loads. That separation lets a personal repository become one configuration source without making OMP depend on the repository’s local path.

What OMP installs

OMP is a terminal-based development agent. It brings sessions, models, tools, skills, extensions, and MCP integrations into one surface for working in repositories.

An OMP plugin can load conventional resources such as:

• skills/ for specialized instructions;
• TypeScript or JavaScript extensions;
• themes;
• prompts and other resources recognized by the package manifest;
• MCP definitions when the plugin needs to provide them;
• complementary configuration applied by an extension during startup.

The marketplace is not the plugin. The catalog points to a plugin directory and declares its version:

{
  "name": "personal",
  "version": "0.1.0",
  "source": "./personal"
}

When you run omp plugin install personal@owner, OMP reads the marketplace, installs a managed copy, and records the version in local state. The session loads the installed content, not the original checkout.

That distinction matters. Editing the repository does not immediately change a running setup. The workflow becomes: edit, bump the version, publish the change, and run omp plugin upgrade on the other computers.

Structure the repository as a marketplace

A repository that already contains agent configuration can keep its documentation and scripts, but it should separate installable content:

agents/
├── .omp-plugin/
│   └── marketplace.json
├── plugins/
│   └── personal/
│       ├── package.json
│       ├── config.yml
│       ├── mcp.json
│       ├── AGENTS.md
│       ├── skills/
│       ├── themes/
│       └── extensions/
├── docs/
└── scripts/

The catalog lives in .omp-plugin/marketplace.json:

{
  "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
  "name": "owner",
  "owner": { "name": "Personal" },
  "metadata": {
    "description": "Personal OMP extensions",
    "version": "1.0.0",
    "pluginRoot": "./plugins"
  },
  "plugins": [
    {
      "name": "personal",
      "description": "Personal OMP configuration",
      "version": "0.1.0",
      "category": "development",
      "source": "./personal"
    }
  ]
}

The plugin manifest declares its extensions and resources:

{
  "name": "@owner/personal",
  "version": "0.1.0",
  "private": true,
  "type": "module",
  "omp": {
    "extensions": ["./extensions/personal-config.ts"]
  },
  "skills": ["./skills"],
  "themes": ["./themes"]
}

owner is only a marketplace identifier. In a private personal repository, it does not need to represent a public organization.

Install on each computer

After cloning or publishing the repository, add the marketplace and install the plugin:

omp plugin marketplace add /path/to/agents
omp plugin install personal@owner

For a remote marketplace, use your repository’s Git source. Install the package that provides the models used by the profile first if the personal configuration points to an external provider:

omp plugin marketplace add <provider-marketplace>
omp plugin install <provider-plugin>@<provider-owner>

Validate the result:

omp plugin doctor personal@owner
omp config get modelRoles --json
omp config get theme.dark --json

doctor checks the plugin installation. The configuration commands show whether the shared profile was applied in the current session.

Apply a shared profile without symlinks

config.yml can live inside the versioned plugin. The extension reads the YAML file and applies only keys supported by OMP, such as:

• model roles and aliases;
• retry fallbacks;
• memory backend;
• theme;
• skills and provider isolation;
• composer shape;
• display preferences.

This is different from copying one complete config.yml to every computer. The plugin acts as an application layer: the versioned file is the shared source, while OMP still persists effective local settings in the agent directory.

The extension can also inject AGENTS.md into the system prompt and register extensions such as a session-renaming tool or completion sounds. Skills and themes should be loaded through the plugin resource mechanism, not through symlinks to the checkout.

The boundary is intentional: session state, caches, local databases, tokens, and machine-specific preferences do not belong in the shared plugin.

Share MCPs without sharing secrets

MCPs are the easiest part to configure incorrectly. The definition can be shared; credentials cannot.

Keep references to environment variables in the repository:

{
  "n8n-mcp": {
    "enabled": false,
    "type": "http",
    "url": "http://localhost:<n8n-port>/mcp-server/http",
    "headers": {
      "Authorization": "Bearer ${N8N_API_KEY}"
    }
  }
}

Export the value on each computer before starting OMP:

export AIHUB_TOKEN="..."
export GRAFANA_SERVICE_ACCOUNT_TOKEN="..."
export GRAFANA_SERVICE_ACCOUNT_URL="..."
export SHORTCUT_API_TOKEN="..."
export N8N_API_KEY="..."

The plugin can merge its definitions into ~/.omp/agent/mcp.json while preserving local servers that are not in the package. Variable expansion must happen in the user configuration supported by OMP; do not assume that a packaged .mcp.json will expand ${VAR} by itself.

Document local dependencies too. uvx and npx must be on PATH; Playwright needs a browser; a local HTTP MCP needs its service running. Do not put Homebrew paths, dynamic CDP ports, or computer-specific directories in a shared plugin.

Remote OAuth MCPs follow a different flow: enable the server and authorize the account on each computer. An environment variable does not replace OAuth state.

Update with versions

When shared content changes:

# edit the plugin
# bump the version in package.json and marketplace.json
git add .omp-plugin plugins/personal
git commit -m "fix(omp): update personal configuration"
git push

On each computer:

omp plugin marketplace update owner
omp plugin upgrade personal@owner

Version bumps are not ceremony. They tell OMP that the installed package changed and create a clear point at which to reproduce or roll back the configuration.

Checklist

• Separate the marketplace catalog from the installable plugin directory.
• Version package.json and the matching marketplace entry together.
• Move skills, extensions, and themes into the plugin.
• Apply config.yml through an extension instead of relying on symlinks.
• Share MCP definitions with ${ENV_VAR}, never real tokens.
• Use uvx, npx, and relative or portable paths.
• Keep sessions, caches, OAuth state, and secrets outside the repository.
• Install the model provider before the plugin that uses its model IDs.
• Validate with omp plugin doctor and a real session.

Conclusion

A personal marketplace turns agent configuration into an installable, versioned package. The benefit is not distributing code to strangers; it is making every computer load the same deliberate setup while leaving machine-specific state local.

The most important boundary is the secret boundary: the marketplace shares the integration shape, while each computer supplies credentials, OAuth state, and local services.