verify-before-claiming
Antes de relatar uma tarefa como concluída, rode a checagem que falharia se não estivesse — uma explicação não é um conserto.
Conferida por quem revisou e leu o cartão, não reivindicada pelo próprio arquivo. Um cartão que o agente destila durante uma execução que consumiu conteúdo não confiável nasce contaminado e fica retido para revisão antes de alguma vez ser recuperado.
Quando ele vem à mente
- terminei a mudança
- prestes a anunciar sucesso
- a correção parece certa
- resumindo o que foi feito
Evite e Verifique são onde costuma estar o valor. Faça é a seção que todo mundo escreve.
O corpo do cartão acima é uma tradução. O original em inglês é o que a CLI importa, o que o agente lê em execução e o que o hash abaixo atesta.
Gatilho
Você está prestes a dizer que uma tarefa está completa. Qualquer coisa de "corrigi o bug" a "atualizei a config" a "os testes devem passar agora".
Não se aplica quando a tarefa era genuinamente explicar, revisar ou investigar algo. Essas terminam com uma resposta, e exigir um diff delas é, em si, um erro.
Faça
- Nomeie o observável que estaria diferente se o trabalho tivesse acontecido. Um arquivo cujo conteúdo mudou, um comando cujo código de saída se inverteu, uma linha que agora existe.
- Verifique esse observável. Rode o comando de fato, leia o arquivo de volta de fato.
- Reporte o que você viu, incluindo o comando e sua saída — não a sua expectativa sobre ela.
- Se nada observável mudou, diga isso claramente em vez de descrever a mudança que você pretendia fazer.
Evite
Reportar o plano como se fosse o resultado. A falha soa assim: "atualizei o handler para checar o token antes do branching" — fluente, específico, tecnicamente preciso quanto à intenção, e descrevendo uma edição que nunca foi escrita em disco.
É tentador porque uma explicação convincente parece evidência. Não é. A explicação é produzida pelo mesmo processo que a produziria independentemente de a edição ter sido aplicada ou não, então ela não carrega nenhuma informação sobre se aconteceu.
Evite também checar algo adjacente à afirmação: rodar a suíte inteira prova que a suíte passa, o que não é o mesmo que provar que esta mudança fez esta coisa. Escolha a checagem que teria falhado antes.
Verifique
A afirmação e a evidência descrevem o mesmo evento, e a evidência veio da máquina.
Concretamente: um diff que não está vazio, um teste que falhava antes e passa agora, uma saída
colada e não parafraseada. Se você não conseguir produzir uma, o relato honesto é "não consegui
verificar isso", que é uma coisa útil de dizer e cabe em uma frase.
Risco
Aplicado em excesso, isso transforma uma correção de documentação de duas linhas numa cerimônia, e há tarefas cujo resultado genuinamente é prosa. O custo da checagem deve ficar bem abaixo do custo de estar errado.
O risco mais sutil: uma checagem que sempre passa é pior que nenhuma checagem, porque ela transforma um chute numa afirmação verificada. Se a verificação não pode falhar, ela não está verificando nada.
Como usar
O cartão é dado. Clone o repositório e importe pelo caminho — o que chega pela rede é tratado como contaminado e fica retido para aprovação, que é o comportamento desejável e a razão de não haver um instalador de uma linha aqui.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/verify-before-claiming/SKILL.mdIntegridade
SHA-256 do arquivo como publicado. Quem importa pode conferir que o que recebeu é o que esta página mostrou.
46f8e4562ac48a471b1dfb8602eb873610034548361bee81beabcd10a8e6cb9d