🛡️ Playbooks, Skills, Rules e Governança

Um procedimento reutilizável para uma tarefa recorrente, escrito como sequência de passos com entradas, saídas e critério de conclusão.

O playbook é o que torna o resultado repetível entre pessoas e entre agentes — e é onde o conhecimento do time para de depender de quem está de plantão.

Passos ordenados > princípios genéricos · Um playbook por tarefa recorrente · Ele evolui com o retorno da prática.

Ler a especificação → confirmar escopo → mapear impacto → criar plano → implementar mudança mínima → criar testes → executar quality gates → revisar → documentar → preparar pull request.

É o caminho padrão do trabalho novo. Ter isso escrito elimina a variação de qualidade entre a segunda e a sexta-feira.

Confirmar escopo antes de codar · Mapear impacto revela o que quebra · Documentar faz parte do pronto.

Reproduzir o erro → registrar evidência → identificar causa → criar teste que falha → implementar correção → executar regressão → revisar impacto → documentar.

A ordem importa: sem reprodução, você conserta o que imagina; sem teste que falha antes, não há prova de que o bug foi embora.

Reprodução é o primeiro passo · Teste que falha antes = prova · Regressão fecha o ciclo.

Mapear dependências → criar testes de caracterização → definir fronteira → criar adaptador → migrar módulo pequeno → executar em paralelo → comparar resultados → liberar gradualmente.

É a trilha 4 condensada em procedimento — o formato em que ela realmente é usada no dia a dia.

Um módulo por vez · Comparação antes da troca · Liberação gradual mantém a volta disponível.

Coletar logs → classificar gravidade → preservar evidências → identificar causa provável → criar mitigação → validar → aplicar correção → registrar aprendizado.

Sob pressão ninguém improvisa bem. O playbook é o que impede que a primeira reação apague a evidência do que aconteceu.

Preservar antes de agir · Mitigar ≠ corrigir · Aprendizado registrado vira regra ou gate.

A prática de revisar o playbook toda vez que ele falha na realidade — e de guardar no repositório, versionado como código.

Playbook que não é usado apodrece e passa a atrapalhar: o agente segue um procedimento que já não descreve o sistema.

Falhou na prática? atualize · Versionado no repositório · Poucos e bons > muitos e mortos.

Uma capacidade reutilizável que orienta o agente numa tarefa específica: analisar repositório, gerar especificação, criar plano, reproduzir bug, gerar testes, revisar arquitetura ou segurança, preparar PR.

Skill é o playbook em formato que o agente consome direto — deixa de ser você recolando o mesmo prompt toda semana.

Skill ≈ playbook executável · Uma tarefa por skill · Reuso reduz variação de qualidade.

Objetivo, quando usar, entradas, ferramentas, etapas, critérios de aceitação, ações proibidas, tratamento de falhas, formato da saída e verificações obrigatórias.

"Quando usar" e "ações proibidas" são os campos que separam uma skill útil de um prompt salvo — o primeiro faz o agente escolher certo, o segundo evita o dano.

Quando usar > o que faz · Formato de saída torna a skill componível · Verificação obrigatória fecha o loop.

O critério de priorização: comece pelas tarefas que você repete muito e que hoje saem com qualidade inconsistente.

Skill de tarefa rara é manutenção sem retorno. Skill de tarefa semanal se paga na primeira semana.

Repetição justifica empacotar · Variação alta = ganho alto · Comece com 3 a 5 skills, não 30.

Regras permanentes ou condicionais que limitam o comportamento dos agentes — nunca alterar testes para esconder falha, nunca inserir segredos, não fazer deploy sem aprovação, não refatorar fora do escopo.

Rules reduzem decisões arbitrárias. Elas não dependem de você lembrar de escrever a mesma proibição em cada tarefa.

Skill = capacidade, rule = limite · Regra vale em toda tarefa · Poucas e claras > muitas e ignoradas.

O núcleo duro: não expor segredos, preservar APIs públicas, não remover logs de segurança, não modificar banco de produção diretamente, produzir evidência dos testes.

São as regras cuja violação custa caro e é difícil de reverter — merecem estar escritas e, quando possível, viradas gate.

Regra crítica também vira verificação · API pública é contrato · Evidência é obrigação, não cortesia.

Regras que fixam limite de tentativas, teto de custo, exigência de aprovação antes de ações destrutivas e proibição de refatoração fora do escopo.

É onde a governança encontra o loop: a rule é a versão escrita e permanente dos limites que você configurou na trilha 2.

Limite escrito vale para todo agente · Destrutivo pede humano · Rule sem verificação depende de obediência.

O conjunto de controles que define como a IA pode operar dentro da empresa: identidade, permissões, responsabilidades, auditoria, logs, custos, ambientes, dados, ações proibidas e tratamento de incidentes.

Sem governança, a adoção acontece de qualquer jeito — e a organização descobre suas regras depois do primeiro incidente.

Governança habilita, não só proíbe · Controle escrito > norma implícita · Ela precisa caber no fluxo de trabalho.

Credencial própria, escopo mínimo de acesso, responsabilidades declaradas e trilha de auditoria por ação.

Agente rodando com a credencial pessoal de alguém torna impossível auditar e responsabilizar — e concede acesso que ninguém revisou.

Identidade própria sempre · Menor privilégio · Toda ação rastreável até quem autorizou.

Teto de gasto por equipe e por tarefa, ambientes autorizados para execução, quais dados podem entrar no contexto e política de retenção.

Dado pessoal ou segredo em contexto de terceiro é incidente de privacidade, não detalhe técnico — e custo sem teto vira surpresa no fechamento do mês.

Dado sensível não entra no contexto · Ambiente autorizado é lista curta · Custo por tarefa é métrica de gestão.

Nível 1 assistência (só sugere) · 2 execução supervisionada (cada ação importante aprovada) · 3 execução controlada (tarefas delimitadas com quality gates) · 4 autonomia operacional limitada (fluxos completos dentro de regras e ambientes) · 5 autonomia crítica.

O nível 5 não deve ser adotado sem controles extremamente rigorosos. Saber onde você está evita conversas confusas sobre "usar IA ou não".

O nível é por tipo de tarefa, não por empresa · Subir de nível exige o controle do anterior · Nível 5 é limite, não meta.

O processo de promover um tipo de tarefa a mais autonomia com base em números: taxa de aprovação sem correção, incidentes causados, custo por tarefa e tempo de revisão.

Autonomia concedida por empolgação volta atrás no primeiro susto — e aí o time perde também o que já funcionava.

Medir antes de promover · Piloto delimitado · Rebaixar também é decisão válida.

Um documento curto que responde: quem é o agente, o que pode acessar, o que pode fazer sozinho, o que exige aprovação, quanto pode gastar, o que é registrado e quem responde.

É o artefato que permite escalar o uso de IA para outros times sem repetir a discussão inteira a cada vez.

Uma página, não um manual · Revisão periódica · Sem dono, não existe governança.