🤖 Sub-agentes para Testar

Testes manuais de skills têm um defeito estrutural: você testa o caminho que você imaginou. Você criou a skill com uma intenção de uso em mente, e naturalmente vai testá-la nessa intenção. Os casos que você não imaginou — os edge cases, os usuários com perfis diferentes, as situações extremas — ficam invisíveis até que alguém os encontre na prática. Sub-agentes resolvem esse problema porque não têm o viés do criador. Eles simulam sistematicamente o espaço de possibilidades, incluindo os cenários que nenhum humano pensaria em testar. O resultado é uma cobertura de teste radicalmente mais ampla, com uma fração do tempo que testes manuais abrangentes demandariam.

UX friction é o atrito que surge quando uma skill é difícil de usar — quando o trigger não é intuitivo, quando as instruções assumem conhecimento que o usuário não tem, quando o output requer interpretação excessiva. O agente de UX friction simula múltiplos perfis de usuário e identifica sistematicamente esses pontos de atrito. Diferente de uma análise técnica, que pergunta "isso funciona?", o agente de UX friction pergunta "isso é fácil de usar para pessoas diferentes?" — uma distinção crítica porque uma skill pode ser tecnicamente correta e ainda assim ser praticamente inutilizável para qualquer pessoa além do criador.

Você vai simular 4 perfis de usuário tentando usar a skill abaixo.
Para cada perfil, relate: (1) como tenta acionar a skill, (2) onde
encontra atrito, (3) o que pode fazer de errado.

[COLE O CONTEÚDO COMPLETO DA SKILL AQUI]

## Perfil 1: Iniciante
- Tentativa de acionamento: Como alguém sem experiência tentaria usar?
- Pontos de atrito: O que seria confuso ou difícil de entender?
- Erros prováveis: O que poderia dar errado sem perceber?

## Perfil 2: Impaciente
- Tentativa de acionamento: Como alguém com pressa tentaria usar?
- Pontos de atrito: Quais etapas pareceriam desnecessárias?
- Erros prováveis: O que seria pulado com consequências negativas?

## Perfil 3: Perfeccionista
- Tentativa de acionamento: O que seria questionado antes de usar?
- Pontos de atrito: Quais ambiguidades gerariam paralisia?
- Erros prováveis: Onde a interpretação excessiva levaria ao lugar errado?

## Perfil 4: Expert
- Tentativa de acionamento: Como alguém avançado tentaria customizar?
- Pontos de atrito: O que pareceria excessivamente básico ou limitante?
- Erros prováveis: Onde a expertise levaria a comportamentos inesperados?

## Síntese
Liste os 5 principais pontos de atrito identificados em todos os perfis,
ordenados do mais crítico ao menos crítico.
Para cada um: o que causou, quem é mais afetado, como corrigir.

Enquanto o agente de UX friction foca na experiência do usuário, o agente de auditoria estrutural foca na arquitetura interna da skill. Ele analisa o fluxo de decisão, identifica redundâncias de instrução, mapeia os pontos onde a skill pode falhar silenciosamente (sem erro explícito, mas com resultado errado) e verifica se a skill tem scope creep — fazendo mais do que deveria. Problemas estruturais raramente aparecem em uso normal; eles aparecem nos casos que desafiam as suposições implícitas da skill. O agente de auditoria estrutural faz exatamente isso: testa as suposições, não o comportamento declarado, expondo fraquezas que ficam invisíveis no caminho feliz.

Sub-agentes bem configurados produzem relatórios detalhados — e relatórios detalhados sem triagem produzem paralisia. A habilidade de ler e priorizar os achados é tão importante quanto a habilidade de gerar os achados. O framework de classificação por impacto — high, medium, low — parece simples mas requer julgamento calibrado para ser aplicado corretamente. High impact não significa "sério", significa "afeta significativamente a utilidade da skill para casos de uso comuns". Low impact não significa "ignorar", significa "melhora desejável quando houver tempo". A distinção define onde você deve focar sua energia limitada de melhoria.

Com o relatório priorizado em mãos, o processo de correção tem uma lógica clara: começar pelos high impact, validar cada correção antes de avançar para a próxima, e manter um registro das mudanças feitas. A tentação é corrigir tudo de uma vez — mas correções em cascata sem validação intermediária introduzem novos problemas ao resolver os anteriores. A abordagem correta é cirúrgica: uma correção, um teste, um avanço. Esse ritmo parece mais lento, mas evita a situação de entregar uma skill "corrigida" que na prática está pior do que a versão original.

Para tornar o processo concreto, vamos percorrer uma sessão real de teste com sub-agentes, desde o dispatch inicial até a skill melhorada ao final. O exemplo usa a skill de reflexão de sessão como objeto de teste — uma skill simples o suficiente para ser entendida rapidamente, mas com complexidade suficiente para demonstrar os diferentes tipos de findings que os agentes produzem. Cada etapa da sessão é documentada com os inputs e outputs reais, mostrando exatamente como as decisões foram tomadas e por que. O objetivo é fornecer um template mental que você pode replicar em suas próprias sessões de melhoria.