O caminho da trilha 4: do conceito de skill (markdown chamável) ao build na prática, terminando nos agentes que decidem sozinhos e rodam sem você presente.
Mapa da trilha
Conteúdo detalhado
📦 Skills: Conceito & Anatomia
A skill é um workflow em markdown que você chama como slash command. Aqui: o que é, onde mora (.claude/skills), a anatomia do SKILL.md, como skills chamam tools, quando usar skill vs digitar, skills vs CLAUDE.md e como compartilhar/versionar.
Um arquivo markdown de instruções — conceitualmente a mesma coisa que um "workflow" (a camada W do WAT), só que guardado num diretório especial e exposto como slash command.
Para de reexplicar a mesma tarefa: o processo vira chamável e consistente.
Skill = workflow chamável; markdown; mesmo processo toda vez.
Cada skill vive em sua própria pasta dentro de .claude/skills, com um arquivo markdown que a define; aí ela aparece como um slash command (ex.: /draft-email).
É como o agente "descobre" a skill e a expõe para você invocar.
Uma pasta por skill; slash commands viraram skills; descoberta automática.
O SKILL.md define nome, descrição (quando acionar), argumentos esperados e instruções passo a passo.
A descrição é o que faz o agente saber QUANDO usar a skill; os argumentos são o que ele pede.
Nome; descrição-gatilho; argumentos; passos.
Uma skill ainda pode acionar tools (scripts Python: busca na web, raspagem, geração de documento) — o framework WAT permanece intacto por baixo.
Skill não é só texto: é um processo que executa trabalho real via tools.
Skill ≈ W; tools ≈ T; o agente decide quando rodar cada tool.
Use skill para workflows repetidos, quando a consistência importa, ou para instruções complexas/fáceis de esquecer. Para tarefa de uma frase ou experimento único, só digite — skill seria exagero.
Saber a hora de empacotar evita tanto o caos quanto o over-engineering.
Repetição → skill; one-off → digitar; consistência; compartilhar.
CLAUDE.md guarda só as regras de toda sessão (propósito, objetivo, framework); instruções por tarefa vão em skills, que carregam sob demanda só quando invocadas.
Jogar tudo no CLAUDE.md estoura a janela de contexto; skills economizam tokens.
Toda sessão vs sob demanda; 20-50 skills não incham; janela de contexto.
Como a skill é um arquivo na pasta do projeto, ela pode ser versionada no Git e compartilhada com o time — todo mundo ganha o mesmo processo confiável.
Skill battle-tested vira ativo da equipe, não conhecimento preso numa cabeça.
Arquivo = versionável; compartilhável; delegar-e-esquecer.
🔨 Construindo Skills na Prática
Mão na massa: pedir uma skill no formato oficial, construir e testar a skill "rascunhar e-mail" (/draft-email), invocar sem argumentos, reusar com contexto limpo, montar a skill "documento → slides", plugar uma skill de design pronta e montar a sua biblioteca de skills.
Você não precisa saber escrever skills: descreve o workflow (entradas, comportamento, onde salvar) e pede para o agente transformar num slash command seguindo o formato oficial.
Mesma mentalidade vibe coding: descreva o resultado, a IA gera a skill.
Formato oficial; Plan Mode; descrever entradas/saída.
O primeiro build: uma skill que recebe bullets, destinatário e tom e escreve um e-mail polido, conciso e sem enrolação, salvando na pasta temporária. Vira o slash command /draft-email.
É o exemplo canônico de skill reutilizável de ponta a ponta.
Argumentos (bullets/destinatário/tom); SKILL.md; pasta temporária.
Chamar o slash command sem passar dados faz o agente perguntar pelas entradas que faltam (destinatário, tom, bullets) antes de rodar.
A skill é robusta: nunca roda "no escuro"; coleta o necessário.
Coleta de inputs; argumentos faltantes; experiência guiada.
Para reusar, você limpa a conversa (/clear) e chama o slash command de novo com novas entradas — saída fresca e consistente, seguindo sempre as mesmas regras.
Contexto limpo = runs previsíveis; a skill garante o mesmo padrão.
Limpar entre usos; consistência; modificar é só pedir.
Uma segunda skill que lê um documento, extrai os pontos-chave e cria uma apresentação profissional — usando tools Python por baixo.
Mostra a skill resumindo conteúdo longo num deck estruturado, reusável.
Resumir → estruturar; tools de geração; iterar design.
Plugar uma skill de design já existente faz a qualidade visual subir sem você precisar descrever cada detalhe de design manualmente.
Skills se compõem: você empilha uma skill de design por cima do seu workflow.
Composição de skills; design skill; reuso de conhecimento pronto.
Um catálogo de ideias de skill prontas para você montar: notas → ações, dados → PDF, e-mail, resumo de reunião, brief de pesquisa.
Te dá pontos de partida concretos para construir a sua própria biblioteca.
Catálogo; skills battle-tested; salvar o que funciona.
🤖 Agentes: Locais, Agendados & por Evento
O salto para sistemas que decidem sozinhos: o que é um agente (raciocina, adapta, se auto-cura), agente local sob demanda, o loop de auto-melhoria, agente agendado (cron), agente por evento (webhook), o agentic gap, projetar para produção desde o 1º prompt, e quando um "agente" é só um script.
Diferente da automação tradicional (você liga cada passo), um agente recebe o resultado desejado e raciocina, adapta, faz perguntas e se auto-cura quando algo quebra.
É a fronteira entre "wire tudo na mão" e "diga o resultado".
Raciocina; adapta; auto-cura; não-determinístico.
O assistente como agente pessoal: pesquisa, monta arquivos, itera na saída e fica mais esperto a cada uso — tudo rodando local, sem deploy.
É a forma mais simples de agente; constrói intuição antes da nuvem.
Local; sob demanda; você assiste e aprende.
O agente roda um workflow, bate num erro, diagnostica, conserta a tool e atualiza o workflow para o erro não voltar — runs ficam mais suaves e rápidos.
É o superpoder dos agentes locais — e exatamente o que some em produção.
Errar → consertar → atualizar; aprender com a falha; persistir o fix.
Um agente que roda sozinho na hora marcada por um padrão cron (5 campos; ex.: 0 7 * * * = 7h todo dia) — pesquisa, sintetiza e grava o resultado, sem você presente.
É a primeira forma de agente que escala além de "quando você aparece".
Cron (5 campos); roda unattended; agenda.
Um agente que acorda quando um webhook (uma URL que escuta dados) é chamado, recebendo um payload — uma "campainha digital" que dispara o trabalho.
É como um formulário, um app ou outro sistema dispara o seu agente.
Webhook = campainha; payload; auth Bearer.
Quando o agente roda na nuvem por agenda/evento, o assistente não está mais olhando para se auto-curar: o sistema roda mas não adapta sozinho — e uma falha pode passar despercebida.
É o risco central de produção; define como você projeta o agente.
Sem auto-cura; falha silenciosa; logs e alertas fecham o gap.
As quatro exigências do build unattended: inputs fixos, saída estruturada/previsível, tratamento de erro embutido e log em cada passo — tudo desde o 1º prompt.
Como o agente não vai se auto-curar, você projeta a robustez de saída.
Inputs fixos; saída estruturada; try/catch; logar tudo.
Nem todo automação precisa de raciocínio: se a tarefa é fixa e previsível, um script determinístico é mais barato e confiável que um agente — e isso é uma escolha válida.
Saber a diferença evita pagar por inteligência que você não precisa.
Determinístico vs agêntico; "boring is beautiful"; custo vs adaptação.