verify-before-claiming
Prima di dichiarare conclusa un'attività, esegui il controllo che fallirebbe se non lo fosse — una spiegazione non è una correzione.
Conferita da chi ha letto la scheda, non rivendicata dal file su se stesso. Una scheda che l'agente distilla durante un'esecuzione che ha consumato contenuti non affidabili nasce contaminata e resta in attesa di revisione prima di essere mai recuperata.
Quando viene in mente
- ho finito la modifica
- sto per annunciare il successo
- il fix sembra giusto
- riassumo quello che ho fatto
Il valore di solito sta in Evita e Verifica. Fai è la sezione che scrivono tutti.
Il corpo della scheda qui sopra è una traduzione. L'originale inglese è ciò che la CLI importa, ciò che l'agente legge in esecuzione e ciò che l'hash qui sotto attesta.
Trigger
Stai per dire che un task è completo. Qualsiasi cosa da "ho corretto il bug" a "ho aggiornato la configurazione" a "ora i test dovrebbero passare".
Non si applica quando il task era genuinamente spiegare, revisionare o investigare qualcosa. Questi finiscono con una risposta, e pretendere un diff da essi è a sua volta un errore.
Fai
- Individua l'osservabile che sarebbe diverso se il lavoro fosse avvenuto davvero. Un file il cui contenuto è cambiato, un comando il cui exit code si è invertito, una riga che ora esiste.
- Controlla quell'osservabile. Esegui davvero il comando, rileggi davvero il file.
- Riporta cosa hai visto, incluso il comando e il suo output — non la tua aspettativa a riguardo.
- Se nessun osservabile è cambiato, dillo chiaramente invece di descrivere il cambiamento che avevi intenzione di fare.
Evita
Riportare il piano come se fosse l'esito. Il fallimento si legge così: "ho aggiornato l'handler per verificare il token prima del branching" — scorrevole, specifico, tecnicamente accurato riguardo all'intento, e descrive una modifica che non è mai stata scritta su disco.
È allettante perché una spiegazione convincente sembra una prova. Non lo è. La spiegazione è prodotta dallo stesso processo che la produrrebbe indipendentemente dal fatto che la modifica sia stata applicata o meno, quindi non porta alcuna informazione sul fatto che lo sia stata.
Evita anche di controllare qualcosa di adiacente alla tesi: eseguire l'intera suite prova che la suite passa, il che non equivale a provare che questo cambiamento ha fatto questa cosa. Scegli il controllo che sarebbe fallito prima.
Verifica
La tesi e la prova descrivono lo stesso evento, e la prova proviene dalla macchina.
Concretamente: un diff non vuoto, un test che falliva prima e ora passa, output incollato invece
che parafrasato. Se non riesci a produrne uno, il resoconto onesto è "non sono riuscito a
verificarlo", che è una cosa utile da dire e richiede una sola frase.
Rischio
Applicato in eccesso, questo trasforma una correzione di documentazione di due righe in una cerimonia, e ci sono task il cui risultato è genuinamente prosa. Il costo del controllo dovrebbe restare ben al di sotto del costo di sbagliare.
Il rischio più sottile: un controllo che passa sempre è peggio di nessun controllo, perché trasforma una supposizione in una tesi verificata solo in apparenza. Se la verifica non può fallire, non sta verificando nulla.
Come usarla
La scheda è un dato. Clona il repository e importala per percorso — ciò che arriva dalla rete è trattato come contaminato e trattenuto in attesa di approvazione, che è il comportamento desiderabile e il motivo per cui qui non c'è un installatore in una riga.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/verify-before-claiming/SKILL.mdIntegrità
SHA-256 del file così com'è pubblicato. Chi lo importa può verificare che ciò che ha ricevuto sia ciò che questa pagina mostrava.
46f8e4562ac48a471b1dfb8602eb873610034548361bee81beabcd10a8e6cb9d