📝 /commit - Commit Inteligente com IA
O comando /commit analisa todas as mudancas no seu repositorio (staged e unstaged), entende o que foi alterado e gera automaticamente uma mensagem de commit descritiva. Nao e um resumo generico: o Claude le o diff real, entende o contexto das mudancas e escreve uma mensagem que descreve o "por que" da mudanca, nao apenas o "o que".
🎯 Conceito Principal
O /commit nao e apenas um atalho para git commit -m "...". Ele executa um pipeline completo: roda git status, analisa o git diff, verifica o historico recente de commits para manter consistencia de estilo, e gera uma mensagem que segue as convencoes do repositorio.
- • Analise de diff real: O Claude le cada linha alterada, entende a intencao da mudanca e gera uma mensagem que captura o proposito, nao apenas lista arquivos
- • Convencoes automaticas: Se o repositorio ja usa Conventional Commits (feat:, fix:, refactor:), o Claude detecta e segue o mesmo padrao
- • Revisao antes de confirmar: A mensagem gerada e apresentada para voce aprovar, editar ou rejeitar antes do commit ser executado
- • Co-authored-by: Adiciona automaticamente uma tag de co-autoria do Claude na mensagem de commit, mantendo rastreabilidade
📊 O Que o /commit Faz Por Baixo
- git status - Identifica arquivos modificados, novos e deletados (staged e unstaged)
- git diff - Le o conteudo exato das mudancas para entender o contexto
- git log - Verifica os ultimos commits para seguir o estilo de mensagens do projeto
- Staging inteligente - Se ha arquivos unstaged, o Claude pergunta quais voce quer incluir
- Protecao - Nunca comita arquivos sensiveis (.env, credentials) sem aviso explicito
💡 Dica Pratica
O /commit gera mensagens drasticamente melhores quando as mudancas sao atomicas. Se voce fez 5 coisas diferentes no mesmo batch de arquivos, a mensagem vai tentar cobrir tudo e ficar generica. Prefira commitar mudancas relacionadas juntas:
Primeiro implemente a feature, rode /commit. Depois faca o fix de estilo, rode /commit de novo. Dois commits claros valem mais que um commit confuso. O Claude entende cada mudanca isolada com muito mais precisao.
✓ O que FAZER
- ✓ Fazer mudancas atomicas antes de rodar /commit
- ✓ Revisar a mensagem gerada antes de confirmar
- ✓ Deixar o Claude detectar e seguir as convencoes do repo
✗ O que NAO fazer
- ✗ Acumular dezenas de mudancas nao-relacionadas e rodar /commit
- ✗ Aceitar a mensagem sem ler (pode haver imprecisoes)
- ✗ Comitar arquivos .env ou credenciais sem verificar o staging
🔍 /review - Code Review Automatico
O /review executa um code review completo das mudancas atuais, analisando por camadas: seguranca, bugs, performance e qualidade de codigo. Funciona como ter um reviewer senior olhando seu diff antes de voce commitar. Cada problema encontrado e classificado por severidade para que voce saiba exatamente onde focar.
🎯 Conceito Principal
O /review nao e um linter. Ele entende semantica. Enquanto um linter verifica regras sintaticas (identacao, ponto-e-virgula), o /review entende o que o codigo faz e identifica problemas logicos, vulnerabilidades de seguranca, gargalos de performance e padroes que vao causar dor de cabeca em manutencao.
- • Camada 1 - Seguranca: SQL injection, XSS, secrets expostos, autenticacao bypass, inputs nao-sanitizados, permissoes excessivas
- • Camada 2 - Bugs: Null pointer exceptions, race conditions, off-by-one errors, edge cases nao tratados, estados impossiveis
- • Camada 3 - Performance: N+1 queries, loops desnecessarios, alocacoes excessivas, falta de caching, re-renders evitaveis
- • Camada 4 - Qualidade: Nomes pouco claros, funcoes grandes demais, falta de tratamento de erros, duplicacao de logica
📊 Classificacao de Severidade
- Critical - Problemas que devem ser corrigidos antes de qualquer merge. Vulnerabilidades de seguranca, bugs que causam perda de dados, crashes em producao
- Important - Problemas que afetam qualidade significativamente. Performance degradada, logica de negocio incorreta, tratamento de erro insuficiente
- Minor - Sugestoes de melhoria. Nomes melhores, simplificacao de logica, oportunidades de refactoring, documentacao ausente
💡 Dica Pratica
Adote a regra: nunca rode /commit em codigo de producao sem antes rodar /review. O custo de tokens do review e insignificante comparado ao custo de um bug em producao. O /review pega coisas que voce nao ve porque esta imerso no codigo.
Depois de receber o review, voce pode pedir ao Claude para corrigir os problemas identificados diretamente. Diga algo como "corrija os problemas Critical e Important do review" e ele aplica os fixes automaticamente. Depois rode /review novamente para confirmar que tudo foi resolvido.
✓ O que FAZER
- ✓ Rodar /review antes de todo /commit em codigo de producao
- ✓ Focar primeiro nos itens Critical, depois Important
- ✓ Pedir ao Claude para corrigir os problemas encontrados
✗ O que NAO fazer
- ✗ Ignorar itens Critical porque "funciona no meu ambiente"
- ✗ Usar /review como substituto para testes automatizados
- ✗ Achar que um review limpo significa zero bugs (e uma camada, nao a unica)
🚀 /pr - Pull Request Instantaneo
O /pr analisa todos os commits da sua branch atual, gera um titulo conciso e uma descricao formatada com Summary e Test Plan, e cria o Pull Request no GitHub automaticamente via gh CLI. O que antes levava 5-10 minutos escrevendo descricao e formatando, agora leva segundos.
🎯 Conceito Principal
O /pr nao e um wrapper simples do gh pr create. Ele analisa todo o historico de commits da branch desde que ela divergiu da branch base, entende o conjunto completo de mudancas, e gera uma descricao que cobre tudo de forma coerente.
- • Analise completa: Le todos os commits da branch, nao apenas o ultimo. Entende a narrativa das mudancas como um todo
- • Titulo curto: Gera um titulo com menos de 70 caracteres que captura a essencia da mudanca
- • Summary + Test Plan: A descricao segue um formato padrao com bullet points do que mudou e um checklist de como testar
- • Criacao automatica: Push da branch e criacao do PR acontecem em sequencia, sem interacao manual com o GitHub
Fluxo Ideal de PR
/review
Antes de tudo
Rode o review para identificar e corrigir problemas. Nao abra PR com issues Critical pendentes.
/commit
Commits limpos
Garanta que todas as mudancas estao commitadas com mensagens claras. O /pr usa o historico de commits para gerar a descricao.
/pr
Pull Request pronto
O Claude analisa os commits, gera titulo e body, faz push da branch e cria o PR no GitHub. Voce recebe a URL do PR na resposta.
⚠️ Pre-requisito
O /pr requer o GitHub CLI (gh) instalado e autenticado. Rode gh auth status para verificar. Se nao estiver configurado, rode gh auth login primeiro. Sem o gh CLI autenticado, o /pr vai falhar ao tentar criar o PR.
💡 Dica Pratica
Quanto melhores forem suas mensagens de commit, melhor sera a descricao do PR. O /pr usa os commits como fonte primaria de informacao. Se voce usou /commit para gerar mensagens descritivas ao longo do desenvolvimento, o PR praticamente se escreve sozinho.
O formato padrao gerado inclui ## Summary com bullet points das mudancas e ## Test plan com checklist de verificacao. Voce pode personalizar pedindo ao Claude para adicionar secoes especificas antes de criar o PR.
✓ O que FAZER
- ✓ Seguir o fluxo /review > /commit > /pr em sequencia
- ✓ Verificar que gh CLI esta autenticado antes de usar /pr
- ✓ Revisar o titulo e body gerados antes de confirmar a criacao
✗ O que NAO fazer
- ✗ Criar PR com mudancas nao-commitadas (o /pr nao ve uncommitted changes)
- ✗ Pular o /review antes do /pr em codigo de producao
- ✗ Usar /pr sem verificar em qual branch voce esta
🏗️ /init - Inicializacao do Projeto
O /init gera automaticamente um arquivo CLAUDE.md para o seu projeto. O Claude explora a estrutura de pastas, identifica a stack tecnologica, descobre comandos de build/test, detecta convencoes de codigo e cria um arquivo de memoria do projeto que sera carregado em todas as sessoes futuras.
🎯 Conceito Principal
O CLAUDE.md e o equivalente a dar ao Claude um "manual do projeto". Sem ele, cada sessao nova comeca do zero - o Claude precisa re-descobrir a stack, as convencoes e os padroes. Com o CLAUDE.md, ele ja entra sabendo como o projeto funciona.
- • Exploracao automatica: O Claude navega pelos arquivos do projeto, le package.json, Makefile, Dockerfile, configs e entende a stack
- • Deteccao de convencoes: Identifica padroes de nomeacao, estrutura de pastas, estilo de codigo e frameworks em uso
- • Comandos uteis: Descobre como rodar testes, build, lint, deploy e outros comandos do projeto
- • Persistencia: O CLAUDE.md e carregado automaticamente em toda sessao do Claude Code naquele diretorio
📊 O Que o /init Detecta
- Linguagens e frameworks: TypeScript, React, Node.js, Python, Go, Rust e suas respectivas configs
- Gerenciadores de pacotes: npm, yarn, pnpm, pip, cargo e seus lockfiles
- Scripts de build/test: Scripts do package.json, Makefile targets, docker-compose services
- Estrutura de pastas: src/, lib/, tests/, docs/ e como o codigo esta organizado
- Configuracoes: ESLint, Prettier, tsconfig, .env.example e outras configs
💡 Dica Pratica
O /init gera um bom ponto de partida, mas voce deve revisar e personalizar o resultado. Adicione regras especificas que so voce sabe: "nunca usar ORM X", "sempre usar o pattern Y para endpoints", "testes devem cobrir cenarios A, B e C". Quanto mais contexto voce adicionar ao CLAUDE.md, melhores serao todas as sessoes futuras.
Voce pode ter CLAUDE.md em diferentes niveis: na raiz do projeto (regras do projeto), no diretorio home (regras globais), e em subdiretorios (regras especificas de modulo). Todos sao carregados e combinados.
✓ O que FAZER
- ✓ Rodar /init assim que comecar a usar Claude Code em um projeto
- ✓ Revisar e enriquecer o CLAUDE.md gerado com suas preferencias
- ✓ Commitar o CLAUDE.md no repositorio para compartilhar com o time
✗ O que NAO fazer
- ✗ Aceitar o CLAUDE.md gerado sem ler (pode conter imprecisoes)
- ✗ Colocar secrets ou tokens no CLAUDE.md (ele vai para o git)
- ✗ Trabalhar em projetos sem CLAUDE.md (sessoes comecam do zero toda vez)
🩺 /doctor - Diagnostico do Ambiente
O /doctor executa um checklist automatico de diagnostico na sua instalacao do Claude Code. Verifica versao, autenticacao, status dos MCPs, permissoes de acesso, dependencias e configuracoes. Quando algo para de funcionar e voce nao sabe por que, o /doctor e o primeiro comando que voce deve rodar.
🎯 Conceito Principal
O /doctor funciona como um mecanico automatizado. Ele roda uma serie de verificacoes e, para cada problema encontrado, aponta a causa provavel e sugere o comando ou acao para corrigir. Nao e um diagnostico generico: ele e especifico para o seu ambiente.
- • Versao do Claude Code: Verifica se voce esta na versao mais recente e sugere atualizacao se nao estiver
- • Autenticacao: Confirma que sua sessao esta autenticada corretamente com a API da Anthropic
- • MCPs: Testa cada MCP server configurado, verifica se esta respondendo e identifica falhas de conexao
- • Permissoes: Verifica permissoes de leitura/escrita nos diretorios necessarios
- • Dependencias: Checa se Node.js, git, gh CLI e outras dependencias estao instaladas e acessiveis
🔍 Problemas Comuns que o /doctor Detecta
- MCP desconectado: Um MCP server crashou silenciosamente. O /doctor identifica qual e sugere reiniciar
- Versao desatualizada: Voce esta usando uma versao antiga que nao tem features ou fixes importantes
- Autenticacao expirada: O token de API expirou ou foi revogado. O /doctor aponta e sugere re-autenticacao
- Permissoes insuficientes: O Claude Code nao consegue ler/escrever em diretorios necessarios
- Dependencia ausente: Uma ferramenta necessaria (git, node, gh) nao esta no PATH ou nao esta instalada
💡 Dica Pratica
Rode /doctor sempre que alguma integracao parar de funcionar inesperadamente. Antes de tentar reinstalar, reconfigurar ou pesquisar no Google, o /doctor provavelmente vai identificar o problema e te dar a solucao em segundos.
Tambem e util rodar /doctor periodicamente como manutencao preventiva. Problemas pequenos (como um MCP que falha intermitentemente) podem ser detectados e resolvidos antes de causar interrupcoes no seu workflow.
✓ O que FAZER
- ✓ Rodar /doctor como primeiro passo de qualquer troubleshooting
- ✓ Seguir as sugestoes de correcao que o /doctor fornece
- ✓ Usar periodicamente como manutencao preventiva
✗ O que NAO fazer
- ✗ Reinstalar o Claude Code antes de rodar /doctor
- ✗ Ignorar warnings do /doctor (problemas pequenos crescem)
- ✗ Tentar debugar MCPs manualmente sem primeiro consultar /doctor
🔗 Fluxo Completo com Slash Commands
Cada slash command individual resolve um problema especifico. Mas o poder real aparece quando voce os encadeia em um pipeline de producao. O fluxo padrao /init > desenvolver > /review > /commit > /pr transforma seu workflow de desenvolvimento em um sistema onde cada passo agrega qualidade automaticamente.
🎯 O Pipeline de Producao
Pense nos slash commands nao como comandos isolados, mas como etapas de uma linha de producao. Cada etapa recebe o output da anterior e agrega valor. O resultado final e codigo revisado, bem documentado, com commits claros e PRs profissionais.
- • /init (uma vez): Cria o CLAUDE.md do projeto. Todas as sessoes futuras comecam com contexto. Faca isso no primeiro dia e nunca mais comece do zero
- • Desenvolvimento: Implemente a feature ou fix normalmente com o Claude. Use os comandos do Modulo 1.1 (/cost, /compact, /clear) para gerenciar a sessao
- • /review: Revisa tudo antes de commitar. Corrige Critical e Important. Garante qualidade antes do commit
- • /commit: Gera mensagem descritiva que captura o "por que" da mudanca. Commits atomicos e claros
- • /pr: Cria o PR com descricao completa, Summary e Test Plan. Push e criacao em um unico passo
Pipeline em Acao: Exemplo Real
Inicializacao (uma unica vez)
Primeiro dia no projeto
Rode /init na raiz do projeto. Revise o CLAUDE.md gerado, adicione suas regras e preferencias, commite no repo. A partir de agora, toda sessao do Claude Code neste projeto carrega esse contexto.
Desenvolvimento
Trabalhando na feature/fix
Escreva codigo, debugue, refatore. Use os comandos do Modulo 1.1 para gerenciar a sessao: /cost para monitorar, /compact quando necessario, /clear para foco.
Review + Commit + PR
Finalizacao em 3 comandos
Rode /review, corrija issues. Rode /commit, confirme a mensagem. Rode /pr, receba a URL. Tres comandos e o trabalho esta entregue com qualidade profissional.
Troubleshooting (quando necessario)
Algo deu errado
Se qualquer passo falha, rode /doctor para diagnosticar. O /doctor identifica problemas de configuracao, MCPs falhando, autenticacao expirada e outros problemas do ambiente que podem impedir os outros comandos de funcionar.
💡 Dica Pratica
A sequencia /review > /commit > /pr deveria se tornar tao automatica quanto salvar um arquivo. Com o tempo, voce internaliza o fluxo e ele leva menos de 2 minutos do inicio ao PR criado. Compare isso com os 15-20 minutos de escrever mensagem de commit, revisar mentalmente, escrever descricao do PR e navegar pela interface do GitHub.
Cada passo do pipeline tambem funciona isoladamente. Voce pode usar /review sem /commit, ou /commit sem /pr. O pipeline completo e o ideal, mas cada comando ja agrega valor individualmente. Comece usando um por vez e va adicionando os outros conforme se sentir confortavel.
✓ O que FAZER
- ✓ Internalizar o pipeline /review > /commit > /pr como habito
- ✓ Usar /init no primeiro dia e manter o CLAUDE.md atualizado
- ✓ Combinar com os comandos do Modulo 1.1 para sessoes completas
✗ O que NAO fazer
- ✗ Pular o /review achando que seu codigo nao precisa de revisao
- ✗ Tentar memorizar o pipeline em vez de pratica-lo gradualmente
- ✗ Abandonar o pipeline quando um passo falha (use /doctor e tente novamente)
📋 Resumo do Modulo
Modulo Anterior:
1.1 - Comandos Essenciais do Terminal
Proximo Modulo:
1.3 - Flags de Linha de Comando