As skills e comandos que você criou no Claude Code funcionam no OpenCode?

Fala aí, beleza? Sua pasta .claude não vira lixo no dia em que você abre o OpenCode, mas ela também não atravessa inteira

Quem já montou skill, comando de barra e um CLAUDE.md caprichado quer saber uma coisa só antes de testar outro agente: o que vai junto e o que vai ter que ser reescrito do zero?

A resposta não é sim nem não, ela muda por TIPO de customização

Tem camada que o OpenCode lê de graça, tem camada que ele nem procura e tem camada que muda de formato por completo

Bora separar isso direitinho =)

Mapa do que atravessa: Claude Code x OpenCode

Antes de entrar no detalhe, o resumo visual

Cada linha aqui é um tipo de customização que você provavelmente já tem no projeto

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Repara no padrão

Quanto mais perto de "texto com frontmatter", mais portátil

Quanto mais perto de "código que se pluga no motor da ferramenta", menos portátil

Skills: o único pedaço que atravessa sem conversão

Aqui mora a boa notícia do post

O OpenCode lê skill nativamente e inclui os caminhos do Claude Code na própria lista de descoberta

Ou seja: uma skill que você escreveu pro Claude Code é ENCONTRADA sem conversão nenhuma

O formato é o mesmo dos dois lados: uma pasta por skill, com um SKILL.md dentro, e o arquivo começando com frontmatter YAML

Se você conhece a estrutura de .claude/skills/, você já conhece a do OpenCode, é literalmente a mesma coisa

A documentação de skills do OpenCode lista seis locais de busca:

Dois dos seis locais são exatamente onde suas skills já estão hoje, massa demais 😀

O que muda na prática:

Encontrar é uma coisa, o comportamento é outra

No OpenCode as skills são carregadas SOB DEMANDA, por uma ferramenta nativa de skill

E tem um detalhe que morde: skill sem description não é anunciada ao modelo

Então aquela skill meio preguiçosa, sem descrição, que no seu dia a dia você sempre chamava na mão, simplesmente não vai aparecer pro modelo do outro lado

Tome cuidado com isso antes de sair dizendo que "não funcionou"

O outro ponto é a identidade: skills são chaveadas por ID, e se várias fontes definirem o mesmo ID, a fonte posterior vence

Como .opencode/skills/ e .claude/skills/ podem coexistir no mesmo repositório, duas skills com o mesmo nome viram uma só na prática

Se você quer entender melhor onde uma skill roda de verdade fora do Claude Code, esse ponto de descoberta e precedência é o coração da história

Comandos de barra: onde a portabilidade quebra

Agora a parte chata

Os dois produtos têm comando de barra, mas eles não olham pra mesma pasta

No Claude Code os comandos foram unificados com as skills: o .claude/commands/deploy.md continua criando o mesmo /deploy que uma skill em .claude/skills/deploy/SKILL.md, só que o formato de commands/ virou o legado e o recomendado hoje é a skill

No OpenCode o comando é um markdown na pasta de comandos, e o nome do arquivo vira o nome do comando

Fora da tabela ainda tem duas diferenças que valem o parágrafo

Do lado do Claude Code, a skill não vive só do /nome: ela também pode ser acionada sozinha quando a description casa com a tarefa, e ainda permite empacotar scripts, templates e documentação de referência junto do prompt

Do lado do OpenCode, o comando trabalha com entrada: tem o placeholder $ARGUMENTS pra passar argumentos e a sintaxe !comando pra injetar a saída de um comando bash dentro do prompt

E se você criar um comando customizado com o mesmo nome de um embutido do OpenCode, o seu tem precedência e sobrescreve o built-in

E o .claude/commands/? O OpenCode não descobre essa pasta nativamente

Ele suporta .claude/skills/ pra skill, mas não .claude/commands/ pra comando, e a paridade segue como pedido de recurso em aberto no repositório (issues #6985 e #12291)

Então sobram duas saídas reais, e as duas são honestas:

1. Reescrever o comando como skill: já que a skill atravessa e o próprio Claude Code recomenda o formato de skill hoje, mover /deploy de commands/ pra skills/deploy/SKILL.md resolve os dois lados de uma vez
2. Usar o plugin de terceiro: o oh-my-opencode, mantido por code-yeongyu, traz uma camada de compatibilidade com o Claude Code e mantém disponíveis os slash commands de ~/.claude/commands/ e ./.claude/commands/, com liga e desliga pelo campo claude_code do oh-my-opencode.json (que cobre mcp, commands, skills, agents, hooks e plugins)

A opção 1 é a que deixa seu setup portátil de verdade

A opção 2 é a que salva quem tem trinta comandos escritos e zero vontade de mexer neles hoje, hehe

CLAUDE.md, AGENTS.md e o resto do setup (agentes, plugins e hooks)

Instrução de projeto é o segundo pedaço que atravessa bem

O OpenCode usa AGENTS.md pras regras do projeto e ~/.config/opencode/AGENTS.md pras regras globais

Pra quem vem do Claude Code tem fallback: o CLAUDE.md do projeto é usado se não existir AGENTS.md, e o ~/.claude/CLAUDE.md é usado se não existir ~/.config/opencode/AGENTS.md

Vale o primeiro arquivo que casar em cada categoria, ou seja, não é soma, é o primeiro que aparecer

E se você quiser gerar o arquivo em vez de copiar na mão, o OpenCode tem o /init, que varre os arquivos importantes do repositório e cria ou atualiza o AGENTS.md

E o que NÃO atravessa:

Agente customizado no OpenCode vem de outro lugar: você configura no opencode.json ou define em arquivo markdown, onde o nome do arquivo vira o nome do agente (review.md cria o agente review)

Plugin é o caso mais duro

Um plugin do Claude Code é uma pasta com .claude-plugin/plugin.json, que pode empacotar skills, agentes, hooks e servidores MCP de uma vez

O OpenCode não lê esse formato diretamente, e existe issue de feature request aberta pedindo o carregamento de plugins do diretório .claude/ (#8158)

Do lado de lá, plugin é outra criatura: código em JavaScript ou TypeScript que se conecta a eventos (execução de ferramenta, criação de sessão, limite de contexto, entre outros) pra mudar o comportamento do agente

Isso não é conversão, é reescrita, e não adianta se enganar quanto a isso

Três cenários: migrar de vez, manter os dois ou só testar

Cenário 1: só quero testar o OpenCode

Esse é o mais tranquilo

Não mexe em nada, deixa tudo no .claude e abre o projeto

Suas skills vêm de graça, porque os dois caminhos do Claude Code já estão na lista de descoberta, e o CLAUDE.md entra pelo fallback caso não exista AGENTS.md

O que vai faltar são os comandos de barra, e só

Cenário 2: vou manter os dois em paralelo

Muita gente cai nesse cenário depois de esbarrar nos limites de uso do Claude Code no meio de um trabalho e querer um plano B aberto na outra janela

Se é o seu caso, a regra é simples: concentre a customização em skill e no arquivo de instruções, porque é o que os dois leem

Tudo que você escrever como skill roda dos dois lados sem duplicar manutenção

Um cuidado aqui: se as duas árvores de pastas coexistirem no mesmo projeto, atenção ao ID repetido

Skill com o mesmo ID em .opencode/skills/ e em .claude/skills/ não vira duas, vira uma, e a fonte posterior é a que vence

Cenário 3: vou migrar de vez

1. Roda o /init no OpenCode pra gerar ou atualizar o AGENTS.md do projeto, em vez de depender do fallback do CLAUDE.md pra sempre
2. Confere se cada skill tem description no frontmatter, senão ela não é advertida ao modelo e você vai jurar que a skill sumiu
3. Reescreve os comandos: os que fazem sentido viram skill, os que dependem de argumento ou de saída de shell viram comando do OpenCode, com $ARGUMENTS e !comando
4. Refaz agente no opencode.json ou em markdown, e plugin como código plugado em eventos

O erro comum do passo 3 é assumir que basta copiar o markdown do comando pra pasta nova

O nome do arquivo vira o comando e o frontmatter é outro (description, agent, model), então revisa o cabeçalho antes de sair copiando

Quanto do seu setup você perde ao usar os dois

O veredito honesto não é um número, é uma conta que você faz olhando pras suas pastas

Soma sua customização por camada e vê onde ela está concentrada:

Se a maior parte do seu setup está em skill, trocar de agente é quase indolor

Se está tudo em comando de barra e hook, você não tem um setup portátil, você tem um setup do Claude Code, e não tem problema nenhum nisso, desde que você saiba

A regra de bolso pra quem quer portabilidade:

• escreva como skill sempre que der (é o formato que os dois leem)
• use o arquivo de instruções como base comum do projeto
• trate comando, plugin e hook como código específico de cada ferramenta, e não conte com eles atravessando

Conclusão

O compartilhamento real hoje é skill mais arquivo de instruções

Esses dois pedaços atravessam sem conversão, e é neles que vale investir se você pretende rodar mais de um agente

Os pontos que continuam abertos, comando e plugin, não são mistério: são feature request registrados no repositório, que hoje vive em github.com/anomalyco/opencode, depois da saída de sst/opencode

Próximo passo bem concreto pra hoje: abre um projeto seu no OpenCode, confere quais skills do .claude aparecem e faz a lista dos comandos que ficaram pra trás

Aí sim você decide o que reescrever, com a lista na mão em vez de no achismo 🙂

até o próximo post!