Como criar um marketplace pessoal para compartilhar sua configuração do OMP

Configurações de agentes de IA começam pequenas. Um arquivo de instruções aqui, algumas skills ali, uma extensão TypeScript para resolver um comportamento específico. Depois de alguns computadores, a configuração vira uma coleção de symlinks, cópias manuais e arquivos que só funcionam na máquina onde foram criados.

O OMP resolve uma parte diferente desse problema: ele consegue instalar extensões como plugins versionados. Um marketplace é o catálogo que diz quais plugins existem; o plugin é o pacote que o OMP instala e carrega. Essa separação permite usar um repositório pessoal como fonte única de configuração sem fazer o OMP depender do caminho local do repositório.

O que o OMP instala

O OMP é um agente de desenvolvimento executado no terminal. Ele reúne sessões, modelos, ferramentas, skills, extensões e integrações MCP em uma superfície única para trabalhar em repositórios.

Um plugin instalado pelo OMP pode carregar recursos convencionais, como:

• skills/ para instruções especializadas;
• extensões TypeScript ou JavaScript;
• temas;
• prompts e outros recursos reconhecidos pelo manifesto do pacote;
• definições de MCP quando o fluxo do plugin precisar fornecê-las;
• configuração complementar aplicada por uma extensão durante a inicialização.

O marketplace não é o plugin. O catálogo aponta para um diretório de plugin e informa sua versão:

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

Quando você executa omp plugin install personal@owner, o OMP baixa ou lê o marketplace, instala uma cópia gerenciada e registra a versão no estado local. A sessão passa a carregar o conteúdo instalado, não o checkout original.

Essa última parte é importante. Editar o repositório não altera imediatamente a sessão. O fluxo passa a ser: editar, aumentar a versão, publicar a mudança e executar omp plugin upgrade nas outras máquinas.

Estruture o repositório como marketplace

Um repositório que já contém configuração de agentes pode continuar guardando documentação e scripts, mas precisa separar o conteúdo instalável:

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

O catálogo fica em .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"
    }
  ]
}

O manifesto do plugin declara as extensões e os recursos que serão carregados:

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

O nome owner é apenas um identificador do marketplace. Em um repositório privado pessoal, ele não precisa representar uma organização pública.

Instale em cada computador

Depois de clonar ou publicar o repositório, adicione o marketplace e instale o plugin:

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

Para um marketplace remoto, use a origem Git do seu repositório. Antes do plugin pessoal, instale o plugin que fornece os modelos usados pelo perfil, caso sua configuração aponte para um provider externo:

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

Valide o resultado:

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

O doctor confirma a instalação do plugin. Os comandos de configuração mostram se o perfil comum foi aplicado na sessão atual.

Aplique um perfil comum sem symlink

O arquivo config.yml pode ser versionado dentro do plugin. A extensão lê o YAML e aplica somente as chaves que o OMP suporta, como:

• roles e aliases de modelos;
• fallback de retry;
• backend de memória;
• tema;
• isolamento de skills e providers;
• formato do composer;
• preferências de exibição.

Isso é diferente de copiar um config.yml inteiro para cada computador. O plugin atua como uma camada de aplicação: o arquivo versionado é a fonte comum, enquanto o OMP continua persistindo sua configuração efetiva no diretório local do agente.

A extensão também pode injetar um AGENTS.md no system prompt e registrar extensões como uma ferramenta de renomear sessão ou sons de conclusão. Skills e temas devem ser carregados pelo mecanismo de recursos do próprio plugin, não por symlinks para o checkout.

O limite é intencional: estado de sessão, cache, banco local, tokens e preferências específicas da máquina não pertencem ao plugin compartilhado.

Compartilhe MCPs sem compartilhar segredos

MCPs são a parte mais fácil de configurar errado. A definição pode ser comum; credenciais não.

No repositório, mantenha apenas referências a variáveis:

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

Em cada máquina, exporte o valor antes de iniciar o OMP:

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

O plugin pode mesclar suas definições em ~/.omp/agent/mcp.json, preservando servidores locais que não estão no pacote. A expansão das variáveis deve ocorrer na configuração de usuário suportada pelo OMP; não presuma que um .mcp.json empacotado expandirá ${VAR} sozinho.

Documente também dependências locais. uvx e npx precisam estar no PATH; Playwright precisa de um navegador; um MCP HTTP local precisa do serviço rodando. Não grave caminhos absolutos de Homebrew, portas dinâmicas de CDP ou diretórios do seu computador no plugin comum.

MCPs remotos com OAuth, como integrações de documentação ou incidentes, seguem outro fluxo: habilite o servidor e autorize a conta em cada máquina. Variável de ambiente não substitui o estado OAuth.

Atualize com versões

Quando o conteúdo compartilhado muda:

# editar o plugin
# aumentar a versão em package.json e marketplace.json
git add .omp-plugin plugins/personal
git commit -m "fix(omp): update personal configuration"
git push

Em cada computador:

omp plugin marketplace update owner
omp plugin upgrade personal@owner

O aumento de versão não é burocracia. Ele informa ao OMP que o pacote instalado mudou e cria um ponto claro para reproduzir ou reverter a configuração.

Checklist

• Separar catálogo do marketplace e diretório instalável do plugin.
• Versionar package.json e a entrada correspondente do marketplace juntos.
• Mover skills, extensões e temas para o plugin.
• Aplicar config.yml por extensão, em vez de depender de symlink.
• Compartilhar MCPs com ${ENV_VAR}, nunca com tokens reais.
• Usar uvx, npx e caminhos relativos ou portáveis.
• Manter sessões, caches, OAuth e segredos fora do repositório.
• Instalar o provider de modelos antes do plugin que usa seus IDs.
• Validar com omp plugin doctor e uma sessão real.

Conclusão

Um marketplace pessoal transforma uma configuração de agente em um pacote instalável e versionado. O ganho não é distribuir código para terceiros; é fazer cada computador carregar a mesma configuração deliberada, deixando no ambiente local apenas o que realmente depende daquela máquina.

A fronteira mais importante é a dos segredos: o marketplace compartilha a forma da integração, enquanto cada computador fornece credenciais, OAuth e serviços locais.