4
wildrik
2 min de leitura ·

Testei os 'códigos secretos' do Claude Code na pratica, o que realmente aprendi?!

Vi alguns posts girando nas redes sociais essa semana: "5 códigos secretos do Claude Code" — /L99, /godmode, /ghost e afins. Então resolvi testar. Resumo honesto primeiro, prático depois.

A real sobre os "códigos secretos"

Não são comandos nativos, são convenções de prompt — palavras que você digita para dar contexto ao modelo. Não existe "código secreto":

  • /L99 → "responda em nível de especialista, sem simplificar"
  • /godmode → resposta mais completa e direta
  • /ghost → tom mais natural (não dribla detector de IA)

Funcionam como atalho mental, o detalhe é que dá pra transformar cada um num comando real — e é aí que o Claude Code mostra a sua utilidade!

Os recursos nativos que quase ninguém usa

Esses são oficiais e documentados, cada um tem a sua função à parte, mas quando a gente une todos eles, aí sim a brincadeira fica legal!

  1. Slash commands customizados — cria um /godmode real, num arquivo em .claude/commands/, reutilizável e versionado.
  2. Skills — comandos que carregam contexto sob demanda, sem inchar o prompt.
  3. Output styles — o "/godmode" honesto e permanente: você define o estilo uma vez, não repete instrução.
  4. Hooks que bloqueiam — não pedem permissão, barram a ação. Ex: proibir git commit na main, rodar lint antes de salvar.
  5. Permissions as code — trava exatamente o que o agente pode tocar, no repo.
  6. Headless orquestrado — claude -p como peça de pipeline / CI, não sessão interativa.
  7. Subagents — cada um com modelo e memória próprios, rodando em paralelo.
  8. MCP versionado no repo + resources (ferramentas do time, não da sua máquina).
  9. Checkpoints e /rewind — rede de segurança pra desfazer o que o agente mexeu.
  10. .claude/rules/ com paths — regra que carrega só na pasta que importa, não no projeto inteiro.

Junte slash command + skill + hook + subagent e você tem um agente configurado no próprio repositório — reproduzível pra qualquer um que clonar o repo.

O ponto é esse: pare de procurar código secreto — os recursos reais já estão na doc e quase ninguém utiliza da forma correta, esrevi um artigo detalhando melhor como utilizei os recursos disponíveis, com os exemplos práticos pra copiar e colar, documentei tudo aqui.

Alguém aqui já montou um fluxo avançado com subagents + hooks e skills? Curioso para conhecer os setups utilizados!

Carregando publicação patrocinada...
4

Meus 2 cents,

Parabens pelo post !

Tem varios detalhes que voce colocou que sao interessantes: p.ex rules com paths - tenho usado um script que muda o harness conforme o tipo de acao que estou fazendo (plan, front, back, manutencao, banco), que nao eh exatamente a mesma coisa da eh uma ideia.

Obrigado por compartilhar !

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

4

Respondendo sua pergunta do final, o que mudou o jogo aqui não foi juntar os 10, foi entender que existe hierarquia entre eles.

Hook está no topo, porque é o único da lista que não é sugestão. Skill e CLAUDE.md são instrução, e instrução tem adesão menor que 100%. Hook é código e roda sempre. Os dois que pagaram o próprio custo: um PreToolUse que reescreve comando de terminal para uma versão de saída compactada (menos token gasto em output de ferramenta é mais janela para o problema real), e um bloqueio de tudo que toca produção. A diferença entre "pedi cuidado no CLAUDE.md" e "barrei a ação" só aparece uma vez, e você não quer descobrir qual das duas tinha.

Sobre skill vs slash command, a distinção que decide o setup: slash command quem dispara é você, skill quem dispara é o modelo, pela description. Se você precisa lembrar de digitar, vai esquecer justamente no dia que importa. O que se otimiza numa skill é a description, não o corpo. Corpo excelente com description ruim nunca é acionado.

E um contra a corrente sobre subagent: só compensa em trabalho amplo e paralelo onde eu quero a conclusão e não o dump de arquivos. Para review eu evito, porque verificação precisa do contexto do que foi decidido e por quê, e isso está no loop principal.

Sobre o /godmode: ele parece funcionar porque dá permissão pro modelo gastar mais raciocínio e não simplificar. Isso existe de verdade, só que é o nível de esforço de raciocínio mais o output style. Dois parâmetros documentados empacotados como cheat code.