Como padronizar o uso do Jev no time que trabalha com Claude Code?
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_KEYdefinida 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
Curso de Jev: Sistemas Mais Inteligentes, Rápidos e Robustos
Desenvolva sistemas mais inteligentes, rápidos e robustos com Jev
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
- 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
- Declare marketplace e plugin no
.claude/settings.jsone 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
- Escreva no
CLAUDE.mdda 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 probabilidadescore: 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"
Curso RecomendadoDesenvolva sistemas mais inteligentes, rápidos e robustos com JevConhecer cursoIsso 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
- 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
- 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.jsonna 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
- 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…
- 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

Crie sistemas com IA para vender
Prompts, modelos e checklists para criar e publicar seu sistema com IA e preparar a oferta para o primeiro cliente.
Quero o e-book gratuito Receba o livro e os bônus no seu e-mail.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
Formações
Formação Claude Code
Domine Claude Code do absoluto zero até o avançado
- 120 aulas
- 4 projetos
- 9h 48min
Blog | Mais populares

Como montar um workflow de automação combinando decisões do Jev em código
Aprenda a montar um workflow com Jev: decisões tipadas encadeadas em código, alta confiança agindo sozinha e casos incertos escalando para revisão.

Jev decide, LLM escreve: como dividir os papéis dentro de um agente de IA
Jev é o modelo que decide, não escreve: entenda como dividir papéis entre Jev e LLM dentro de um agente de IA e quando usar cada um.

Para quem o Jev serve (e para quem não serve)?
Jev serve pra roteamento, scoring e guardrails em IA, não pra texto ou código. Veja pra quem o Jev serve e quando evitar.
