Conteúdo detalhado
⚡ Slash commands: atalhos que economizam tempo
Você digita / e uma lista de ações aparece na hora. São os slash commands — a forma mais barata de controlar o estado da sua sessão. Dois são indispensáveis daqui pra frente: /context mostra quanto da janela de contexto já foi usada, e /clear zera a conversa e começa do zero.
Ações rápidas embutidas no Claude Code, disparadas ao digitar /. Pense em atalhos de teclado, mas em texto.
São a maneira mais barata de gerenciar a sessão. Saber o que ocupa espaço e quando zerar evita queda de qualidade.
/clear = abrir uma aba nova (contexto fresco) · comandos personalizados · skills viram comandos ao serem instaladas.
Os dois comandos que você mais vai usar neste módulo
/context # quanto da janela já foi consumido /clear # zera a conversa — igual a abrir uma aba nova / # abre a lista de todos os comandos disponíveis
💡 Dica prática
Várias skills aparecem como slash commands quando instaladas. Quando estiver na dúvida sobre o que tem disponível, digite só / e role a lista — é o seu "menu" da sessão.
🧠 Contexto e tokens: o penhasco invisível
Toda conversa tem um penhasco. Quanto mais longa, pior o desempenho — fenômeno chamado context rot. É o erro nº 1 de iniciante: usar a mesma janela o dia inteiro. Gerenciar contexto é exatamente o que separa um resultado bom de um medíocre.
Context rot é a queda de desempenho conforme a conversa cresce. Mais histórico empilhado, mais o modelo se perde.
Contexto é um recurso finito. Quem o trata como descartável mantém a qualidade alta tarefa após tarefa.
Uma tarefa, uma janela · terminou, descarte (/clear) · /context para enxergar o consumo · modelo certo para a tarefa.
Abra e meça
Rode /context no começo para ver o uso atual da janela.
Faça uma tarefa focada
Uma tarefa pequena e bem delimitada. Não misture cinco assuntos na mesma janela.
Terminou? Descarte
Rode /clear antes de começar algo novo. Contexto fresco, qualidade preservada.
📊 Modelo certo para a tarefa certa
- •Nem tudo exige o modelo mais pesado — tarefas simples rodam bem em modelos mais leves.
- •Usar o modelo leve no que é simples poupa custo e escala melhor.
- •Guarde o modelo mais forte para o raciocínio difícil e a revisão crítica.
🎯 Skills: o caderno de receitas do especialista
Uma skill é um conjunto de instruções — um arquivo SKILL.md com nome, descrição e passo a passo — que o Claude carrega sozinho quando a tarefa combina. Sem skill, o modelo improvisa; com skill, ele segue uma receita testada e entrega sempre o mesmo padrão de qualidade.
Um procedimento reutilizável empacotado num SKILL.md. Peça "monte uma apresentação" e a skill de apresentação entra em ação sem você citá-la pelo nome.
Skills são "a ciência por trás do output". Toda tarefa que você repete vira candidata a skill — você codifica uma vez e colhe o padrão para sempre.
A skill é descoberta pela descrição (o gatilho) · confira o que existe digitando / + nome · três peças: nome, descrição, conteúdo.
✓ Skill bem feita
- ✓Descrição clara do quando usar — é o que faz a skill "acender" na hora certa.
- ✓Procedimento curto e direto, fácil de seguir.
- ✓Testada: você pede a tarefa e a skill dispara sozinha.
✗ Skill que não acende
- ✗Descrição vaga ou genérica — o Claude nunca sabe quando aplicar.
- ✗Passo a passo longo e confuso, cheio de exceção.
- ✗Nunca testada — você só descobre que não dispara na hora H.
Construir a sua skill do zero — peça assim
Vamos criar uma skill para padronizar meu resumo de reunião. Comece pela DESCRIÇÃO (quando ela deve ser usada), depois o passo a passo. Entregue como um SKILL.md pronto para revisar.
Indo mais fundo (opcional): a descrição é tudo
O Claude escolhe a skill lendo a descrição, não o corpo. Uma descrição genérica ("ajuda com textos") raramente dispara; uma específica ("use quando o usuário pedir um resumo de reunião com decisões e próximos passos") acende na hora certa. Capriche nela como se fosse o gatilho — porque é.
🔌 MCP: a tomada universal
O Model Context Protocol (MCP) é um padrão aberto que deixa o modelo conversar com APIs e serviços sem você escrever a integração. Uma API é um manual técnico que máquinas usam para falar com máquinas; o MCP é o adaptador padronizado por cima dela. Você não programa a "cola" — lista o servidor MCP e pede em português.
Um padrão aberto (anunciado pela Anthropic no fim de 2024) que dá ao Claude uma janela para suas ferramentas: e-mail, dados, scrapers, serviços.
Em vez de decorar endpoints e escrever código de integração, você conversa com a ferramenta. Hoje quase toda ferramenta séria tem um servidor MCP.
API = máquina-para-máquina · MCP = invólucro que expõe só o necessário · MCP local mantém sua chave na sua máquina, sem intermediário.
✓ Com MCP
- ✓Você pede em português: "puxe meus últimos e-mails não lidos".
- ✓A chave fica em variável de ambiente, nunca no chat.
- ✓Um padrão só serve para qualquer ferramenta com servidor MCP.
✗ Sem MCP (API crua)
- ✗Você decora endpoints e escreve a "cola" de integração na mão.
- ✗Risco de colar chave no lugar errado.
- ✗Cada serviço, um código diferente para manter.
Criar um MCP local (exemplo: serviço de vídeo) — peça assim
Quero criar um MCP local para [SERVIÇO]. A chave de API já está como variável de ambiente. Liste as funcionalidades disponíveis, escolha as mais úteis pro meu uso e crie o MCP local. No fim, explique como chamá-lo em conversa.
🔒 Chave nunca no chat
A chave de API mora em variável de ambiente local — nunca colada na conversa nem em arquivo versionado. Um MCP local roda direto na sua máquina e mantém a chave ali, longe de qualquer intermediário.
👥 Subagentes: delegar para terminar mais rápido
Em vez de um trabalhador fazendo tudo em sequência, você abre uma equipe. Subagentes são agentes disparados para tarefas separadas, cada um com sua própria janela de contexto. Trabalho independente roda em paralelo e termina antes.
A paralelização: vários agentes trabalhando ao mesmo tempo, cada um com contexto próprio.
Ótimo para pesquisa multi-ângulo e para quebrar um projeto em frentes. O que é independente termina mais cedo.
Delegue partes que não dependem uma da outra · cada subagente devolve só a conclusão (não o histórico bruto) · isso protege o seu contexto principal.
Divida em partes independentes
Quebre a tarefa em frentes que não dependem uma da outra (X, Y, Z).
Dispare os subagentes
"Crie três subagentes — um analisa X, outro Y, outro Z." Cada um devolve só as conclusões.
Recolha e consolide
Junte os resultados num quadro comparativo no agente principal.
Fan-out em paralelo — peça assim
Faça [TAREFA]. Crie três subagentes independentes: - subagente 1: analisa [ângulo X] - subagente 2: analisa [ângulo Y] - subagente 3: analisa [ângulo Z] Cada um devolve só as conclusões. Depois consolide num quadro comparativo.
🔁 Loop de crítica: um cria, outro revisa
"O Claude avalia o trabalho do Claude." Pedir para criar é uma coisa; pedir para revisar é outra completamente diferente — e melhora muito o resultado. A revisão automática pega erros que o autor não vê.
Um fluxo onde um agente cria o entregável e outro assume o papel de revisor crítico, apontando furos e devolvendo a versão corrigida.
Revisão pega o que o autor não enxerga. Você pode até usar um modelo diferente como revisor, trazendo um segundo ponto de vista.
Separe os papéis (autor x crítico) · peça a crítica de forma explícita · itere uma ou duas rodadas · outras CLIs de modelos podem entrar como revisores externos.
Mudar de papel para revisar — peça assim
Você acabou de criar [ENTREGÁVEL]. Agora mude de papel: seja um revisor crítico e rigoroso. Aponte furos, vieses e o que faltou. Em seguida entregue a versão final corrigida.
Indo mais fundo (opcional): por que separar os papéis funciona
Quando o mesmo agente cria e julga na mesma respirada, ele tende a defender o próprio rascunho. Ao pedir explicitamente "agora seja o crítico", você reseta a postura: o objetivo passa a ser achar problemas, não justificar escolhas. Uma ou duas rodadas costumam bastar — mais que isso vira rendimento decrescente.
Auto-checagem (opcional): qual é o melhor jeito de evitar o context rot?
🧪 Exemplo prático guiado: mini-pesquisa "onde morar"
Vamos juntar skills + subagentes + loop de crítica numa tarefa real — e ver a gestão de contexto na prática.
Sessão limpa
Rode /clear e depois /context para confirmar que está zerado.
Dispare subagentes
"Pesquise o melhor lugar para viver. Três subagentes: financeiro/tributário, qualidade de vida, clima e segurança. Cada um devolve só as conclusões."
Consolide
Quando os três voltarem, peça ao agente principal um quadro comparativo.
Loop de crítica
"Agora aja como revisor crítico: aponte furos, vieses e o que faltou. Depois entregue a versão final corrigida."
Verifique o contexto
Rode /context. Note o quanto a janela cresceu — e por que vai querer /clear antes da próxima tarefa.
✏️ Exercícios
1. Higiene de contexto (fácil)
Rode /context, faça uma tarefa curta, rode /context de novo e depois /clear. Critério: você sabe dizer quanto a tarefa consumiu e a janela volta ao zero após o /clear.
2. Usar uma skill pronta (médio)
Instale uma coleção de skills de fonte confiável, confirme uma skill com / + nome e use-a numa tarefa real. Critério: a skill aparece na lista e produz output no padrão dela.
3. Sua primeira skill (médio)
Crie uma skill para uma tarefa que você repete (ex.: padronizar resumo de reunião). Critério: ao pedir a tarefa, a skill é acionada e o resultado sai consistente.
4. MCP local (médio)
Conecte uma ferramenta que você usa via MCP (com a chave no ambiente). Critério: você chama a ferramenta em português, sem escrever endpoint, e a chave nunca apareceu no chat.
5. Crítico em paralelo (difícil)
Peça uma criação qualquer, depois dispare um subagente revisor para criticá-la e devolver a versão final. Critério: a versão final corrige pelo menos um problema apontado na crítica.
⌨️ Prompts prontos
Quatro instruções para acionar os power features. Use-as como ponto de partida e adapte ao seu caso. O banco completo está na Biblioteca → Prompts.
Verificar e limpar contexto
Antes de começarmos, me diga: o que está ocupando minha janela de contexto agora? Se passar de metade, sugira o que descartar. (equivalente a /context)
Criar uma skill do zero (canônico)
Quero criar uma skill para [TAREFA QUE REPITO]. Primeiro escreva a DESCRIÇÃO (quando esta skill deve ser usada). Depois o passo a passo que você deve seguir toda vez. Entregue como um SKILL.md pronto para eu revisar.
Original (EN):
I want to create a skill for [REPEATED TASK]. First write the DESCRIPTION (when this skill should trigger). Then the step-by-step you must follow every time. Output it as a ready-to-review SKILL.md.
Disparar subagentes em paralelo
Faça [TAREFA]. Crie três subagentes independentes: - subagente 1: analisa [ângulo X] - subagente 2: analisa [ângulo Y] - subagente 3: analisa [ângulo Z] Cada um devolve só as conclusões. Depois consolide num quadro comparativo.
Auditar uma skill de terceiros antes de instalar
Vou instalar esta skill de terceiros. Leia o SKILL.md, me diga em bullets o que ela executa, que acessos ela pede e qualquer sinal de risco. Só recomende usar se for seguro.
⚠️ Erros comuns
- ✗Usar a mesma janela o dia todo. Conversa longa = context rot = queda de qualidade. Uma tarefa por janela;
/clearao terminar. - ✗Instalar skill de fonte duvidosa. Skill é código que roda na sua máquina. Leia o
SKILL.mde instale só de fonte confiável. - ✗Colar chaves de API no chat. Chaves ficam em variáveis de ambiente locais, nunca no corpo da conversa nem em arquivos versionados.
- ✗Pular a revisão. Aceitar o primeiro rascunho sem um loop de crítica deixa erros passarem. Criar e revisar são passos diferentes.
- ✗Paralelizar tarefas dependentes. Subagentes brilham em trabalho independente. Se a parte B depende da A, rodar em paralelo só gera retrabalho.
✅ Resumo do módulo
/context mede, /clear zera; uma tarefa por janela vence o context rot.Checklist de conclusão
- ☐ Sei usar
/contexte/cleare entendo o que é context rot. - ☐ Instalei e usei uma skill pronta de fonte confiável.
- ☐ Criei pelo menos uma skill do zero (nome + descrição + passo a passo).
- ☐ Conectei uma ferramenta externa via MCP, com a chave no ambiente.
- ☐ Disparei subagentes em paralelo e consolidei os resultados.
- ☐ Rodei um loop de crítica (criar → revisar → versão final).
- ☐ Consigo escolher o modelo adequado para tarefas simples x complexas.
🎉 Fim da Trilha 1!
Você concluiu os Fundamentos. Próxima trilha: Construir — comece pelo módulo 2.1, do website do zero ao deploy.