Como criar uma skill no Claude Code em 6 passos (sem ser programador)

Uma skill no Claude Code é uma instrução reutilizável que você ensina uma vez para o seu agente de IA e ele passa a aplicar sozinho, sempre que reconhecer o contexto certo. Por baixo, uma skill é só uma pastinha com um arquivo SKILL.md dentro — mas você não precisa escrever esse arquivo na mão: o agente faz isso para você. Em vez de ficar explicando a mesma coisa toda vez, você cria a skill e o agente já sabe o que fazer. É como dar um manual permanente para um assistente que está sempre do seu lado.

Neste tutorial eu te mostro um método em 6 passos para você aprender a criar qualquer tipo de skill — e o ponto mais importante: o objetivo não é você baixar um pacote com as 10 ou 100 mil skills mais usadas. O objetivo é a sua independência. Essa busca por autonomia, em vez de dependência, é justamente um dos pilares do Método Prompthen, a forma de trabalhar com agentes de IA que eu venho organizando ao longo dos anos. Eu sou contra pegar coisa pronta, porque assim você não aprende. O caminho certo é aprender a criar as suas próprias skills, do jeito que a sua dor real pede.

A ideia central que eu repito em tudo o que ensino, e que está na base do Método Prompthen, é simples: você não precisa ser programador para usar IA. Trate o agente como um Einstein sentado do seu lado, com acesso a um computador. Você só precisa aprender a conversar com ele — de forma pausada, organizada e verificável — e participar do planejamento junto. Quem faz a maior parte do trabalho técnico é o próprio agente.

Para deixar concreto, neste vídeo eu crio uma skill de verdade junto com você: uma skill de leitura de screenshot. Com ela, sempre que eu colar uma URL de uma foto da tela (do Lightshot ou do Zight, por exemplo), o agente entende que é um screenshot, acessa o link, baixa a imagem, lê com a visão dele e me responde sobre o que viu — sem eu precisar explicar nada disso a cada vez.

Os 6 passos do método são:

1. Pegar uma skill de referência — a skill creator da Anthropic, que está no GitHub.
2. Separar o link dessa skill creator para usar daqui a pouco.
3. Inicializar o Claude e conversar — pedir para ele acessar o link e retornar as descobertas, sem criar nada ainda.
4. Salvar a skill creator como skill global no seu ambiente.
5. Criar a skill nova de verdade — no nosso caso, a skill de screenshot.
6. Finalizar e testar — pedir a opinião do agente, justificar escolhas em casos delicados, sair e reabrir o Claude e testar a skill funcionando.

Isso funciona no Claude Code, mas o conceito de skill é um padrão universal — então a mesma ideia vale para o Codex ou qualquer outra CLI de agente.

Transcrição da aula

Nesse vídeo eu vou te ensinar como você aprende a criar qualquer tipo de skill, tá? Porque a ideia é você ficar independente. Você não vai mais ter aquela necessidade de "ah, vou baixar um pacote com as 10 mil, 100 mil skills mais utilizadas". Eu vou te mostrar um método que eu uso, que funciona muito bem: você conversa com a IA, identifica a sua dor e cria qualquer tipo de skill a partir disso.

São só 6 etapas, então é bem fácil. A ideia é que qualquer um consiga aplicar. Eu deixei bem organizado em cada uma das etapas, e ao longo do texto a gente vai passar por todas elas.

A skill que eu escolhi criar aqui, na minha opinião, é muito útil: uma skill que entende o screenshot que você passa para o seu agente. Isso aqui funciona no Claude Code, mas funcionaria em Codex ou em qualquer outra CLI, né? Porque a skill é um padrão universal para IA.

A ideia é o seguinte: você faz a skill e o agente passa a entender aquela URL de screenshot que você está compartilhando. Eu coloquei dois exemplos aqui — o Zight e o Lightshot — mas pode ser qualquer ferramenta que você queira. Quando você compartilhar aquela URL, ele entende, acessa, baixa a imagem, lê e te dá uma resposta sobre aquilo. Porque senão, toda vez que você compartilha alguma coisa lá no Claude Code que é uma URL, você tem que ficar explicando: "olha, acessa, baixa o arquivo, leia o arquivo, entenda que eu estou te mandando uma foto da tela". A skill é justamente para isso: para ficar bem fácil.

O que é uma skill no Claude Code? É uma instrução reutilizável que você ensina uma vez ao agente e ele passa a aplicar sozinho sempre que reconhecer o contexto certo, sem você precisar repetir o pedido a cada vez.

E a etapa 6 vai ser a finalização. Então são só 6 etapas, é um processo bem tranquilo para te dar essa independência.

Seguindo a forma como eu gosto de explicar para as pessoas como usar agentes de IA para te potencializar: você não precisa ter nenhum grande conhecimento na área. Não precisa ter nenhuma instrução prévia de programação ou coisa assim. A maior parte das coisas que a gente vai fazer, quem vai fazer é o próprio agente de IA. Eu vou te ensinar a conversar com ele e a aplicar um método para deixar esse processo todo tranquilo.

Passo 1: pegar uma skill de referência (a skill creator da Anthropic)

A primeira coisa é pegar uma skill padrão. Eu sempre falo que sou contra você pegar prompt pronto, pegar coisa pronta — porque você não aprende. O ideal é que cada um consiga desenvolver, junto com agentes de IA, coisas que vão te multiplicar no seu dia a dia. Mas aqui nessa situação a gente vai pegar uma skill pronta de propósito: a skill creator.

Essa skill creator da Anthropic já tem, explicado para o agente, todo o protocolo de como se cria uma skill: se essa skill vai usar script, se vai ser só instrução ou se vai usar subagente. Se a gente fosse desenvolver uma skill para isso do zero, esse vídeo ficaria muito longo e a gente acabaria perdendo alguns protocolos de segurança e por aí vai. Então o melhor é a gente pegar essa skill juntos.

E, como eu falei, não é você que vai pegar, baixar, colocar em algum lugar. A gente vai falar para o agente de IA fazer isso. Mas eu estou mostrando aqui na tela de onde a gente vai catar essa informação, para vocês também se sentirem seguros de onde ela vem.

É o GitHub da Anthropic, a página de skills deles. Se você entrar no GitHub naquela URL da Anthropic e vier em "skills", tem várias skills deles. Algumas dessas eu uso para ter esse padrão de uso, mas eu não gosto de ficar pegando skill pronta porque geralmente a minha necessidade é um detalhezinho X.

Skill global x skill de projeto

Aqui já vale uma definição importante, porque eu uso os dois tipos. Eu devo ter mais de 30, 40 skills que uso, mas não são em todos os projetos:

• Skill global: como essa de screenshot que a gente vai fazer. Você chama ela de qualquer lugar, em qualquer projeto. Ela mora numa pasta única do seu Claude Code (a ~/.claude/skills). Screenshot você vai usar em tudo, então faz sentido ela ser global.
• Skill de projeto: às vezes você vai montar uma skill específica de um projeto X, específica de um cliente X. Aí ela fica numa pastinha isolada dentro daquele projeto (a .claude/skills), e só funciona ali.

Skill global é aquela que funciona em qualquer projeto que você abrir; skill de projeto é aquela que existe só dentro de um projeto ou cliente específico.

E aqui vem uma coisa que tira o medo de quem pensa "se eu tiver 40 skills, não vai ficar tudo pesado e confuso?". Não fica. O Claude não carrega todas as skills na cabeça dele o tempo todo — cada skill só entra na memória dele na hora em que é necessária, quando o contexto bate. Então você pode ter dezenas de skills guardadas que, no dia a dia, o agente só "puxa" a certa quando precisa. É por isso que dá para acumular skills sem peso nenhum.

Passo 2: separar o link da skill creator

Os passos 1 e 2 são extremamente simples. A skill creator que a gente vai pegar está nessa página da Anthropic, então é só pegar a URL.

Eu deixo dois links nos comentários do vídeo: uma primeira URL, da página geral de skills da Anthropic, e uma segunda URL que já vai direto para a skill creator. Essa segunda é a que importa para a gente — é a que vai direto para a skill creator. Então é só copiar esse link e deixar separado, que daqui a pouco a gente passa ele para o agente.

(Esse quadro que aparece na tela é o Prompthen Whiteboard v3 — uma ferramenta de arquivo único que eu fiz no próprio Claude Code para planejar e deixar as etapas das aulas visuais. Ainda está em construção, então tem coisa que não está tão maravilhosa assim, mas já ajuda a você acompanhar o passo a passo.)

Passo 3: inicializar o Claude e conversar ("vamos conversar, não crie nada")

A etapa 3 é o coração do método. Você vem aqui e inicializa o Claude. Como eu falei, isso também funciona em Codex, funciona em qualquer CLI, porque a skill é um padrão universal para IA.

Você abre o seu Claude e a primeira coisa é falar para ele que a gente vai conversar. Isso é importante. Quando você fala para o seu agente de IA que quer fazer alguma coisa, geralmente ele tem uma ansiedade. Isso é natural da IA: ela quer construir algo logo. Ela pega o que o usuário está falando e já quer entregar alguma coisa, porque o agente de IA sempre tenta completar a missão — e a missão dele é o que você está pedindo. Ele sempre quer cumprir os objetivos.

Conter a ansiedade da IA é dizer ao agente "vamos conversar, não crie nada ainda" antes de pedir a execução, para ter uma conversa fluida e um bom planejamento antes que ele saia construindo. É uma das técnicas que eu mais uso no Método Prompthen.

Então uma forma de conter essa ansiedade é falar para ele: "vamos conversar, não crie nada". E aí a gente continua: "por favor, acesse o link que eu vou fornecer na próxima mensagem".

Veja que isso é intencional — você não coloca tudo numa mensagem só. É importante pensar assim: o agente de IA é como se ele estivesse sentado do seu lado, como se fosse uma pessoa, e que tem acesso a um computador. Essa é a grande diferença de você ter um Claude Code, um Claude que está lá na máquina: o uso dele é infinitamente melhor do que na web, porque é como se fosse uma pessoa do seu lado — um Einsteinzinho, um gênio com acesso a um computador, que pode fazer tudo.

Então você vai conversar com ele como se ele tivesse aqui do seu lado. Se você tivesse uma pessoa do seu lado, você não ia vomitar todas as informações de uma vez só. Você ia falar de forma pausada, organizada, verificável, ver se ela entendeu, montar o planejamento junto.

Um dos grandes segredos para ter bom resultado com agentes de IA é conversar com calma e participar do planejamento junto com o agente, em vez de despejar tudo de uma vez.

A primeira mensagem: leia e retorne as descobertas

A primeira mensagem é a conversa. Depois a gente fornece o link. Eu não fico copiando e colando exatamente todas as palavras — algumas eu escrevo na hora. Faça da forma que você achar melhor, porque não precisa ser cada palavra exata. A ideia não é você ter os prompts decorados. Inclusive, se você quer entender melhor as coisas, pause o vídeo e entenda, para você poder escrever do seu jeito. Eu não acho bom ficar de copia e cola de prompt; aqui eu copio e colo só para ser mais dinâmico.

Então a mensagem é mais ou menos assim, numa linguagem natural:

Vamos conversar, não crie nada. Você vai acessar o link que eu vou te dar.

Acesse o link abaixo. É uma skill que cria skills. Leia e compreenda
tudo nela e retorne as descobertas.

<cola aqui a URL da skill creator>

E outra coisa: não se preocupe se você escrever um pouco errado, esquecer um acento, colocar uma palavra torta. Hoje em dia a IA é tão inteligente que ela vai entender o que você quer dizer.

Como se tivesse uma pessoa do seu lado, você falou: "tá aqui o material, acessa lá e me diz o que você entendeu". Aí ela vai ler esse material. Por ser uma URL de uma skill e uma página do GitHub, ele consegue compreender rapidinho como funciona — ele já sabe como catar as coisas por lá e vai pegar tudo o que for necessário.

Esse pedido de "leia primeiro e retorne o que entendeu" faz parte da mesma lógica: conter a ansiedade da IA e ter uma conversa fluida para as coisas funcionarem bem.

Passo 4: salvar a skill creator como skill global

Enquanto ele lê, a gente já prepara a próxima etapa. Ele vai falar que o arquivo foi baixado e que vai ler — é aquele arquivo .md (Markdown). Assim que ele terminar, a gente vai pedir para ele salvar essa skill.

Todo esse conhecimento que ele acabou de adquirir — por isso eu falei "retorne as descobertas" — a gente vai pedir para ele transformar numa skill global. Porque a gente quer duplicar essa skill creator, quer que ela fique salva no ambiente. Mas eu mandei ele ler primeiro.

Por que salvar, em vez de já criar a skill nova? Porque a gente poderia, sim, a partir desse momento, mandar ele criar uma skill nova qualquer. Porém, essa informação que ele acabou de adquirir lendo a skill creator ficaria perdida — só na memória de texto da sessão. Salvando como skill global, esse conhecimento fica permanente no ambiente.

Skill só de instrução x skill com script x skill com subagente

Aqui entra um conceito importante. Não tem pressa, e isso só vai entrar depois que ele terminar tudo. Uma skill pode ter formatos diferentes:

• Skill só de instrução: por exemplo, "quero que você formate um texto num determinado padrão, sempre com um cabeçalho no início, depois uma instrução embaixo, fazendo determinadas verificações". Isso é só um arquivo .md lá dentro.
• Skill com script: quando você quer algo mais complexo, às vezes vai ter um script (em Python, por exemplo).
• Skill com subagente: às vezes a skill amarra um subagente específico para rodar junto.

Existem três formatos básicos de skill: só instrução (um arquivo .md), instrução com script, e instrução com script e subagente.

E o melhor: todas essas regras — quando vai ter script, quando não vai, o que usar — estão dentro da própria skill creator. Por isso a gente manda ele criar a nossa skill: assim, quando você for conversar com ele, ele já tem todo esse conhecimento para saber o que vai usar. Você não precisa falar "use um script, use isso, não use aquilo". Ele mesmo vai entender.

Mandando criar a skill global

Então ele aguardou, finalizou, compreendeu. A mensagem que a gente dá é mais ou menos:

A leitura dessa skill está sendo feita porque a gente vai criar uma
skill nossa neste ambiente. Leia tudo.

Agora crie uma skill chamada skill creator, e essa skill vai ser global.

Sendo uma skill global, você roda ela em qualquer lugar, em qualquer projeto. Aqui eu tenho uma pastinha que criei para fazer esses vídeos/aulas, que não tem nada dentro. Mas quando você abrir o seu Claude Code em qualquer projeto, a skill global você chama de qualquer lugar.

Por ser do GitHub, existe uma grande chance de ele pegar aquela skill inteira do GitHub, baixar e colocar na pasta global. Pode ser que ele faça isso, e estaria super certo — porque a gente não precisa ficar personalizando a skill creator. A Anthropic, que criou, já colocou todos os protocolos ali. Por isso esse é um dos raros copia e cola que você vai me ver fazer em qualquer lugar.

E aqui vem uma regra que eu sempre sigo: depois que a gente cria a skill, sempre saio e entro de volta. O Claude Code nas versões atuais já faz um reload da skill quando você muda, mas eu gosto de sair e entrar de novo para ter garantia — principalmente quem usa alguma modificação em cache, prompt e tal, como eu uso.

As perguntas que ele pode fazer no caminho

No meu caso, eu já tinha uma skill creator antiga aqui (esqueci de tirar, mas não tem problema). Ele percebeu, falou que era uma versão antiga e me fez algumas perguntas. Vou responder elas só porque alguém de vocês pode passar pelo mesmo:

• Já existe uma skill creator antiga, como tratar? As opções eram tipo "mesclar o melhor dos dois", "substituir limpo", "substituir sem backup". Se aparecer para você, pode mesclar e manter a lógica, sem problema.
• Qual o nível de adaptação ao ambiente? Aqui eu uso o Claude Code num VPS meu, num Debian, porque às vezes uso no Mac, às vezes no celular, no iPad, no Windows — então acesso o Claude remoto. Mas isso para você não faz diferença nenhuma: provavelmente você tem o Claude Code instalado na máquina mesmo. Eu só pedi para ele mesclar e manter a lógica.

Se você já tem uma skill creator, pode atualizar, sim — porque pode ser que a versão oficial tenha tido alguma boa ideia. Por exemplo, a versão oficial tinha uma questão de "agents" que a minha não tinha, e a minha tinha outras duas que a oficial não tinha. Não tem problema juntar. A única utilidade dessa skill creator é ensinar o agente de IA como ele deve criar uma skill — só isso, nada mais. Se no GitHub tem informação atualizada, seguimos.

Ele encontra um bug — e isso é ótimo

No meio do processo ele faz modificações e, em determinado momento, ele mesmo achou um bug e corrigiu. Ele falou ali algo como "ainda bem que testei, em vez de assumir que deve funcionar". Isso é por causa de instruções que eu tenho lá na base do meu ambiente — instruções úteis tipo: evite deduções, proibido preguiça, pense e planeje cem vezes antes de agir, para agir uma vez só certa, evite cortar as pernas. São coisas que fazem o agente não te entregar um negócio de qualquer jeito.

Pode ser também porque, no momento em que eu gravo esse vídeo, estou usando o Claude Opus 4.8, que é muito bom. Do Opus 4.6 em diante ele mesmo percebe os próprios erros — é incrível, antes do 4.6 ele não era tão eficiente nisso. É muito difícil ver o Opus errando e errando sem perceber. Quando me perguntam qual o melhor modelo (a gente está em junho de 2026), eu acho o Opus extremamente confiável; o GPT-5 também está incrível, praticamente no mesmo nível.

Por outro lado, para desenvolver coisas, o que eu acho menos confiável dos três mais populares é o Gemini — ele esquece muito, às vezes inventa. Eu uso muito o Gemini Flash 3 como subprocesso, para tarefas de "um tiro só" e para ler conteúdos muito densos (tem planejamento meu que dá 30 mil linhas e precisa de um modelo com um milhão de contexto). Faço entre 20 e 20 mil processos por semana com ele porque, via Bash, fica barato. Mas para desenvolver com confiabilidade, dentro desse ambiente, ele é o pior dos três. Inclusive eu tive que colocar uma instrução de "cuidado, esse modelo mente" quando o uso como subagente.

Saindo e entrando de volta

Bom, ele fez um backup (uma versão preservada), colocou tudo na pasta global do Claude Code e avisou que a skill global vai entrar na lista quando reiniciar. Então, como eu mesmo recomendo: dou um exit, abro o Claude de volta e reinicio a conversa.

Se você quiser voltar direto para a conversa anterior, dá para fazer um resume/load normal e ele te dá um resumo direto e volta para a conversa. Tranquilo.

Pronto. Agora a gente tem uma skill para criar skills salva como global. Ele já sabe como tudo funciona, porque leu a skill antes e, ao salvar, aprendeu ainda mais — quando foi criar, teve que personalizar para o ambiente (se você usa Windows, por exemplo, e tem alguma instrução que não vai bem no Windows, ele tende a adaptar; foi por isso que ele perguntou sobre o ambiente Debian, no meu caso).

Passo 5: criar a skill nova de verdade (a skill de screenshot)

Agora a gente vai conversar com ele para criar a skill de screenshot. Eu já tirei a minha skill antiga de screenshot fora, então vai dar certo.

Eu coloco os dois termos — "screenshot" e "foto da tela" — de propósito, para deixar os dois na mente dele. Porque, quando você for conversar com ele no dia a dia, você pode usar tanto "foto da tela" quanto "screenshot". A skill tem gatilhos (triggers), e o próprio agente, a partir da conversa, vai perceber quais gatilhos colocar.

Os gatilhos (triggers) de uma skill são as palavras ou padrões que fazem o agente reconhecer sozinho que aquela skill deve ser ativada — e ele mesmo define esses gatilhos a partir da sua conversa.

E aqui está, na minha opinião, a coisa mais importante de toda a parte técnica de uma skill. Tem uma descriçãozinha dentro da skill — uma frase que explica para o agente quando usar aquela skill — e é essa descrição, junto com os gatilhos, que faz o Claude decidir sozinho se vai acionar a skill ou não. É o que dispara tudo. Se a descrição for boa e clara ("use isto quando o usuário mandar um link de foto da tela"), a skill aciona certinho toda vez. Se for vaga, pode ser que ela simplesmente nunca seja chamada — você criou a skill, mas o agente nunca lembra de usar. A boa notícia: você não escreve isso na mão. A partir da conversa, o próprio agente já entende a sua dor e escreve uma descrição que funciona.

A mensagem inicial é algo assim, em linguagem natural:

Estou te dando uma foto da tela para te mostrar algo. Isso tem que
ficar claro para você. Mas não crie nada, vamos conversar a respeito.

Vamos criar uma skill de screenshot / foto da tela: quando eu enviar
para você, neste ambiente, um determinado tipo de link que seja um
compartilhamento de screenshot através de uma URL, você consegue
identificar facilmente e não fica perdido.

Repare que eu não uso nenhum termo extremamente técnico. Não tem uma grande sacada de "como escrever o prompt perfeito". Na minha opinião, o melhor jeito de você aprender com a IA, fazer essa conversa e ter a opinião dele é usar uma linguagem o mais natural possível.

Por isso eu falo coisas como "não fique perdido", "sem entender como ler ou pegar a informação". Faz todo sentido quando você trabalha com a IA do jeito que eu explico — falando como se ele estivesse do seu lado. Pelo que eu vejo nos feedbacks dos treinamentos que faço para clientes, essa é a forma que funciona melhor para qualquer pessoa conseguir usar o agente de IA para se potencializar.

Por que a skill de screenshot vale tanto

Deixa eu mostrar na prática. No meu Mac (ou no Windows), eu seleciono uma área da tela com a ferramenta de screenshot, ele gera um link e eu copio. Para quem eu mandar aquele link, a pessoa vê exatamente aquele conteúdo.

Dentro do Claude, poder compartilhar screenshot facilita muita coisa. Imagine que você está desenvolvendo um site, um conteúdo, um PDF, e pensa "essa parte aqui não está boa". Você vem, pega a área que quer comentar, bota uma seta, e fala: "olha, te passando aqui nessa seta, esse negócio está errado, veja no link". O screenshot ajuda demais nisso — eu uso muito.

Mas, sem a skill, ele fica perguntando "o que eu faço com a sua URL?". Ele acessa o link e fica sem saber o que fazer. Com a skill, você usa uma linguagem natural, cola o link, e ele — como uma pessoa — entende que aquilo é uma foto da tela. Só que, como ele precisa de padrões, ele vai:

1. Acessar a URL e identificar o padrão de URL daquela ferramenta;
2. Salvar aquela imagem num lugar correto, com o nome correto;
3. Ler usando a visão dele para compreender a imagem;
4. Retornar para você falando sobre a imagem.

A skill não define só o que o agente faz, mas também o que ele faz com o resultado e qual é o objetivo final — no caso do screenshot: baixar, ler e retornar ao usuário a intenção da imagem.

Eu escolhi essa skill porque dá para considerá-la básica, mas ela não é só texto simples: ela tem instruções, pode criar um script Python, pode colocar comandos para baixar o arquivo. No seu ambiente pode sair diferente do meu — e não tem problema, o importante é o objetivo final.

As ferramentas de screenshot: Lightshot e Zight

Aqui vamos para a parte das ferramentas. No Mac e no Windows eu uso o Zight, que é muito bom mesmo — só que é pago, e eu acho que não tem versão grátis. O Lightshot, que eu conheço, é o melhor e mais prático dos gratuitos. Existem outros, tá?

(Inclusive, depois de um tempo trabalhando com agentes de IA, você acaba se sentindo super poderoso, porque pode criar quase tudo. Eu já cheguei a ter mais de 100 servidores com sites, e hoje, quando monto um servidor de hospedagem novo, crio tudo com a IA — tenho um agente que treinei e especializei nessa parte. Muitas ferramentas que eu pagava, eu desenvolvi. Essa de screenshot eu ainda pago porque ela é muito boa, mas em breve provavelmente faço a minha. Claro, sempre avalie o custo-benefício: o tempo que você vai gastar versus o que aquilo custa.)

Se você já tem uma ferramenta de screenshot, não trava, não pensa "puxa, vou ter que instalar uma dessas duas". Não. Eu mostro essas duas porque são as que eu conheço e sei explicar o que vai acontecer. Você pode ter uma terceira, uma quarta. Geralmente a ferramenta te dá a possibilidade de fazer uma seleção na tela com um atalho, e aí ela gera um link (share / copiar link) ou salva. No nosso caso eu mostro o link, porque é isso que a gente vai passar para o agente — e pode ser qualquer ferramenta, vai funcionar com qualquer uma.

Mostre os padrões e mande ele identificar

A grande sacada de desenvolver dessa forma: a gente não vai explicar tecnicamente para ele como cada ferramenta funciona. A gente faz uma conversa e mostra os exemplos. Se na sua empresa usam cinco ferramentas de screenshot, então mostra os cinco tipos de link para ele — ele que se vire para entender os padrões. Você fala: "identifique os padrões, retorne as descobertas e agora crie".

Então eu peguei um link do Zight e um do Lightshot e passei. E coloquei também uma dica opcional (deixei marcada com uma "lâmpada" no whiteboard para não esquecer): se alguém estiver vendo isso e nunca usou nenhuma ferramenta, e não quiser usar essas duas, converse com ele. Algo como:

Me explique como funcionam as ferramentas para tirar foto da tela no
computador, similares ao Lightshot e ao Zight, que tiram foto da tela
e geram um link com a imagem para compartilhar facilmente uma URL.
De preferência as mais fáceis e intuitivas, e gratuitas. Me dê a sua
opinião sobre elas.

Repare que eu não coloquei "Windows, Mac e Linux" todos juntos, porque isso limitaria — de repente ele responde "só existe uma ferramenta X que funciona nos três". Coloque só o seu sistema. Se você quiser aprofundar essa conversa, ele te fala os benefícios de cada uma e, dependendo da ferramenta, ele mesmo consegue instalar para você.

Resumindo o passo 5: ou você usa o seu programa de screenshot, ou instala um desses dois. Se não tem nenhum, eu recomendo o Lightshot, que é super fácil.

Passo 6: finalizar e testar (a opinião do agente, justificar escolhas e o teste real)

Chegamos na última etapa. Antes de mandar criar, a mensagem reforça de novo a contenção da ansiedade — algo como "não saia já criando, vamos conversar primeiro". A gente dá o enter, e aí ele dá a opinião final dele: "olha, eu acho que essa skill funcionaria bem se fizesse assim, assim, assim — por causa disso, disso, disso".

Peça para o agente justificar as escolhas

Se você está fazendo uma coisa muito delicada, lembra do que eu falei sobre pedir para ele justificar as escolhas. O agente de IA, muitas vezes, faz perguntas para o usuário e joga a responsabilidade no colo dele. Se o agente começar a fazer isso com você, corrija. Pare ele e fale:

"Você não pode jogar as perguntas no colo do usuário e jogar a responsabilidade para cima dele. Sempre que fizer perguntas, você precisa dar a sua opinião e justificar as suas escolhas, para ajudar o usuário a escolher o melhor caminho."

Porque senão o usuário faz três, quatro perguntas e escolhe o caminho errado. Por quê? Porque a gente não é programador, não é expert, não trabalha no Google. A ideia desses vídeos, e dos clientes que eu atendo, é que ninguém precisa virar um expert gênio para se multiplicar. E quem não é expert em programação pode escolher o caminho errado. O agente, que tem todo esse conhecimento e sabe todos os padrões de desenvolvimento, é quem deve contextualizar e dizer: "são três perguntas; eu recomendo os itens 1 e 2, por causa disso, disso e disso".

O agente decide o formato sozinho

Pelo fluxo da conversa, ele entende o tipo de skill que precisa ser criado. Lembra dos três formatos (instrução, instrução com script, instrução com script e subagente)? Ele colocou que a nossa vai ter um script, e eu fiquei contente com isso. Ele poderia ter feito tudo só com instrução, mas eu acho mais legal quando tem script, porque aí ele usa o melhor dos dois mundos.

Pensa assim: quando você trabalha com o agente de IA, você está trabalhando com inteligência (ter uma opinião, decidir o que fazer). Quando você faz um script, você tem um processo mecânico, com validação: vai pelo caminho A, B ou C, e pronto, sem improviso. E ele mesmo explicou isso — fez um desenho híbrido, onde o script faz a parte mecânica de pegar e baixar a imagem, e a inteligência dele faz o resto.

Use script quando você quer um resultado padronizado e repetível: se você precisa que algo seja feito mil ou um milhão de vezes sempre igual, um script garante o mesmo padrão; sem ele, a IA tende a fazer de um jeito diferente a cada vez, como um ser humano faria.

Os gatilhos ele também definiu sozinho — eu não precisei dizer na skill quais seriam. Ele identificou que a dor real não é técnica, é uma de gatilho: "não quero ter que explicar toda vez". Aí ele colocou os domínios das ferramentas como gatilho — quando você compartilhar uma URL daquele domínio, ele entende "opa, isso é um screenshot" —, mais frases de captura.

O teste é o que prova (não é dedução)

Uma coisa importante: nada do que ele decidiu foi por memória ou dedução. Lembra que a gente pediu para ele testar? Ele foi lá, acessou a internet e comprovou como os padrões de URL funcionam. A IA de hoje é muito boa porque é inteligente e consulta a internet. Se você pega qualquer IA via API e não dá nenhuma ferramenta de acesso à internet, o desempenho dela cai muito, porque ela trabalha só com informação do treinamento e às vezes já comete erros. No Claude Code ele tem acesso à internet e a todas as ferramentas do computador. Então a forma como a skill foi feita não veio da memória de treinamento — veio de teste.

Ele também fez uma calibração sem exagero: nada de criar uma skill mega complexa com milhares de validações para um screenshot. A gente não está construindo uma skill para a NASA.

Como a skill ficou organizada

Uma skill, gente, no fundo é simples assim: uma pasta com um arquivo chamado SKILL.md dentro — essas são as instruções, o "manual" que o agente vai seguir. Quando tem script, ele cria uma pasta auxiliar. Ele criou, dentro do padrão, uma pasta chamada scripts, e lá dentro colocou um arquivo resolve_screenshot em Python. E olha que tranquilo: esse SKILL.md quem escreveu foi o próprio agente, usando a skill creator. Você não toca nele na mão, não mexe em configuração nenhuma — você conversou, ele montou o arquivo.

A gente não vai abrir esse arquivo. Não precisa. E aqui vai um desabafo importante: quando comecei a trabalhar forte com IA (uns dois, três anos atrás), eu usava o VS Code porque gostava de ver o script do meu lado. Ficava incomodado de deixar a IA fazer e não conferir — só que, caramba, eu não sou um excelente programador. Tenho cursos de programação da época em que os dinossauros ainda andavam no planeta, porque eu tinha uma agência e precisava entender do assunto para coordenar meu time. Mas não sou programador, não vou sair criando scripts.

Desde o ano passado, eu não olho mais o código. Tenho projetos com 20, 30 mil arquivos e não abro. Sabe o que o pessoal da Anthropic fala? Que ferramentas que o Claude lançou foram desenvolvidas por ele mesmo. Os caras que são "power" não estão mais abrindo script, não estão mais codando. Quem somos nós para ficar codando? Você não tem que ser programador, não tem que entender o que é um laço, o que é um if. Claro que, se você entende, é melhor — sua comunicação com o agente fica mais fluida e você sabe melhor o que falar. Programador tem uma excelente vantagem nesse mundo de agentes. Mas você não precisa. Então não vamos abrir o arquivo: eu só quero que ele funcione.

Fechando o desenho (sem fallback, só os serviços que eu uso)

Ele me mandou um resumo da opinião dele — uma skill híbrida, global, com script — e pediu para confirmar dois pontos, A e B, antes de criar qualquer coisa.

• Fallback: aqui ele propôs um protocolo de fallback, mas isso é porque eu tenho outras skills no meu ambiente (uma de navegador, uma de video-frame). Você provavelmente não tem isso, então eu respondi "não quero fallback nenhum", para ele não criar algo que demore mais do que deveria.
• Serviços: ele poderia se empolgar e falar "existem 30 plataformas de screenshot, vou fazer uma skill para as 30". Não precisa. Se um dia você for usar outra plataforma, daí você conversa com ele e pede para melhorar a skill. Faça só para as que você usa. A gente tem que pensar sempre no gasto de token, no dinheiro e no tempo. Eu respondi: "os serviços são os que eu te forneci como exemplos".

Construa a skill enxuta, só para o que você realmente usa hoje. Se um dia precisar de mais, você conversa com o agente e pede para ele melhorar a skill — não tente cobrir tudo de uma vez.

Teve um ponto que eu não entendi: ele falou de "comportamento pós-visão". Eu não fico lendo cada palavra do monte de texto que ele escreve (ainda mais gravando um vídeo); leio dinamicamente. Então eu perguntei: "o que você quis dizer com comportamento pós-visão?". Era o que ele faz depois de ver a imagem.

O puxão de orelha: rewind e recomendação obrigatória

Aí ele fez de novo aquilo que eu avisei: jogou a pergunta no colo do usuário, me dando uma opção A ou B sem recomendar. Em vez de simplesmente responder, eu dei um /rewind — você volta para a mensagem anterior. Ele te pergunta se quer restaurar a conversa, restaurar os arquivos, etc. Eu só restaurei a conversa.

Por que rewind, e não corrigir na frente? Porque, se ele tomou uma atitude errada, foi por algum motivo — talvez a sua instrução não tenha sido boa o suficiente. Se a instrução podia ser melhor, use o rewind, porque você melhora a instrução na origem. É melhor do que ficar corrigindo, porque na correção aquela mensagem ruim (ele jogando a pergunta no seu colo) já fica ali no rolo de contexto. Com o rewind, você reescreve.

O /rewind serve para corrigir o agente na origem: em vez de corrigir uma atitude errada que já entrou no contexto, você volta e melhora a própria instrução que causou o problema.

Então eu reescrevi a instrução com um puxão de orelha:

Você não pode jogar as perguntas no colo do usuário e esperar que ele
decida com pouco ou nenhum contexto. Sempre que você perguntar algo ao
usuário, você deve recomendar uma das opções com justificativas claras,
sem dedução e sem preguiça.

Assim, da próxima vez que ele perguntar "quer o caminho A, B ou C", já vem com a recomendação dele. Mesmo com essa instrução, ele às vezes ainda escorrega — mas melhora muito. Eu faço essa correção pensando em qualquer pessoa: se eu acho que a pergunta não está clara para qualquer um, vale a correção.

Quando ele voltou, explicou direitinho o "pós-visão": é "vejo a imagem, descrevo o que encontrei, e paro". A única ressalva: se a sua intenção não estiver evidente, ele pergunta. O exemplo que ele deu foi ótimo — se você manda um print de um canal do YouTube com setas vermelhas dizendo "esse botão está errado", a intenção é óbvia e ele já age. Mas se você manda a imagem só dizendo "quero te mostrar uma coisa", ele descreve o que viu e pergunta qual caminho seguir, em vez de sair fazendo sozinho. Ele precisa ter um comportamento flexível, adaptado ao contexto.

(Eu já fiz skill de screenshot umas dez vezes e nunca tinha visto uma pergunta sobre a intenção — geralmente é meio óbvio. Mas foi bom que apareceu. Se aparecer uma pergunta diferente para você, coloca nos comentários do vídeo.)

Adicionando o timestamp no nome do arquivo

No meu whiteboard eu tinha marcado uma dica (com a lâmpada amarela) que quase esqueci de empolgação: pedir para ele usar timestamp no nome do arquivo. Mandei isso como informação extra:

Sempre use timestamp no nome do arquivo.

Timestamp é o tempo: ele pega ano, mês, dia, hora, minuto, segundo (até frações). Então, se você manda dois screenshots, ele salva um com _timestamp e o outro com outro _timestamp — nunca vão ter o mesmo nome, nunca um substitui o outro. Mesmo que ele cometa um errinho, o nome do arquivo sempre é único. E ele coloca isso direto no script (_timestamp), então é mecânico e à prova de duplicação.

Outras coisas que você pode pedir para enriquecer (eu não vou colocar aqui para o vídeo não ficar mais longo, mas dá para fazer):

• Que o script faça uma verificação automática e delete arquivos antigos a cada 60 ou 90 dias, para não pesar a máquina. Como o script já roda na hora de salvar, ele faz essa limpeza sozinho.
• Que ele otimize a imagem ao salvar, no menor tamanho possível, sem perder qualidade. Eu tenho isso no meu padrão — você fala "quando salvar o screenshot, salve já compactado, otimizado, sem perder qualidade".

Tudo isso entra naquilo que eu falei de conversar: você expõe a sua necessidade real ("não quero arquivos pesados", "quero limpeza automática") e ele resolve.

A bateria de testes (faça ele testar de verdade)

Agora a parte que eu considero essencial: testar. Eu tenho, no meu ambiente, vários subagentes (uns 11, 12), e um deles, global, é o que eu chamo de Guardian. A função dele é desconfiar de tudo: ele parte do princípio de que o colega que desenvolveu o script foi preguiçoso e estragou tudo, então a missão dele é destruir o script com testes para encontrar bugs, falhas, inconsistências e erros ocultos. Isso já está nativamente no prompt de sistema dele.

Mas, como nem todo mundo do outro lado tem um Guardian, eu pedi para o próprio Claude testar, sem subagente. A mensagem foi assim:

Agora, por favor, faça diversos testes, mas não use skill auxiliar de
testes e também não use subagentes de testes como o Guardian. Eu quero
que você mesmo faça todos os testes. E você deve ignorar alertas de hook.

Por que essas ressalvas? Porque eu tenho uma skill de testes extrema (para projetos grandes, com milhares de arquivos, onde os testes precisam ser feitos em camadas) e tenho o subagente Guardian. Se você não tem skill de testes nem subagente testador, simplesmente não escreva essas partes — pede só "faça diversos testes" mesmo.

E o "ignorar alertas de hook"? Hooks são incríveis, dá para fazer muita coisa com eles. No meu Claude Code, eu tenho um hook (que não aparece para mim, só para o agente) que, quando ele vai ler arquivos muito grandes, avisa: "você é o coordenador, evite abrir arquivos grandes desnecessariamente, delega para o subagente investigador, para não gastar o seu contexto". Como nos testes ele talvez precise abrir arquivos grandes, eu pedi para ignorar esse hook nessa hora. Mas, de novo: isso é do meu contexto. Não copie a minha instrução literalmente — faça dentro do seu contexto.

Por que insistir tanto em testes, se o Opus quase não erra? Porque ele pode ter feito um script que funciona na maioria dos casos, mas que em determinado cenário (um edge case) dá pau — talvez o timestamp bugue num momento específico, sei lá. A gente não instruiu ele detalhadamente em tudo, então é legal sempre pedir uma bateria rígida e exigente de testes. Você pode até citar edge cases, que ele faz testes mais amplos, ou simplesmente falar "testes amplos" que ele já entende.

Mesmo com modelos muito bons, sempre peça uma bateria de testes rígida e cite edge cases: o script pode funcionar na maioria dos casos e falhar só num cenário específico que você não previu.

E ele fez exatamente isso: criou um arquivo de testes, rodou várias rodadas (uma com 29 testes, depois mais camadas), encontrou um bug real, corrigiu, e validou tudo. Isso é maravilhoso — antigamente, na época de frameworks como o CodeIgniter, já era ótimo quando o framework ajudava com testes; hoje a IA identifica e cria a bateria de teste sozinha. (Tem projeto com 1.000, 2.000, 5.000 testes — às vezes o código de teste é maior que o próprio projeto.)

Um aviso sobre modelos, já que toquei nisso: além do Opus, eu uso alguns chineses para propósitos específicos — DeepSeek V4 Pro, o Flash, o M3 da MiniMax (tenho plano anual, dá limites enormes) e o Kimi. Mas tome muito cuidado com aquela cultura de "saiu um modelo novo, o mundo mudou, o jogo virou". Sai coisa nova de IA o tempo todo, e se você tentar acompanhar tudo, não consegue trabalhar nem evoluir. Claro que você tem que se atualizar — mas quando eu vou testar um modelo novo, separo um dia, com um propósito. Eu demoro um pouco para adotar lançamento, porque tenho muita coisa em produção: se der problema, que dê problema com os outros primeiro. Aquela chamada "o jogo é outro, tudo mudou" eu detesto.

O teste final: sair, reabrir e mandar de verdade

Ele mesmo recomendou o teste simples no final: fechar e abrir de volta, e mandar um screenshot. Então exit, reabro o Claude (dá para entrar na mesma sessão), e vamos ao teste.

Eu fiz um screenshot de um pedacinho qualquer da tela — de propósito, um pedaço "do nada", porque assim ele não tem como mentir nem deduzir: ele vai ter que me dizer exatamente o que tem ali. Copiei o link e colei.

E olha o que aconteceu: a skill ficou na pasta global do Claude Code, dentro da pasta skills, numa pasta chamada screenshot reader. Quando eu mandei o link, ele entrou na pasta do projeto (no caso, a pasta "aulas"), criou uma pasta imagens sozinho — eu nem instruí ele a fazer isso, por isso toda aquela conversa valeu — e salvou o arquivo com a numeração de timestamp que eu pedi. Ele testou, leu o arquivo, resolveu direitinho e me reportou a cobertura dos casos comprovados, descrevendo o que tinha naquele pedaço da tela. Funcionando.

Agora a gente tem uma skill de screenshot excelente, que vai te ajudar bastante. E, com esse conhecimento, você pode nunca mais precisar ficar dependendo de skill pronta. Você cria as suas — e só pega uma pronta se for realmente necessário.

Eu sou o Paulo Teixeira. Um abraço e até a próxima.