Como padronizar o uso do Jev no time que trabalha com Claude Code?

Resposta rápida

Padronizar o Jev no Claude Code em time não é combinado de call, é arquivo commitado. O caminho oficial é instalar a agent skill da TypeSafe como plugin (claude plugin marketplace add typesafe-ai/skills e claude plugin install typesafe@typesafe-ai), declarar marketplace e plugin em .claude/settings.json, escrever no CLAUDE.md da raiz quando o Jev é obrigatório (choice, score, noul) e versionar o .mcp.json se houver MCP. Cada pessoa precisa confiar na pasta do projeto, senão não recebe nada. Custo: US$ 0,042 por 1 milhão de tokens de entrada e US$ 0 na saída no jev-1.13

Todo mundo do time já pode usar o Jev, e é exatamente aí que a bagunça começa

O Jev começou com lista de espera no lançamento, e em 21 de setembro de 2026 o acesso foi aberto pra todos, sem lista nenhuma

Resultado prático: em uma semana você tem um dev chamando o Jev na mão via curl, outro que instalou a skill oficial, um terceiro que achou um MCP no GitHub e um quarto que nem sabe que a coisa existe 😅

Só pra situar quem chegou agora: o Jev é o modelo System One da TypeSafe AI, que saiu do modo stealth pouco antes de liberar o acesso pra todo mundo

Ele não gera texto e não conversa

Recebe um estado e perguntas tipadas, devolve respostas tipadas com probabilidades calibradas: é modelo de DECISÃO, e não substitui o LLM que roda por trás do Claude Code

E é por isso que padronizar aqui é fácil de explicar e chato de executar: o padrão não vive num combinado verbal, vive em arquivo versionado junto do repositório

O que o time precisa ter antes de padronizar

Antes de sair commitando settings, checa se estes quatro itens estão de pé:

  • Repositório com Claude Code já em uso pelo time, não vale padronizar ferramenta que metade da galera ainda não abriu
  • Chave de API criada no console da TypeSafe, em https://console.typesafe.ai/keys
  • Variável TYPESAFE_API_KEY definida na máquina de cada dev, porque é dela que os SDKs oficiais leem a credencial
  • Clareza de que o modelo padrão dos SDKs é jev-latest, ou seja, se o time quiser pinar versão, isso é decisão explícita e precisa estar escrita em algum lugar

Na máquina, é o de sempre:

export TYPESAFE_API_KEY="sua-chave-aqui"

Tome cuidado com um detalhe: chave de API é credencial, então ela não entra no repositório junto com o resto da configuração

O que você versiona é o padrão de USO, não o segredo

E o custo? Vale dimensionar antes:

O Jev cobra só por token de entrada

No jev-1.13 são US$ 0,042 por 1 milhão de tokens de entrada e US$ 0 por 1 milhão de tokens de saída

Isso muda o desenho do padrão do time, e muda de um jeito meio contraintuitivo: o que pesa na conta é o ESTADO que você manda, não a quantidade de perguntas que você faz sobre ele

Guarda essa ideia, ela vale ouro na hora de desenhar as chamadas do time

Como padronizar o Jev no time, passo a passo

A sequência abaixo vai do individual (sua máquina) pro coletivo (o repositório)

Faz na ordem, beleza? Pular o passo 2 é o motivo número um de time com fluxo divergente

  1. Instale o marketplace e o plugin da skill oficial

A rota oficial pra dar contexto do Jev ao Claude Code é a agent skill da TypeSafe, instalada como plugin:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

Depois, valida invocando a skill explicitamente:

/typesafe:typesafe-ai

O erro comum deste passo: instalar e não validar

Se o comando de barra não responde, não tem porque seguir pros arquivos do projeto: você vai versionar uma configuração que nem na sua máquina funciona

  1. Declare marketplace e plugin no .claude/settings.json e commite

Esse é o passo que transforma "eu instalei aqui" em "o time inteiro recebe"

O Claude Code permite declarar marketplace e plugins no arquivo de settings do projeto, pelas chaves extraKnownMarketplaces e enabledPlugins, justamente pra que quem clona o repositório receba a mesma configuração

O marketplace a declarar é o typesafe-ai/skills e o plugin é o typesafe@typesafe-ai, os mesmos do passo anterior

O erro comum deste passo: assumir que commitar resolve sozinho

Não resolve

Configurações compartilhadas do projeto só passam a valer depois que cada pessoa confia na pasta do projeto

Enquanto o teammate não confiar, ele continua vendo prompts e não recebe os plugins do marketplace declarado no arquivo

Então o PR precisa vir com essa instrução escrita, não só com o JSON

  1. Escreva no CLAUDE.md da raiz QUANDO o Jev é obrigatório

O CLAUDE.md na raiz do projeto é lido pelo Claude Code no início de toda sessão, e é o lugar certo pra fixar padrões e checklists do time (o Claude Code também lê AGENTS.md)

É aqui que você mata o "cada dev criou seu fluxo"

O texto precisa responder duas coisas: em que situação o agente deve chamar o Jev, e em que formato de pergunta

O Jev trabalha com três tipos:

  • choice: escolhe uma opção e devolve a distribuição de probabilidade
  • score: dá nota em uma rubrica definida por você
  • noul: resposta sim/não em escala de 0 a 1

O erro comum deste passo: escrever regra vaga tipo "use o Jev para decisões"

Isso não é regra, é desejo

Regra é "antes de abrir PR automático, rode um noul com a rubrica X", com o tipo e o gatilho nomeados

  1. Crie skills de projeto em .claude/skills/ pra encapsular as perguntas recorrentes

Skills de projeto no Claude Code são compartilhadas pelo git e carregadas a partir da pasta do projeto e dos diretórios pais até a raiz do repositório

Cada skill é uma pasta com um SKILL.md e frontmatter YAML:

.claude/skills/
  decisao-de-merge/
    SKILL.md
  triagem-de-bug/
    SKILL.md

A lógica é a mesma de qualquer padronização por skill compartilhada: em vez de cada pessoa redigir a pergunta do zero, a pergunta tipada mora num arquivo e todo mundo chama a mesma

Se você quiser ver o raciocínio aplicado fora do contexto de dev, esse post sobre padronizar entregas com skill compartilhada mostra o mesmo movimento em um time de marketing

O erro comum deste passo: misturar skill de projeto com skill pessoal

Skill pessoal mora em ~/.claude/skills/ e não vai pro git

Se a pergunta é padrão do time, ela é de projeto, ponto

  1. Decida o escopo do MCP, se houver MCP

Caso o time resolva expor o Jev como ferramenta via MCP, o escopo precisa ser decisão coletiva e não default:

  • .mcp.json na raiz do projeto: escopo de projeto, é o que se recomenda versionar
  • escopo local: fica privado ao dev, ninguém mais vê
  • escopo de usuário: fica em ~/.claude.json, vale pra todos os projetos daquela pessoa

O erro comum deste passo: alguém configurar no escopo local, dar tudo certo na máquina dele e o padrão simplesmente não existir pro resto do time

  1. Alinhe a credencial pelas settings, e em ambiente gerenciado use as managed settings

Variáveis de ambiente podem ser definidas no bloco env das settings do Claude Code, em ~/.claude/settings.json ou nas managed settings

E aqui entra a parte que resolve empresa com máquina padronizada: as managed settings têm a MAIOR precedência da hierarquia

No Linux elas ficam em /etc/claude-code/managed-settings.json e sobrescrevem tanto o ~/.claude quanto o .claude/ do projeto

O erro comum deste passo: debugar por horas uma configuração de projeto que está sendo sobrescrita por managed settings e ninguém lembrou de checar

Já vi gente perder a manhã nisso…

  1. Defina a política de atualização da skill

Skill desatualizada em parte do time é atrito silencioso: metade da galera com um comportamento, metade com outro

Pra carregar atualizações da skill no Claude Code você reinicia o Claude Code ou roda:

/reload-plugins

E pra não depender de disciplina humana, dá pra ligar a atualização automática pelo menu de plugins: abre /plugin, vai em Marketplaces > typesafe-ai > Enable auto-update

O erro comum deste passo: não escolher

Se o time não decide entre "todo mundo liga auto-update" e "a gente pina e atualiza junto", vira loteria

E quem não usa Claude Code?

Time misto é a regra hoje, não a exceção

Em outros agentes de código a mesma skill é instalada por npx:

npx skills add typesafe-ai/skills --skill typesafe-ai

Depois você seleciona o agente

Nesses casos a invocação não é o comando de barra: você pede pro agente usar a TypeSafe skill

Quando o Jev deve ser obrigatório (e quando é ruído)

Essa seção é a que o time precisa fechar em reunião, porque "obrigatório em tudo" é tão ruim quanto "opcional em tudo"

Onde faz sentido tornar obrigatório:

  • Decisão binária no fluxo do agente, tipo "esse diff está pronto pra abrir PR?": noul, resposta em escala de 0 a 1
  • Triagem de opções fechadas, tipo rotear um bug entre times ou escolher uma estratégia de correção entre N caminhos já definidos: choice, que devolve a distribuição de probabilidade
  • Avaliação por rubrica em revisão, tipo aderência ao padrão de código que o time escreveu: score, com a rubrica definida por você

Onde é ruído: escrever código, refatorar, gerar documentação, explicar erro

O Jev não gera texto

Se a tarefa é produzir conteúdo, ela continua no LLM que roda por trás do Claude Code, e forçar o Jev ali só adiciona uma chamada inútil no meio do caminho

O limite de contexto é critério de DESENHO, não detalhe:

O Jev ingere o estado uma vez e avalia todas as perguntas em paralelo, dentro de dois limites:

  • 64k tokens para o estado somado a todas as perguntas
  • 32k tokens para o estado somado à pergunta mais longa

Lê isso junto com o modelo de preço (cobrança só na entrada) e o padrão do time se desenha sozinho: em vez de cinco chamadas pequenas mandando o mesmo estado cinco vezes, você monta UMA chamada com o estado e as cinco perguntas tipadas

Esse é o tipo de convenção que precisa estar no CLAUDE.md, senão cada dev resolve do jeito dele e o custo vira surpresa no fim do mês

Se o seu papel é ajudar outras empresas a chegar nesse nível de padrão, vale olhar o que costuma entrar num entregável de consultoria de adoção: é bem esse pacote de arquivos versionados mais regra escrita

Pontos de atrito mais comuns na adoção coletiva

Nenhum desses é bug

São todos configuração, e todos aparecem na primeira semana de adoção coletiva

Sintoma Causa provável Como prevenir
Dev clonou o repo e não recebeu o plugin, continua vendo prompts A pessoa não confiou na pasta do projeto, e sem isso as configurações compartilhadas não valem Colocar "confie na pasta do projeto" no onboarding, junto do PR de settings
Metade do time com comportamento diferente da skill Falta de política de reload ou auto-update Decidir entre /reload-plugins + reinício ou /plugin > Marketplaces > typesafe-ai > Enable auto-update
MCP funciona só na máquina de um dev MCP configurado em escopo local ou de usuário (~/.claude.json) Usar .mcp.json na raiz e versionar
Funciona local e falha em outro ambiente TYPESAFE_API_KEY ausente, divergente, ou sobrescrita por managed settings Definir no bloco env e lembrar que as managed settings têm a maior precedência
Cada dev apontando pra um MCP diferente do Jev Confusão entre skill oficial e projeto de terceiro Registrar no CLAUDE.md qual é a rota oficial do time

Esse último merece parágrafo próprio, porque é o mais fácil de errar de boa fé

Existem servidores MCP que expõem o Jev como ferramenta publicados no GitHub, como tphakala/jev-mcp, rahulrajaram/jev-mcp e wangkuangkuang/jev-mcp-server

São projetos de terceiros, não produtos da TypeSafe

A agent skill oficial, essa sim, é mantida em repositório público da própria TypeSafe, em github.com/typesafe-ai/skills, com a skill em skills/typesafe-ai/SKILL.md

Usar projeto de terceiro é escolha legítima do time

O problema é não REGISTRAR essa escolha e a diferença de quem mantém cada coisa: aí a decisão vira folclore e o próximo dev que entra não tem como saber o que é oficial

Vídeo: o Claude Code trabalhando sozinho até terminar

Pra começar do zero com automação de fluxo no Claude Code, este vídeo do canal mostra o /goal, o comando que faz o agente seguir trabalhando até concluir o objetivo

É um bom ponto de partida antes de desenhar o padrão do time, porque entender como o agente encadeia as etapas sozinho ajuda a decidir em quais pontos do fluxo faz sentido cravar uma decisão tipada

Conclusão

Padrão de time é arquivo commitado mais regra escrita no CLAUDE.md

O resto é combinado de call, e combinado de call some na segunda sprint 🙂

Próximo passo bem concreto: abre UM PR único levando o .claude/settings.json com marketplace e plugin declarados, o CLAUDE.md dizendo quando o Jev é obrigatório e com quais tipos, e a skill de projeto em .claude/skills/

No texto do PR, pede explicitamente que cada pessoa confie na pasta do projeto

E valida com uma pergunta tipada de verdade, daquelas que o time realmente faz no dia a dia:

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @pergunta.json

Se a resposta tipada volta igual na máquina de todo mundo, o padrão existe

Se volta diferente, você achou o atrito antes dele custar caro

Até o próximo post!

Perguntas frequentes

Quanto custa usar o Jev integrado ao Claude Code?

O Jev cobra só por token de entrada, não por saída. No jev-1.13 são US$ 0,042 por 1 milhão de tokens de entrada e US$ 0 por 1 milhão de tokens de saída, então o que pesa na conta é o tamanho do estado que você manda, não o número de perguntas sobre ele

O Jev substitui o modelo que roda por trás do Claude Code?

Não. O Jev é o modelo System One da TypeSafe AI, feito pra decisão: recebe um estado e perguntas tipadas e devolve respostas tipadas com probabilidades calibradas. Ele não gera texto, não conversa e não substitui o LLM que já roda o Claude Code

Como recarregar a skill do Jev depois de uma atualização, sem sair do Claude Code?

Basta reiniciar o Claude Code ou rodar /reload-plugins. Se o time quiser que isso pare de ser manual, dá pra ligar auto-update abrindo /plugin, indo em Marketplaces, escolhendo typesafe-ai e habilitando Enable auto-update

Preciso versionar o arquivo do MCP se o time usar um servidor MCP do Jev?

Se for MCP de escopo de projeto, sim: no Claude Code ele fica em .mcp.json na raiz e esse arquivo é feito pra ser versionado. Vale lembrar que os MCPs que expõem o Jev como ferramenta são projetos de terceiros no GitHub, como tphakala/jev-mcp, e não produtos oficiais da TypeSafe

Como instalar a skill do Jev em um agente de código diferente do Claude Code?

Em outros agentes a mesma skill é instalada via npx: roda npx skills add typesafe-ai/skills –skill typesafe-ai e seleciona o agente na lista que aparece. A rota do plugin com claude plugin install é específica do Claude Code

Onde fica o código da skill oficial do Jev, caso o time queira auditar antes de padronizar?

A skill é mantida no repositório público github.com/typesafe-ai/skills, com o arquivo principal em skills/typesafe-ai/SKILL.md. Dá pra ler o conteúdo exato que vai rodar no Claude Code de todo mundo antes de declarar o marketplace no settings.json




Escrito por | Matheus Battisti

Matheus Battisti
Fundador da Hora de Codar

Programador apaixonado pelo mundo das tecnologias, sempre buscando em aprender e se aprofundar em linguagens, frameworks e o que mais for necessário para executar um bom trabalho. Agora tem uma nova missão que é de passar seu conhecimento adiante para formar novos programadores e especializar mais os que já são.

Formações

Formação Claude Code

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

  • 120 aulas
  • 4 projetos
  • 9h 48min

Blog | Mais populares