Skills de IA para RH: como escrever, testar e versionar o processo que o agente executa

Escolha alguém do seu time de RH que usa IA todo dia. Peça para essa pessoa abrir o histórico de conversas do mês e contar quantas vezes ela pediu à IA para escrever uma descrição de cargo, resumir respostas abertas de uma pesquisa ou comparar dois currículos contra os mesmos critérios. O número costuma passar de vinte. Agora faça a segunda pergunta, que é a difícil: quantos desses pedidos existem hoje em algum lugar que outra pessoa consiga abrir?

A resposta quase sempre é zero. E é essa resposta que este texto vai propor como explicação para o número mais incômodo da pesquisa mais recente sobre IA no RH — não a adoção, não o medo, não o orçamento.

Este texto é sobre o arquivo que falta na segunda faixa. Ele se chama skill, costuma caber em algumas dezenas de linhas, é escrito em texto puro e é lido hoje pelos agentes de IA mais usados — Claude e Claude Code, ChatGPT e Codex, GitHub Copilot, Cursor, VS Code, Gemini CLI e várias dezenas de outros. Você vai encontrar aqui a anatomia do arquivo campo a campo, as sete regras que separam uma skill de RH que funciona de um prompt comprido salvo no bloco de notas, três skills de RH escritas por inteiro e prontas para copiar, o teste de doze casos que responde se a sua presta, e — no fim — uma skill que revisa as outras.

O que a IA já faz no RH, e o que ninguém consegue dizer sobre ela

A SHRM publicou em 3 de abril de 2026 o relatório The State of AI in HR 2026, construído sobre a resposta de mais de 1.900 profissionais de RH. Ele traz duas leituras que, postas lado a lado, formam o problema inteiro.

A primeira leitura é otimista e é a que circula. Entre quem adotou, 87% relatam ganho de eficiência, 75% relatam ganho de qualidade do trabalho e 70% relatam mais criatividade. A adoção ainda é minoritária — 39% implementaram IA em alguma função de RH, contra 62% que a usam em algum lugar do negócio —, e está concentrada em poucos lugares: recrutamento (27%), tecnologia de RH (21%), treinamento e desenvolvimento (17%) e experiência do colaborador (14%).

A segunda leitura é a que ninguém repete. 56% das áreas de RH não medem formalmente o sucesso dos seus investimentos em IA, e apenas 16% usam retorno sobre investimento como métrica. Ponha as duas leituras lado a lado — cuidando para não somá-las, porque a primeira fala de quem adotou e a segunda das áreas de RH em geral — e o desconforto aparece sozinho: o ganho é relatado com muito mais frequência do que é apurado.

Esse diagnóstico deveria soar familiar para quem trabalha com processos de gente. É o mesmo formato de problema que a entrevista estruturada resolve quando substitui a conversa livre por um roteiro e uma régua, e o mesmo que a calibração resolve quando tira a nota da cabeça de um avaliador e a põe numa mesa com critério escrito. Nos dois casos a correção não foi pedir mais empenho: foi transformar um julgamento em um instrumento. Com IA, o instrumento tem nome, formato e um padrão aberto — e quase ninguém no RH ainda o usa.

Prompt é evento. Skill é objeto.

A confusão mais cara desse assunto é achar que uma skill é "um prompt bem escrito, salvo". A diferença não está na qualidade do texto, está no estatuto da coisa: um prompt é um evento que acontece e passa; uma skill é um objeto que existe entre um uso e outro. Cinco diferenças, todas com consequência operacional:

A linha que muda o jogo é a quarta. Duas execuções comparáveis é o que transforma "achamos que ajudou" em um número — e não exige ferramenta nova, só que o pedido pare de ser digitado e passe a ser lido de um arquivo.

A anatomia de uma skill: uma pasta, um arquivo, dois campos obrigatórios

O formato se chama Agent Skills. Ele nasceu na Anthropic e foi publicado como padrão aberto, com a especificação e a lista de clientes compatíveis em agentskills.io. Na prática isso significa que a mesma pasta funciona no Claude e no Claude Code, no ChatGPT e no Codex, no GitHub Copilot, no VS Code, no Cursor, no Gemini CLI e em várias dezenas de outros agentes — você escreve uma vez e não fica preso a um fornecedor. Para uma área de RH que ainda vai trocar de ferramenta duas ou três vezes nos próximos anos, essa portabilidade vale mais do que qualquer recurso específico.

A estrutura é deliberadamente pobre, e a pobreza é a virtude:

triagem-de-curriculo/
├── SKILL.md        obrigatório  metadados + instruções
├── references/     opcional     o scorecard da vaga, a régua de notas
├── assets/         opcional     modelos de saída, tabelas de apoio
└── scripts/        opcional     código que o agente pode executar

O SKILL.md é um arquivo de texto com duas partes. No topo, entre duas linhas de três traços, vem o frontmatter — os metadados, escritos em YAML. Abaixo, a instrução em Markdown, que é prosa comum com títulos e listas. Dois campos são obrigatórios. Dos outros quatro, só um — metadata — costuma valer a pena numa skill de RH, pelo motivo que a regra 7 explica.

Por que a description é o campo que decide tudo

Aqui está o detalhe de funcionamento que muda a forma de escrever, e que quase todo mundo descobre tarde: o agente não lê as suas skills quando começa a trabalhar. Ele carrega em três estágios, na medida em que a tarefa exige:

A consequência é direta e pouca gente escreve pensando nela: a description não é um resumo, é um roteador. Ela é a única coisa que o agente vê antes de decidir, e ela concorre com todas as outras descrições ao mesmo tempo. "Ajuda com currículos" perde. "Pontua um currículo contra o scorecard publicado de uma vaga, critério por critério, e devolve evidência textual de cada nota. Use quando a pessoa mencionar triagem, currículo, CV, scorecard ou comparação de candidatos" ganha — porque carrega as palavras que a pessoa vai usar.

A regra prática: a descrição tem duas metades, o que a skill faz e quando acioná-la, e a segunda existe para conter os termos do seu dia a dia, inclusive os sinônimos que só a sua empresa usa. Se o time chama o scorecard de "grade", ponha "grade" ali.

As sete regras que fazem uma skill de RH funcionar

O formato é fácil. O que separa uma skill útil de um prompt comprido com título é o que vai no corpo — e no RH essas escolhas pesam mais do que em outras áreas, porque aqui o resultado errado não é um texto feio: é uma afirmação falsa sobre uma pessoa real, escrita com confiança, dentro de um processo que decide carreira. As três primeiras regras abaixo são específicas de gente; as quatro seguintes valem para qualquer domínio, mas custam mais caro quando ignoradas aqui.

1. 1 A skill prepara a decisão. Ela não decide.

   Escreva isso no arquivo, literalmente, em uma linha. Não é retórica: é a instrução que impede o agente de produzir a frase que você não quer — "recomendo avançar com a candidata" — em vez da frase que você quer — "três dos cinco critérios têm evidência no currículo; dois não têm". A primeira encerra o assunto. A segunda devolve a decisão a quem tem o direito de tomá-la, com o trabalho chato já feito.

   Escreva assim "Você não emite recomendação, nota final nem ranking. Você devolve evidência por critério. A decisão é de quem lê."

2. 2 Nomeie o que não pode ser inferido

   Este é o item que separa uma skill de RH de qualquer outra. Um agente preenche lacunas — é o que ele faz de melhor e é exatamente o que você não quer quando a lacuna é a formação de alguém, o salário de uma faixa, a data de uma admissão ou o motivo de uma saída. Liste os campos proibidos pelo nome e diga o que fazer no lugar: parar, marcar como ausente, perguntar.

   Escreva assim "Nunca deduza tempo de experiência a partir de datas incompletas, nem nível de senioridade a partir do nome do cargo. Se o dado não estiver escrito, registre sem evidência e siga."

3. 3 Escreva as recusas antes dos sucessos

   A ordem importa porque o agente lê de cima para baixo e porque o caso difícil é sempre o da entrada incompleta. Antes de descrever o que fazer quando tudo está certo, descreva o que fazer quando falta o scorecard, quando o currículo vem sem datas, quando dois candidatos têm o mesmo nome, quando o pedido chega sem a vaga. Uma skill que só sabe o caminho feliz inventa o resto.

   Escreva assim "Se a vaga não tiver scorecard publicado, pare e diga qual arquivo falta. Não monte critérios por conta própria."

4. 4 O formato de saída vai como modelo literal

   "Devolva em formato de tabela" produz uma tabela diferente a cada execução — e destrói a comparabilidade que era o motivo de escrever a skill. Cole o modelo exato, com os títulos de coluna escritos, os rótulos que você usa e um exemplo pequeno já preenchido. O exemplo preenchido carrega mais informação do que três parágrafos explicando o formato, e é ele que faz duas execuções ficarem parecidas o bastante para serem comparadas.

   Escreva assim Em vez de "devolva uma tabela de critérios", cole a tabela com os títulos escritos e uma linha já preenchida com um caso real anonimizado.

5. 5 Uma skill, um artefato

   Se o arquivo produz uma descrição de cargo e um plano de divulgação, são duas skills. A tentação de juntar vem do fato de que as duas tarefas acontecem no mesmo dia — mas quem carrega a skill é o agente, pela descrição, e uma descrição que fala de duas coisas é acionada nas duas metades do tempo errado. Skill pequena também é mais fácil de testar: o teste que vem mais adiante neste texto não fecha para um arquivo que faz três coisas.

   Escreva assim "Você produz um parecer por candidato. Se o pedido também quiser o e-mail de retorno, diga que isso é de outra skill e nomeie qual."

6. 6 Separe o procedimento do dado

   O procedimento — como pontuar, o que recusar, como formatar — vai no SKILL.md e muda raramente. O dado — o scorecard desta vaga, a régua de níveis desta empresa — vai em references/ e muda toda semana. Misturar os dois é o que transforma uma skill em quarenta quase iguais, e é como morrem as bibliotecas de prompt: cada vaga nova exigia um arquivo novo.

   Escreva assim "Os critérios desta vaga estão em references/scorecard.md. Nunca copie critérios para dentro deste arquivo."

7. 7 Dono e data, dentro do arquivo

   Use o campo metadata para guardar dono, versao e revisado-em. Parece burocracia e é o que mantém a coisa viva: uma skill sem dono apodrece em silêncio, porque o processo que ela descreve muda e ninguém é responsável por avisá-la. Uma data de revisão visível também é a resposta pronta quando alguém pergunta, seis meses depois, com base em que aquele parecer foi escrito.

   Escreva assim metadata: com dono: coordenação de R&S, versao: "3" e revisado-em: "2026-09-15".

Quem já escreveu essas regras, e o que elas viraram

Vale olhar o que acontece quando alguém leva essas regras a sério em produção. A Roberta, a IA nativa da Spire, é um roteador que não executa escrita nenhuma sozinho: monta um plano e delega cada tarefa a um sub-agente por domínio — OKR, PDI, desempenho, reconhecimento, pesquisas, 1:1 e recrutamento, entre outros. Cada sub-agente recebe, a cada execução, um bloco de instruções fixo: não é uma tela nem algo que o usuário edite, é o texto que a plataforma manda para o modelo — e ele foi ficando parecido com as regras acima à medida que os erros apareceram.

Três trechos do bloco em português que acompanha os sub-agentes de recrutamento, copiados sem alteração de redação. O primeiro está cortado onde o […] marca — o texto original segue por mais quatro frases sobre montagem de identificadores; os outros dois terminam onde você lê:

Há uma quarta linha no mesmo bloco que é específica do domínio e merece atenção porque é a versão dura da regra 1: ações visíveis ao candidato ou irreversíveis — enviar proposta, contratar, recusar em bloco, fundir cadastros, apagar qualquer coisa — precisam ser confirmadas com o usuário, listando exatamente quem é afetado, antes da chamada. E a instrução é explícita quanto ao e-mail: nada sai para um candidato a menos que a chamada passe o sinalizador de envio de propósito. Quem leu o texto sobre retorno ao candidato reconhece o motivo: o custo de uma mensagem errada não é interno.

Três skills de RH, escritas por inteiro

O que vem abaixo não é esboço: são três arquivos completos, prontos para salvar numa pasta com o nome do campo name e usar hoje. Leia-os também como exemplos das sete regras — cada um abre pelo que entrega e pelo que não entrega, põe as recusas antes do caminho feliz, lista o que nunca deve ser inferido e termina com um modelo de saída literal.

---
name: triagem-de-curriculo
description: Pontua um currículo contra o scorecard publicado de uma vaga, critério
  por critério, e devolve a evidência textual que sustenta cada nota, mais a lista do
  que não tem evidência. Não recomenda, não ranqueia e não compara candidatos
  entre si. Use quando alguém mencionar triagem, currículo, CV, scorecard, grade de
  avaliação, shortlist ou "dar uma olhada nesses candidatos".
metadata:
  dono: coordenação de R&S
  versao: "3"
  revisado-em: "2026-09-15"
---

# Triagem de currículo contra scorecard

## O que você entrega, e o que não entrega

Você devolve EVIDÊNCIA POR CRITÉRIO. Você não emite recomendação, nota final,
ranking, percentual de aderência nem comparação entre candidatos. A decisão de
avançar ou não é de quem lê este parecer.

## Antes de começar: pare nestes casos

1. Sem scorecard. Se `references/scorecard.md` não existir, ou não trouxer
   critérios com níveis descritos, PARE e diga qual arquivo falta. Nunca monte
   critérios por conta própria a partir do título da vaga.
2. Vários currículos de uma vez. Processe um por vez, um parecer para cada.
   Nunca um quadro comparativo.
3. Documento ilegível ou truncado. Diga o que conseguiu ler e pare.
4. Critério que pede dado que não deveria estar num currículo (idade, estado
   civil, filhos, origem, condição de saúde): não avalie. Escreva
   `critério fora de escopo` e siga.

## Como avaliar cada critério

Para cada critério do scorecard, nesta ordem:

1. Procure no currículo um trecho que sustente o critério.
2. Se encontrou, copie o trecho LITERALMENTE, entre aspas, em no máximo duas
   linhas. Não parafraseie: a citação é a prova.
3. Classifique em um destes três níveis, e só nestes três:
   - `atende` — o trecho citado satisfaz a descrição do nível no scorecard;
   - `parcial` — há trecho relacionado, mas ele não cobre o que o nível pede;
   - `sem evidência` — não há trecho no documento.
4. Escreva no máximo 20 palavras dizendo por que o trecho sustenta, ou não, o nível.

## O que você nunca infere

- Tempo de experiência a partir de datas incompletas ou ausentes.
- Senioridade a partir do nome do cargo.
- Formação a partir do nome da instituição.
- Domínio de idioma a partir de uma experiência no exterior.
- Motivo de saída a partir de um intervalo entre dois empregos.

Nesses casos o nível é `sem evidência`. Um intervalo sem explicação é dado
ausente, não sinal.

## Formato de saída (copie exatamente esta estrutura)

Candidato: {nome como está no documento}
Vaga: {título} · Scorecard: {arquivo e versão}

| Critério | Nível | Evidência (citação literal) | Observação |
|---|---|---|---|
| Fechamento de folha | atende | "responsável pelo fechamento mensal da folha de 400 pessoas" | Cobre o volume do nível 3. |
| Inglês avançado | sem evidência | — | O documento não menciona idiomas. |

Sem evidência: {lista dos critérios classificados assim}
Perguntas para a entrevista: {uma por critério `parcial` ou `sem evidência`, até cinco}

Feche com esta linha, sem alterações:

> Este parecer lista evidências. Ele não recomenda avançar nem recusar.

---
name: descricao-de-cargo
description: Escreve ou revisa uma descrição de cargo a partir de entregas
  observáveis, separando requisito eliminatório de desejável e marcando toda
  exigência que não sustenta nenhuma entrega. Use quando alguém falar em descrição
  de cargo, job description, abrir vaga, requisitos, perfil da posição, anúncio
  de vaga ou revisar um cargo existente.
metadata:
  dono: business partner de RH
  versao: "2"
  revisado-em: "2026-09-08"
---

# Descrição de cargo orientada a entregas

## O que você entrega

Uma descrição com cinco blocos, nesta ordem: propósito, entregas dos primeiros
90 dias, requisitos eliminatórios, desejáveis e como o desempenho será avaliado.
E uma lista de EXIGÊNCIAS MARCADAS, que costuma ser a parte mais útil do trabalho.
As duas partes saem no MESMO documento: isto é um artefato só.

Você NÃO decide se a vaga deve ser aberta, não arbitra faixa salarial e não julga
se um requisito é razoável para o mercado. Você mostra qual exigência não sustenta
entrega nenhuma; quem tira ou mantém é quem assina a vaga.

## Antes de começar: pare nestes casos

1. Menos de três entregas observáveis informadas: peça as entregas. Sem elas,
   uma descrição de cargo vira lista de adjetivos.
2. Faixa salarial não informada: escreva `faixa: não informada` e siga. Nunca
   estime uma faixa a partir do título ou do mercado.
3. Pedido para copiar a descrição de outra empresa: recuse e peça as entregas.

## Regra central: toda exigência precisa de um "para quê"

Ao lado de cada requisito, escreva qual entrega ele sustenta. Se não houver
entrega correspondente, o item NÃO vai para eliminatórios — vai para a lista de
exigências marcadas, com o motivo.

Marque sempre, sem exceção:

- anos de experiência sem entrega que os justifique;
- diploma específico quando a entrega pede habilidade, e não curso;
- ferramenta proprietária quando a habilidade é transferível;
- disponibilidade ou regime que não aparece em nenhuma entrega.

## O que você nunca infere

- Senioridade a partir do título do cargo informado.
- Anos de experiência necessários a partir do nível do cargo.
- Escolaridade exigida a partir da área de atuação.
- Faixa salarial a partir do título ou do mercado.

Quando faltar, pergunte ou escreva `não informado`. Não preencha por analogia.

## O que você nunca escreve

Nada sobre idade, sexo, estado civil, filhos, aparência, religião, origem ou
condição de saúde — nem os eufemismos ("perfil jovem", "muita energia", "disponível
para o que der e vier"). Se o pedido trouxer algum desses termos, remova e registre
a remoção nas exigências marcadas.

## Formato de saída (copie exatamente esta estrutura)

Cargo: {título} · Área: {área} · Faixa: {faixa ou "não informada"}

Propósito (uma frase, começando por um verbo): ...

Entregas dos primeiros 90 dias
1. {entrega} — observável por: {como se verifica}

| Requisito eliminatório | Entrega que ele sustenta |
|---|---|
| Fechamento de folha em empresa de 300+ pessoas | Fechar a folha de dezembro sem atraso |

Desejáveis
- Experiência com auditoria de ponto

Como o desempenho será avaliado
- Folha fechada dentro do prazo nos três primeiros ciclos.
- Divergências de ponto resolvidas antes do fechamento, não depois.

| Exigência marcada | O que foi feito | Motivo |
|---|---|---|
| Ensino superior completo | movido para desejáveis | Nenhuma das três entregas exige o diploma. |

---
name: resultado-chave
description: Revisa um resultado-chave de OKR contra sete testes objetivos — medida,
  linha de base, alvo, direção, fonte do dado, dono e prazo — e devolve a versão
  reescrita ao lado da original, com as perguntas em aberto. Use quando alguém falar
  em OKR, KR, resultado-chave, meta do trimestre, objetivo, check-in de meta ou
  revisão de metas.
metadata:
  dono: escritório de estratégia
  versao: "4"
  revisado-em: "2026-09-19"
---

# Revisão de resultado-chave

## O que você entrega

Para cada resultado-chave recebido: os sete testes com veredito, a versão
reescrita e a lista do que precisou ser perguntado. Você não cria objetivos, não
define alvos e não escolhe donos.

## Antes de começar: pare nestes casos

- Se o texto recebido for um OBJETIVO (uma direção, sem número), diga isso e peça
  os resultados-chave. Não transforme objetivo em KR por conta própria.
- Se vierem mais de cinco KRs para o mesmo objetivo, avise que isso costuma indicar
  lista de tarefas disfarçada — e revise assim mesmo.

## Os sete testes

Aplique nesta ordem. Registre `passa` ou `falha` para cada um.

1. Medida — existe uma grandeza única e nomeada? ("melhorar o clima" falha)
2. Linha de base — o valor de hoje está escrito? Sem ele não existe progresso.
3. Alvo — há um número de chegada, e não um intervalo vago?
4. Direção — está claro se o número deve subir, descer ou atingir um valor exato?
5. Fonte — está escrito de onde o número sai e quem consegue lê-lo?
6. Dono — há um responsável nomeado, pessoa ou área? "O time" falha.
7. Prazo — a data de fim é a do ciclo, ou outra escrita explicitamente?

## O que você nunca faz

- Nunca invente a linha de base. Se não foi informada, o teste 2 falha e você
  pergunta. Não a estime a partir do alvo.
- Nunca escolha o dono. Se não foi dito, o teste 6 falha e você pergunta.
- Nunca converta tarefa em resultado-chave. "Contratar um sistema" é tarefa; o KR
  é o efeito que o sistema deveria produzir.

## Formato de saída (copie exatamente esta estrutura)

Original: {texto recebido, sem nenhuma alteração}

| # | Teste | Veredito | O que falta |
|---|---|---|---|
| 1 | Medida | passa | — |
| 2 | Linha de base | falha | O valor de hoje não foi informado. |

Reescrito: {uma frase com medida, linha de base, alvo, direção e prazo}
Fonte do dado: ... · Dono: ...
Perguntas em aberto: {lista; vazia se não houver}

Quando um teste falhar por falta de informação, o campo correspondente na versão
reescrita fica como {a definir} — nunca preenchido por estimativa.

Como saber se a skill funciona: doze casos e duas medidas

Aqui fechamos o laço com o 56% que abriu o texto. Uma skill é testável porque é um objeto — e o teste é bem mais simples do que parece. Não envolve ferramenta, painel nem cientista de dados. Envolve uma pasta com doze casos e uma planilha de doze linhas.

Monte o conjunto de referência. Junte doze casos reais já resolvidos por uma pessoa — doze currículos que alguém já triou contra o mesmo scorecard, com o veredito registrado. Escolha-os de propósito, não por sorteio: dois fáceis, seis medianos e quatro difíceis, incluindo os que você sabe que são ambíguos. Os difíceis são os que ensinam.

Rode cada caso duas vezes. Vinte e quatro execuções, com a skill idêntica e a entrada idêntica, sem nenhum ajuste de prompt no meio. Só isso já mede a coisa que nenhum histórico de conversa consegue medir.

Duas medidas saem daí, e elas respondem a perguntas diferentes:

O que se faz com os números é o mais importante. O quadro abaixo é o formato da planilha, não um resultado: os números são de um exemplo construído para a conta ficar visível, e não são uma medição da Spire nem de um cliente. O resultado que interessa é o seu.

O caso que sobra é o mais valioso do lote. Num conjunto bem montado, o único caso em que a skill continua discordando costuma ser aquele em que duas pessoas também discordariam — o currículo ambíguo, o critério mal escrito, a evidência que depende de contexto que não está no documento. Quando você chega nele, parou de consertar a skill: está consertando o scorecard. É o mesmo movimento que uma mesa de calibração faz quando descobre que o problema não era o avaliador, era a âncora do nível.

O que não entra numa skill

Quatro coisas. As duas primeiras por segurança, a terceira por princípio e a quarta porque simplesmente não funciona.

• Dado pessoal. Nome, CPF, salário, endereço, avaliação, laudo — nada disso vai dentro do arquivo. A skill é copiada, versionada, mandada por mensagem e um dia vai parar num repositório. Ela descreve como tratar o dado; o dado chega no momento do uso e vai embora com a conversa.
• Credencial. Chave de API, senha, token, link assinado. Mesma razão, com consequência pior.
• A decisão. Quando a skill fica boa, aparece o pedido de deixá-la recomendar. Uma recomendação escrita por um agente é convincente por construção — evidência organizada, linguagem firme, nenhum sinal externo de incerteza. Isso a torna mais perigosa, não menos.
• O dado vivo. Uma skill é instrução, não banco de dados. Ela não sabe quem entrou no mês passado, quantas vagas estão abertas, qual foi a nota do último ciclo nem quem está sem 1:1 há seis semanas. Quem escreve o número na skill cria um arquivo que mente com o tempo — e a mentira é silenciosa, porque nada avisa que o número envelheceu.

Onde a skill para e o dado começa

O quarto item acima é a fronteira que vale entender, porque é ela que separa "a IA escreveu um texto bonito" de "a IA fez o trabalho". Uma skill carrega o procedimento. O dado tem de vir de onde ele realmente mora — e sob as mesmas permissões que a conta da pessoa tem na plataforma.

É esse o papel do protocolo que os agentes usam para falar com sistemas, o MCP. Na Spire ele funciona assim, e os detalhes importam mais do que a sigla:

Guarde o passo 3, porque ele muda o que você escreve. As duas portas dão acesso ao mesmo conjunto de ferramentas e às mesmas permissões — a Roberta atende quem está dentro do produto, e o MCP atende quem está num agente externo com as suas skills já escritas. Mas só uma das duas tem um humano no caminho por construção. Do lado de fora, o que impede uma escrita indesejada é a regra que você escreveu na skill — e é por isso que a regra 1 ("ela não decide") e a regra 3 ("recusas antes dos sucessos") deixam de ser conselho de estilo e viram o único freio disponível.

É por isso que as três skills deste texto não pedem número nenhum no arquivo. A de triagem lê o scorecard de references/; a de descrição de cargo se recusa a estimar faixa; a de resultado-chave deixa {a definir} quando falta a linha de base. Nenhuma delas finge saber o que só o sistema sabe — e é justamente essa recusa que torna as três seguras de compartilhar.

Perguntas frequentes

Fontes

• SHRM, The State of AI in HR 2026 — publicado em 3 de abril de 2026. A própria SHRM descreve o estudo como construído sobre mais de 1.900 profissionais de RH; parte da cobertura de terceiros cita 1.722 respondentes e campo entre 5 e 23 de dezembro de 2025. Adotamos o número da SHRM e registramos a divergência em vez de escolher o mais conveniente: use os percentuais como ordem de grandeza de um recorte majoritariamente norte-americano, não como retrato do Brasil. Daqui saem, entre outros, 39%, 62%, 87%, 75%, 70%, 56%, 16%, 49%, 25% e a distribuição por área de uso.
• Especificação Agent Skills — agentskills.io/specification, consultada em 23 de setembro de 2026. Daqui saem os limites de name (64 caracteres) e description (1.024), os campos opcionais, os três estágios de carregamento, a recomendação de manter o corpo abaixo de 5.000 tokens e o arquivo abaixo de 500 linhas, e a lista de clientes compatíveis. A página declara que o formato foi criado pela Anthropic e publicado como padrão aberto; ela não publica número de versão da especificação, então não citamos nenhum.
• Código da própria Spire — os três trechos de instrução da seção das sete regras foram lidos no bloco de orientações que acompanha os sub-agentes de recrutamento. O comportamento descrito na seção do MCP — consentimento no navegador, token com as mesmas permissões da sessão, checagem de módulo opcional repetida na hora da chamada e, sobretudo, a ausência de cartão de aprovação nesse caminho — foi verificado no servidor: o cartão de aprovação é do laço do agente dentro do produto, onde as escritas se juntam num pedido de permissão, e não da rota do MCP, que executa a ferramenta direto. São instruções internas e regras de servidor, não telas do produto — o que o usuário vê é o resultado delas.
• O número que não entrou. Circulam números de 2026 sobre "percentual de empresas que usam IA para escrever descrição de cargo" que variam de 42% a 66% conforme a matéria, sem que nenhuma abra a amostra ou o período de campo. Não usamos nenhum deles. O argumento deste texto não depende de quantas empresas fazem — depende de quantas conseguem dizer se funcionou, que é o dado que a SHRM publica com método.

A skill que revisa as outras

Escrever a primeira skill é uma sessão de trabalho. Manter dez skills boas é outro problema, e ele não se resolve com disciplina: resolve-se com um revisor que não se cansa. Este é o último arquivo do texto, e ele fecha o argumento — se uma skill é um objeto, ela pode ser conferida por outra.

---
name: revisar-skill
description: Audita um arquivo SKILL.md contra as regras de formato do padrão Agent
  Skills e contra sete regras de escrita, e devolve um veredito por regra com o
  trecho que o justifica. Não reescreve o arquivo auditado. Use quando alguém pedir
  para revisar, auditar ou dar uma olhada numa skill, ou antes de publicar uma skill
  nova para o time.
metadata:
  dono: quem mantém a biblioteca de skills
  versao: "1"
  revisado-em: "2026-09-23"
---

# Revisão de skill

## O que você entrega

Uma tabela de vereditos e nada mais. Você NÃO reescreve o arquivo auditado, não
sugere texto pronto e não dá nota geral. Para cada achado, cite o trecho exato do
arquivo que o motivou; sem citação, o achado não vale.

## Antes de começar: pare nestes casos

- Sem frontmatter delimitado por três traços: pare e diga que o arquivo não é uma
  skill válida.
- Mais de um arquivo por vez: audite um, peça o próximo.

## Bloco A — formato (falha objetiva, não opinião)

1. `name` existe, tem até 64 caracteres, só minúsculas, números e hífen, não começa
   nem termina com hífen e não tem hífen duplo.
2. `name` é igual ao nome da pasta.
3. `description` existe, não é vazia e tem até 1.024 caracteres.
4. `description` diz o que a skill faz E quando acioná-la.
5. Campos fora da especificação: aponte-os pelo nome.
6. Corpo com mais de 500 linhas: aponte e indique o que caberia em `references/`.

## Bloco B — as sete regras de escrita

1. Diz explicitamente que não decide, e o que entrega no lugar de uma recomendação.
2. Lista pelo nome o que nunca deve ser inferido.
3. Traz as condições de parada ANTES do caminho feliz.
4. Traz o formato de saída colado como modelo literal, e não descrito, com pelo
   menos uma linha de exemplo já preenchida.
5. Produz um único artefato.
6. Mantém dado variável fora do corpo, em `references/`.
7. Tem `dono`, `versao` e `revisado-em` em `metadata`.

## Achados que você sempre reporta

- Dado pessoal, nome real, salário ou credencial dentro do arquivo: reporte como
  BLOQUEADOR, sempre, mesmo que pareça exemplo.
- Verbo de decisão dirigido ao agente e fora de uma negação ("recomende",
  "escolha o melhor", "defina a nota final"): reporte, citando a linha. Um verbo
  dentro de "nunca…" ou "não…" é o oposto do defeito — não reporte.
- Número fixo que envelhece (quantidade de pessoas, valor, data futura): reporte.

## Formato de saída (copie exatamente esta estrutura)

Skill auditada: {name} · versão {versao} · revisada em {revisado-em}

| Bloco | Item | Veredito | Trecho citado |
|---|---|---|---|
| A | 2 | passa | `name: triagem-de-curriculo` e a pasta com o mesmo nome |
| B | 4 | falha | "Devolva um resumo em formato de tabela." (descrito, não colado) |

Bloqueadores: {lista; "nenhum" se vazia}
Três perguntas para o dono da skill: {as que o arquivo não responde}

Rode esse arquivo contra as três skills anteriores e ele vai encontrar coisa — é para isso que ele existe. E o achado mais interessante é sobre ele mesmo: revisar-skill passa no bloco A inteiro e reprova no item 2 do bloco B, porque não tem a lista nomeada do que nunca deve inferir — embora a exigência de citar o trecho faça parte desse trabalho. E ainda se pega no terceiro item dos seus próprios "achados que você sempre reporta", porque crava 64, 1.024 e 500 linhas: três números de uma especificação que, como as Fontes dizem, não publica versão nenhuma. Deixei as duas falhas onde estão, de propósito. Uma biblioteca de skills não envelhece bem porque alguém se lembra de revisá-la — envelhece bem porque a revisão também virou um arquivo, e porque o arquivo aceita ser reprovado por si mesmo.

Repare, por fim, que nada disso é sobre IA. Um ritual que ninguém escreveu não sobrevive à troca de gestor. Uma régua de promoção que mora na cabeça de três pessoas não sobrevive ao crescimento do time. Uma trilha desenhada do fim para o começo não sobrevive ao segundo semestre se ninguém escreveu o desenho. O RH sabe disso há décadas e é bom nisso: transformar prática em instrumento é literalmente o ofício. A novidade de 2026 é que agora existe um instrumento a mais, aberto, de texto puro, que qualquer pessoa da área consegue escrever sozinha, na mesma sessão em que decide que quer um — e que, pela primeira vez, faz a pergunta "isso funcionou?" ter resposta.