Coloquei o Jev nos mods do Claude Code e é ABSURDO! (entreguei os prompts)

Author: Matheus Battisti - Hora de Codar · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: Portuguese

Original video: Coloquei o Jev nos mods do Claude Code e é ABSURDO! (entreguei os prompts) · Channel: Matheus Battisti - Hora de Codar · 16:41 · Watch on YouTube

Topics: AI agents, Task and workflow automation, Cybersecurity and software security, Claude Code, Prompt and context engineering

Summary

O vídeo mostra como combinar Jev e mods do Claude Code para adicionar decisões flexíveis e rápidas a diferentes etapas de execução. O apresentador demonstra dois exemplos: um porteiro de pacotes, que avalia pedidos de instalação de bibliotecas, e um boletim que analisa o comportamento do Claude Code e sugere melhorias. Ele também explica como os mods podem ser criados com prompts e compartilha recomendações sobre testes, definição de pronto e chamadas HTTP para o Jev. Os prompts dos exemplos são compartilhados para que o público possa consultá-los e adaptá-los.

Key points

Os mods do Claude Code permitem intervir em diferentes pontos da execução, como edições, testes e instalação de pacotes.
O Jev é apresentado como uma opção rápida e de baixo custo para decisões flexíveis, em comparação com regras fixas ou uma LLM.
O porteiro de pacotes avalia pedidos explícitos ou implícitos de instalação e permite que a pessoa escolha se quer prosseguir.
No exemplo, o mod identificou o pedido de instalação do Canvas Confetti e estimou em 94% a chance de o pacote ser necessário.
O boletim avalia critérios do comportamento do Claude Code e sugere regras para melhorar suas respostas.
O comando «melhorar» registra regras no CLAUDE.md, permitindo um ciclo de melhoria contínua por projeto.
O apresentador compartilha prompts dos mods, incluindo versões com e sem Jev.
Adicionar testes e uma definição de pronto aos prompts de criação de mods pode ajudar a fazê-los funcionar corretamente.

Chapters

Start	Chapter	Summary
00:00	Por que combinar Jev e mods	O apresentador explica como o Jev pode acrescentar decisões flexíveis aos mods do Claude Code sem depender de muitas regras fixas.
04:40	Documentação e preparação dos exemplos	Ele aponta a documentação dos mods, apresenta os prompts compartilhados e explica a configuração do Jev.
06:12	Demonstração do porteiro de pacotes	O primeiro mod avalia instalações de pacotes e permite decidir se o Claude Code deve prosseguir.
11:24	Boletim e melhoria contínua	O segundo mod avalia critérios de comportamento e registra sugestões de melhoria no CLAUDE.md.
15:06	Testes, definição de pronto e encerramento	O apresentador recomenda incluir testes e uma definição de pronto nos prompts dos mods e encerra divulgando o treinamento de Jev.

Quotes

Ele é flexível, rápido e barato. — 02:36

O Jev pegou nesse ponto, porque o mod permite essa flexibilidade. — 09:52

Eu consigo fazer esse ciclo de melhoria contínua dentro do meu Claude Code. — 13:30

Eu crio, junto com meus prompts de mod, uma sessão de testes e uma definição de pronto. — 15:38

Concepts and entities

Claude Code, Jev, mods, Anthropic, TypeScript, CLAUDE.md, Canvas Confetti, TypeSafe

Full transcript (original language)

00:00 Gara, ontem a gente falou sobre Cloud Code Mods, que é uma funcionalidade nova que o pessoal da Antropic lançou pro Cloud Code para melhorar a flexibilidade dos hooks. Então, os mods eles vão poder agir basicamente em qualquer ponto ali que o Cloud Code executa, o que aumenta aí a nossa forma de personalizar o que a gente quer que faça nesses intervalos. Também dá mais possibilidades pra gente e via código type, né, para quem programa. É bem interessante. Tem um vídeo que eu fiz, como eu comentei, tem

00:30 um vídeo que eu fiz ontem, então depois assistam lá que vale a pena também aprender mais sobre o assunto por a ótica só de cloud Code. Hoje eu quero mostrar para vocês esse novo recurso do mods junto com o JV, porque eu notei que a gente adiciona muito código de programação para poder fazer os mods, mas às vezes a gente precisa de uma IA que decida ou que faça alguma coisa ali em relação ao que a gente criou o mod, né? para o fim do mod. E aí que entra o JEV, porque a LLM é lenta e cara para

01:01 esse sentido, né, para essa função. O JEV resolve esse problema e não depende de muito código para poder resolver o problema da melhor forma. Então vamos lá, vou explicar para vocês todos os detalhes, dar uma repassada nos mods e criar alguns exemplos práticos. Chega aí. Bom, galera, então antes um disclaimerzinho, né? Uma introdução mais teórica para vocês situarem do que eu tô falando. E aqui a minha ideia foi, cara, e se a gente conseguisse colocar o JV ali nos mods para poder potencializar a

01:32 forma de decisão de algo que não é rígido? Porque eu posso programar uns 3, 5, 10 casos, deixar meu código performático e ter o mesmo sucesso do que se eu usasse Jev, gastasse com uma uma IA, né, que ele gasta tokens. Então eu consegui colocar o Jev, criei alguns casos interessantes e ele faz justamente isso. Ele adiciona ali um poder flexível de decisão nos mods que o Cloud Code tem. Então bota aqui um mod recebe cada passo do cloud code, cada edição, cada

02:05 teste, cada commit. Para fazer algo útil com isso, alguém precisa decidir a cada passo se deixa de seguir ou segura, né? uma regra ali que a gente estabeleceu. E é esse trabalho que o JF faz melhor, porque eu posso ter aqui centenas de regras, eu posso estar trabalhando com esse mod em vários projetos diferentes e quando eu tenho uma IA, eu não tenho esse problema porque eu não preciso criar essas condições todas no código. É esse que é o grande ponto. Então a gente tem que regra fixa é burra, né? Claro que se for um escopo pequeno, tenho cinco, 10 regras, não tem problema. Só

02:36 que eu vou ter que ficar adicionando mais e mais regras. Se o projeto crescer, o molde crescer, o Llm é lento, a gente vai ter uma resposta que vai chegar, pode ser que seja correta, igual o JV, não tem problema nenhum, só que vai demorar um pouco mais e vai ser provavelmente mais cara. E o JV fica nesse meio tema, ele é flexível, rápido e barato. Ele vai conseguir decidir. Não preciso limitar a quantidade de regras. E eu tenho uma IA ainda, né, adicionando poder ao nosso mod. Se eu tivesse regras fixas, por exemplo, vamos dizer que eu

03:07 executo um comando de Linux, isso tá na regra, mas se eu executo um comando de Windows, já teria que adicionar mais uma regra fixa para poder caber esse caso. Então isso é tecnicamente ruim de manter. Já se eu tenho aqui uma LLM e eu depende dela para decidir, ela vai conseguir entregar, ela vai conseguir ler que nem o JV, só que ela vai demorar segundos e gastar muito mais. E o JV não, ele vai gastar poucos tokens. ele vai ser rápido e barato. Outro ponto também, galera, é que na sessão de cloud

03:37 code a gente vai ter várias interações, né? a gente de fora vê só o prompt indo e a resposta chegando, mas na verdade a gente tem alguns outros processos rolando. A gente tem o prompt, a gente tem as interações entre o cloud e nosso editor, a gente tem comandos de terminal sendo executados, a gente tem ali a instalação de pacotes, n coisas. E o JV ele vai conseguir entrar em cada um desses pontos de maneira muito rápida, né? a gente nem vai perceber que ele vai

04:09 tá ali no meio, vai deixar mais fluido também o nosso mod. Então isso aqui é um exemplo nessas barrinhas que o modelo comum de A vai ter ali de interação com o cloud code durante a sessão. Então em cada turno, a gente tem muitas interações, muitas idas e vindas que executam várias coisas. Bom galera, dito isso, espero ter esclarecido um pouco mais sobre essa decisão de colocar JV, não só por colocar Jev em tudo, né, mas sim tem o fundamento por trás. Agora bora lá ver na prática, né, como é que funciona isso tudo. Antes de começar,

04:40 não esqueçam, a gente lançou o nosso treinamento de Jeev, tá galera? As inscrições estão aberta para membros fundadores. Já venho anunciando alguns dias aqui que a gente lançar esse treinamento. O link vai tá aqui no comentário fixado e tu vai ter acesso a essa condição especial de lançamento, beleza? Aí aqui nesse link tu vai acessar essa página, vai conseguir conhecer tudo que tem lá no curso. E esse vídeo aqui eu preparei especialmente para tu entender detalhe por detalhe. São só 6 minutos. Escute, veja e entenda como é que funciona o curso por dentro, tá bom? Os mods oidade

05:11 do cloud code que lançou recentemente, vou tentar deixar esse link aqui na descrição para quem quiser se aprofundar mais, tá? Recomendo que façam porque é um recurso bem interessante. Vários recursos do Cloud Code viraram mods, né? Então, a própria empresa Antropic decidiu transformar recursos que antes eram outras coisas em mods, né, em plugins. E isso provavelmente vai ser tendência, tá? Então aqui é a documentação dele oficial. E galera, nesse vídeo aqui eu testei uma coisa diferente. Em alguns vídeos atrás uma

05:42 pessoa comentou falando: “Por que eu não compartilharia os prompts em guist?” É uma maneira bem interessante. Nesse eu tive a ideia para ver se funciona da maneira que vocês precisam, né? Então tá todos os mods aqui que eu criei inclusive no vídeo passado nesse no guist, tá? Então vou deixar esse link aí também vocês poderem copiar o prompt. Aqui são os prompts de cada um dos mods, os sem jef e os com Jeff, tá bom? Galera, aqui eu estou já com os mods criados, né? Abri o cloud code para vocês verem. E eu tive uma duas ideias,

06:12 na verdade que eu já apliquei aqui, tá? Uma é a porteira de pacote. Que acontece? O cloud ele é uma IA que é muito inteligente e vai tentar resolver o trabalho da maneira mais eficiente possível. No decorrer do projeto, ele vai sugerir a instalação de bibliotecas para não ter que criar o código do zero, né? não reinventar a roda. O problema disso é que pode colocar bibliotecas que não sejam tão famosas, que sejam inseguras e às vezes a gente quer ter um controle mais granular sobre isso. Então eu criei esse porteiro de pacote que faz

06:43 justamente esse cenário. Ele vai conseguir avaliar cada interação do cloud que instala um pacote que pode ser explista eu pedindo ou pode ser inclista. Eu peço alguma coisa e ele resolve instalar o pacote. Então ele trava nesse ponto aí e pergunta se eu quero instalar ou não. É uma trava mais de segurança que a gente tem para não deixar tudo no automático, tá? E aí o que acontece também? A gente tem que pedir, né, para usar o JV, né, esse mod tem Jev. E é bem simples a integração, tá? Lá no Typeesave tem a skill, deixa

07:15 eu mostrar para vocês aqui. Quando tu faz o login na tua conta lá na Type Safe, né, tem a skill aqui, ó, do Jeev. Essa skill aqui ensina o teu agente a utilizar o o Jeff. Isso é bem interessante porque ele aprende que maneiras diferentes execução precisa também de execuções diferentes. Como por exemplo, nesse cenário aqui, ele não usa o JV da maneira convencional, ele tem que fazer uma chamada HTP, tá? Uma das coisas que eu descobri também. Mas de

07:45 todo modo, a gente precisa da nossa chave. Ela vai estar um en local, pode ser na pasta p. Tá? E aqui tem todos os arquivos de código, né? Quando a gente cria um mod, ele cria código type, como eu comentei para vocês. Então aqui tem arquivos, por exemplo, Jev, que vai chamar o JV HTTP e tudo mais, né? Para poder fazer as funcionalidades que a gente precisa. Isso aqui, claro, né, do TypeScript é mais técnico, mas é bom a gente entender que o código, né, fica à vista. É bem fácil de saber como o cloud

08:18 criou. E inclusive a gente pode pedir para ele criar aqui, né? Não precisa fazer nada muito acima da média. Basicamente o prompt vai conseguir criar o mod que a gente quer. Aquele vídeo [limpando a garganta] editou, deixa a tamb aqui do vídeo. Eu fiz primeiro, eu expliquei bem detalhe essa parte de criação. Então depois acessem lá, deem uma olhada. Aqui eu vou testar o porteiro de pacote, só para vocês entenderem como é que ele vai funcionar. Aqui eu vou testar o porteiro de pacote na prática, só para vocês verem como ele funciona. Mandar um prompt que eu peço explicitamente para ele cadastrar. uma

08:49 biblioteca, que nesse caso aqui é quando todos os itens da lista estiverem marcados com comprados, solte confetes na tela usando a biblioteca Canvas Confet. Tem um projeto aqui para testar as coisas, né? Bem simples, só para vocês também terem contexto disso. Voltando lá, que que vai acontecer aqui nesse processo? Ele já tá utilizando todos os plugins, né? Então, por isso tá meio poluído aqui, mas esse porteiro do pacote vai ser ativado e a gente vai conseguir ver ele na prática, inclusive o outro ali que é o boletim, tá? Eu vou explicar os dois na sequência. Então, a

09:20 gente vai esperar a execução normal, não muda nada. O Jeff tá interagindo aqui baseado no que a gente pediu para ele fazer. Isso foi via prompt. Depois eu mostro para vocês como pode ser feito na prática. Ó, aqui ele identificou que eu tô querendo instalar o canvas confet. Eu posso prosseguir, cancelar, pedir para ele instalar outro, né? Claro que eu fiz de forma explícita, né? Mas às vezes vai acontecer tu pedir alguma coisa e ele querer instalar um pacote. E é mais para isso que serve esse plugin. Mas o Jeff que detectou isso. Ele falou que tem 94%

09:52 de chance do Camas Confet ser necessário, tá? Então a gente pode prosseguir ou falar com o Cloud, pedir uma outra sugestão. Isso vai do que a gente quer. Se eu prosseguir aqui, ele vai fazer instalação e pronto. Esse é o funcionamento do porteiro. A decisão é tomada na hora que a gente vai instalar um pacote, né, um comando de instalação que é conhecido pelo npm install que tá justamente aqui, né? Então o JV pegou nesse ponto, né? Porque o cloud mod permite isso, permite essa flexibilidade. Então a gente consegue

10:22 ter um controle granular das coisas. Muito interessante isso. Praticamente qualquer ponto de execução a gente consegue interagir e colocar um mod. E se a gente quiser colocar o JV, né? E aqui, galera, olha só que interessante, isso aqui foi implícito, né? Ele precisava testar de alguma maneira o confet e para isso ele queria instalar o puper. E aí eu posso escolher seguir ou não. É como é isso que eu falei para vocês, às vezes vai tá sendo instalado coisas que a gente não precisa, ou pelo menos a gente quer ter noção do que tá

10:53 sendo somado no nosso projeto. Aqui eu vou prosseguir, né? Mas a gente poderia questionar ele nesse ponto também. Então ó, galera, esse aqui terminou, tá? E aqui o que apareceu é o meu outro plugin que tem Dev também, que eu já vou explicar para vocês, tá? interessante dos mods, né? Plugin, mods. Tô falando isso, mas é a mesma coisa, né? Porque os os mods estão dentro dos plugins aqui no Cloud Code, a gente consegue desenhar na tela, tá? Que é bem interessante, como vocês estão vendo aqui, é o que esse aqui faz, tá? Mas já explico, só deixa eu eh ver a evidência, né? Então, quando

11:24 todos os itens estão comprados, ele vai estourar o confet, ó, estourou o confet. Beleza, então tá, tudo funcionou normal, né? o JV não atrapalhou em nada, apenas a gente teve ali aquela inserção entre a instalação de pacotes e a execução de fato controlada ali pelo JV naquele ponto junto com o mods para a gente ver se era necessária a instalação dele ou não, não deixar isso tudo no automático, tá? E o meu segundo aqui que eu fiz foi esse boletim do cloud. O que acontece? Sempre

11:56 que eu entro num projeto novo, eu vejo que eu tenho que colocar várias regras para deixar o cloud bem alinhado, né? Para ele entender aquele projeto, para ele começar a entregar do jeito que eu quero, me responder dessa forma também. E aí eu criei o boletim. O boletim ele dá a nota aqui com alguns critérios que é um dos fortes do Jeev, né? a gente analisar vários critérios na resposta para ou melhor como o cloud agiu. E com isso eu consigo ver aqui se tá tudo

12:28 certo do jeito que eu quero, tá? Então ele dá essa análise aqui, eu posso abrir e fechar com o comando boletim. Então eu consigo criar criar slash commands, né, também junto com os mods, tá? Então ele tá aqui, né? Esse aqui é o é o boletim. E vocês veem aqui, eu consigo ver dentro do boletim o quais são os pontos de melhoria. Então aqui, regra sugerida: termine sugerindo um próximo passo que faça sentido. Tamanho da mudança. Regra sugerida, mexa só no que o pedido exige. Se achar outra melhoria, sugira em vez

12:59 de fazer. São dois pontos que eu concordo, né? E um ele achou que tá fraco, né? O próximo passo e o tamanho da mudança tá OK. Então a gente pode melhorar isso. Como que eu vou melhorar isso? Eu vou colocar no cloud code regras que vão instruir melhor esse modelo e na próxima vez eu vou ter certeza que ele vai agir melhor nesses pontos. Talvez não ideal ainda, mas a ideia é que fique tudo ótimo, né? E o cloud code obedeça as minhas regras. Então eu consigo fazer com que o cloud

13:30 code passe os critérios pro JV, o JV detect, me retorne aqui no boletim como que eu tenho que melhorar. Vocês percebem aqui que ele tá oscilando de nota, né? Mas conforme eu for utilizando, ele vai melhorar, né, que são os primeiros prompts que eu dei. E aí, como é que isso melhora? Eu dou um barra melhorar, ele vai ler essas regras aqui de melhoria que ainda estão erradas, tá? Ele vai escrever isso no cloud MD, que é o arquivo central do cloud para cada projeto ou global. E com isso eu consigo tá fazendo esse ciclo de

14:03 melhoria contínua dentro do meu cloud code num projeto específico. Então é como se o cloud MD fosse respeitando regras que eu decidi como critério e a cada promp eu consigo ver se elas estão sendo respeitadas e o que que tem que melhorar para respeitar elas. Então, uma melhoria contínua, como eu comentei com vocês, é mais um ponto interessante para usar o JV, porque ele consegue ver vários critérios da entrega do cloud code e esse é o grande ponto. Sem precisar uma LLM avaliar, eu consigo passar para IADO Jeff. E aí, galera, só

14:33 para mostrar mais uma coisa que vai ajudar vocês, com certeza. Depois deem uma olhada nesses prompts aqui. Se eu não colocar o link, vocês me cobrem, tá? Porque é bem importante. Algumas coisas que estão aqui, eu tive que descobrir por tentativa erro, né? fazendo vendo que não dá certo. E a uma delas é a parte do das requisições pro JV, tá? Então aqui, ó, uma requisição HTP, tem que ser dessa maneira aqui. Então ela tá especificada desse jeito, tá? E outra coisa importante, eu não sei se é porque

15:06 o mod é um recurso novo, mas é muito comum tu pedir um mod até relativamente simples e o cloud não conseguir fazer ele funcionar de primeira e tu tem que melhorar ele e tal, ficar refaturando, refaturando não, né, mas enviando novos prompts para ajustar isso, tá? Então eu crio junto com meus prompts de mod também uma sessão de testes e uma definição de pronto. Isso fez com que eu tivesse mais sucesso de primeira nos

15:38 meus mods. Claro que às vezes falta alguma coisa, tem que melhorar, mas eu tô falando aqui da questão de não funcionar mesmo, de ficar assim: “Meu Deus, o que aconteceu?” Então assim, ainda mais quando envolve Jev, né, que é uma algo a mais que tá dentro do mod, isso aqui vai ajudar vocês a terem essa precisão e qualidade melhor, tá? Todos têm essa mesma estruturinha no final que me ajudou a os mods funcionarem em primeiro, tá? Então, cara, espero que você tenham gostado. Achei bem interessante esse recurso de mods porque eu tô explorando ali com JV também, né? Essa mania de colocar JV em tudo que realmente tem dado os frutos. E mais uma

16:09 prova é que os mods que foram de grande valia esses que eu criei, tá galera? Não se esqueçam, custo de Jev, tá? inscrições abertas com essa condição especial de membro fundador. Link vai estar aqui no comentário fixado. Participem lá, treinamento tá bem legal. Vou ensinar na prática como utilizar o JV de maneira efetiva em vários cenários, vários projetos, tá bom? Bom, então é isso, vou ficando por aqui. Agradeço a presença de todos. Se possível, deixa aquele like, se inscreve, isso ajuda bastante meu

16:41 trabalho aqui. E fico esperando vocês num próximo vídeo e também no curso de Jeev. Valeu, falou. M.