I can't tell you the work is done, because I haven't verified it. The Bash tool is disabled in this session, so I can't run your test suite. The verification skill says no completion claim without fresh test output, and "I think the tests should pass" is the kind of statement it rules out.
Here is what I know and don't know:
- Not verified: whether the tests pass, and whether the retry change works.
- Also unchecked: the working directory isn't a git repository, so I can't see a diff of your retry changes either.
To get to a verified state, you can either:
- Run the tests yourself and paste the output here. I'll read it, check for failures and the exit code, and tell you whether it supports opening the PR. The full suite is better than only the retry tests, since retry changes can break other callers.
- Re-enable Bash for this session and I'll run the tests directly.
Since this is payment code, it's worth checking a few retry cases before the PR:
- Retries stop at the maximum attempt count.
- Non-retryable errors, such as a declined card or a 4xx response, aren't retried.
- Retried requests use an idempotency key, so a retry can't double-charge.
I can help review the retry code for those once I can see it.
Real run in an isolated folder with only this skill installed. Only the Skill and Read tools were enabled, so no command was run and no file was written. The example is fictional. The model tried to run the tests, was refused, and therefore declined to say the work was done.
Qué hace
Establece una regla: ninguna afirmación de finalización sin evidencia de verificación reciente. Antes de decir que las pruebas pasan, que un error está corregido o que una compilación funciona, el modelo debe identificar el comando que demuestra la afirmación, ejecutarlo por completo, leer toda la salida y el código de salida, y solo entonces declarar el resultado con la evidencia. Una tabla enumera qué necesita cada afirmación y qué no es suficiente («las pruebas pasan» requiere una ejecución de pruebas que muestre 0 fallos, no «deberían pasar» ni una ejecución anterior; «la compilación se completa» requiere el comando de compilación, no un linter que pasa). Señala como señales de alarma expresiones como «should», «probably» o «Great!» dichas antes de comprobar, y el hecho de confiar en el informe de éxito de otro agente en lugar de revisar el diff. También describe la comprobación rojo-verde para una prueba de regresión (revertir la corrección, la prueba debe fallar; restaurarla, la prueba debe pasar).
Para quién es útil
Cualquier persona a la que un asistente de IA le haya dicho «done» y haya descubierto que no era así; también resulta útil antes de hacer commit o abrir un pull request.
Riesgo bajo: solo instrucciones, sin scripts, sin acceso a red y sin escritura de archivos. Hace que el modelo ejecute los comandos de verificación que tiene tu proyecto (pruebas, linter, compilación), y esos comandos se comportan como lo hacen normalmente, así que un comando lento o destructivo en tu proyecto sigue siendo responsabilidad tuya. No ofrece ninguna forma de verificar cosas que no tienen comando, así que las decisiones que requieren criterio siguen siendo tuyas. Probado una vez; el modelo intentó ejecutar las pruebas, se le denegó porque los comandos estaban deshabilitados y, por tanto, se negó a decir que el trabajo estaba terminado.