1 pontos por baekenough 2026-04-18 | 1 comentários | Compartilhar no WhatsApp

Quando você começa a usar vários agentes com Claude Code, acaba esbarrando repetidamente na mesma parede.
Escreve documentação de skills, encaixa YAML de agentes, pluga regras, amarra roteamento,
e, quando dá conflito, vai lá editar o CLAUDE.md na mão. E toda vez que muda de projeto, faz tudo de novo.

Foi por isso que criei o oh-my-customcode.
A frase no topo do README resume exatamente a identidade do produto.

Your AI Agent Stack. Compiled, Not Configured.

Há dois eixos principais.

1) Um agente não é configuração, e sim um artefato compilado.

  • .claude/skills/ = código-fonte (conhecimento e workflows reutilizáveis)
  • .claude/agents/ = artefatos de build (especialistas montados com skills)
  • mgr-sauron = compilador (validação estrutural)
  • .claude/rules/ = especificação (restrições e regras de build)
  • skill de roteamento = linker (conecta tarefas e agentes)

As skills evoluem de forma independente, e os agentes podem ser recompilados a qualquer momento com as skills atualizadas. Essa separação é o ponto de partida do runtime.

2) Se não houver especialista, ele é criado na hora.

Se alguém pedir "revise este módulo Terraform" e não existir um especialista cadastrado, em vez de o sistema falhar ele faz o seguinte.

  • Roteamento: confirma a ausência de um especialista em Terraform
  • mgr-creator: procura a skill infra-aws-expert + o guia docker-best-practices
  • gera infra-terraform-expert.md
  • executa a revisão imediatamente
  • o agente gerado permanece para chamadas futuras

Não é fallback; é parte do design. A ausência de especialização é tratada como um problema de build.


O que vem por padrão

Com um único omcustom init, você recebe 48 agentes / 107 skills / 22 regras / 39 guias.

  npm install -g oh-my-customcode  
  cd your-project  
  omcustom init  

Algumas decisões de design

  • A conversa principal é um orquestrador singleton (R010).
    Ele não escreve arquivos diretamente; todo o trabalho é delegado, via roteamento, a agentes dedicados.
    Assim, o contexto não se mistura.

  • O tiering de modelos foi definido de forma explícita.
    Arquitetura e pesquisa usam opus; implementação e geração de agentes usam sonnet.
    Busca e validação por contagem usam haiku. O padrão reasoning-sandwich (opus → sonnet → haiku) é a forma básica.

  • Trabalhos independentes rodam em paralelo (R009).
    No máximo 4 por mensagem.

  • Os hooks de segurança são advisory.
    secret-filter, audit-log, schema-validator, PostCompact (reinjeção de regras após compactação).
    Eles não bloqueiam; apenas deixam avisos.

  • O RTK é instalado por padrão para reduzir em 60% a 90% os tokens de saída da CLI.


Falando com sinceridade

Já existem várias coisas na linha de "plugin do Claude Code ao estilo oh-my-zsh".
Eu mesmo usei algumas e tenho respeito genuíno por elas.
Por isso, o oh-my-customcode dá menos ênfase a uma coleção de templates e mais ao lado de runtime, com compilador, roteador e gerenciadores em funcionamento.
Se quiserem saber o que ele resolve de forma diferente em comparação com outras implementações de conceito semelhante, posso responder nas perguntas.

Por que um orquestrador singleton, por que o sauron foi separado como um agente à parte, como foram definidas as heurísticas de tiering de modelos, ...

Se tiver alguma curiosidade, deixem nos comentários.
Feedback inicial é o que mais quero receber.

1 comentários

 
moderator 2026-04-19

Foi movido para o Show GN.
A propósito, posts cujo moderador ajustou a categoria podem ter a exibição na página inicial limitada, então pedimos que verifique a categoria mais uma vez antes de publicar.