verify-before-claiming
Antes de informar que una tarea está hecha, ejecuta la comprobación que fallaría si no lo estuviera: una explicación no es un arreglo.
Conferida por quien revisó y leyó la tarjeta, no reclamada por el propio archivo. Una tarjeta que el agente destila durante una ejecución que consumió contenido no confiable nace contaminada y queda retenida para revisión antes de ser recuperada.
Cuándo viene a la mente
- terminaste el cambio
- a punto de reportar éxito
- el arreglo se ve correcto
- resumiendo lo que se hizo
Evita y Comprueba es donde suele estar el valor. Haz es la sección que todo el mundo escribe.
El cuerpo de la tarjeta de arriba es una traducción. El original en inglés es lo que importa la CLI, lo que lee el agente en ejecución y lo que atestigua el hash de abajo.
Disparador
Estás a punto de decir que una tarea está completa. Cualquier cosa desde «arreglé el bug» hasta «actualicé la configuración» hasta «las pruebas deberían pasar ahora».
No aplica cuando la tarea era genuinamente explicar, revisar o investigar algo. Esas terminan con una respuesta, y exigirles un diff es un error en sí mismo.
Haz
- Nombra el observable que sería distinto si el trabajo hubiera ocurrido. Un archivo cuyo contenido cambió, un comando cuyo código de salida se invirtió, una fila que ahora existe.
- Verifica ese observable. Ejecuta realmente el comando, lee realmente el archivo de vuelta.
- Reporta lo que viste, incluyendo el comando y su salida — no tu expectativa de ella.
- Si nada observable cambió, dilo con claridad en lugar de describir el cambio que pretendías hacer.
Evita
Reportar el plan como el resultado. El fallo se lee así: «Actualicé el handler para verificar el token antes de ramificar» — fluido, específico, técnicamente preciso sobre la intención, y describiendo una edición que nunca se escribió en disco.
Es tentador porque una explicación convincente se siente como evidencia. No lo es. La explicación es producida por el mismo proceso que la produciría tanto si la edición se aplicó como si no, así que no lleva información sobre si ocurrió o no.
Evita también verificar algo adyacente a la afirmación: ejecutar la suite completa prueba que la suite pasa, lo cual no es lo mismo que probar que este cambio hizo esta cosa. Elige la verificación que habría fallado antes.
Comprueba
La afirmación y la evidencia describen el mismo evento, y la evidencia proviene de la máquina.
Concretamente: un diff que no está vacío, una prueba que fallaba antes y ahora pasa, salida pegada en lugar de parafraseada. Si no puedes producir una, el reporte honesto es «no pude verificar esto», que es algo útil de decir y toma una sola frase.
Riesgo
Aplicado en exceso, esto convierte una corrección de documentación de dos líneas en una ceremonia, y hay tareas cuyo resultado genuinamente es prosa. El costo de la verificación debería mantenerse muy por debajo del costo de estar equivocado.
El riesgo más sutil: una verificación que siempre pasa es peor que ninguna verificación, porque blanquea una suposición convirtiéndola en una afirmación verificada. Si la verificación no puede fallar, no está verificando nada.
Cómo usarla
La tarjeta es un dato. Clona el repositorio e impórtala por ruta: lo que llega por la red se trata como contaminado y queda retenido a la espera de aprobación, que es el comportamiento deseable y la razón por la que aquí no hay un instalador de una línea.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/verify-before-claiming/SKILL.mdIntegridad
SHA-256 del archivo tal como se publicó. Quien lo importe puede comprobar que lo que recibió es lo que mostró esta página.
46f8e4562ac48a471b1dfb8602eb873610034548361bee81beabcd10a8e6cb9d