Tu primera tarea no necesita un prompt perfecto.

Lo importante no es formular una orden impecable. Es decir qué quieres conseguir y qué no puedes permitirte romper. Esta guía recorre el intake entero de una tarea real — la migración de pagos a Stripe — con todos los artefactos que produces tú y que produce el sistema.

1. Empieza con una intención concreta

Esto es todo lo que escribe el usuario. Con faltas, sin estructura, tal cual:

«quiero migrar pagos por fases a stripe, lo del webhook si ya hay algo usalo, y k no se rompa na»

Fíjate en lo que YA contiene esta frase mala:

• Un objetivo: migrar la pasarela de pagos a Stripe.
• Una estrategia: por fases.
• Una condición de reutilización: si ya hay webhook, usarlo — no rehacerlo.
• Una restricción de seguridad: no romper lo que funciona.

Cuatro de las seis piezas del prompt formalizado ya están en esa frase informal. El intake no inventa nada: las destila.

2. El filtro barato lo clasifica antes de gastar nada

El chequeo rápido (System 1: 1 milisegundo, 0 tokens, sin IA cara) pasa el texto por el docs-check y deduce:

• Detecta «por fases» + «migrar» → una migración por fases exige una SPEC de fases.
• Veredicto: FALTA crearla → el paso de documentos en borrador (⑥) tendrá que escribirla.

Nada se ha ejecutado todavía. Este filtro solo decide QUÉ documentación necesita la tarea — no interpreta, no decide, no toca el repo.

3. El delta: audita lo que se limpió

La corrección superficial arregla la forma y te enseña la lista exacta de cambios. Nunca mezcla interpretaciones:

• «usalo» → «úsalo» — falta de ortografía.
• «k no se rompa na» → «que no se rompa nada» — abreviación coloquial.
• «stripe» → «Stripe» — capitalización de marca.

Delta reportado: 3 faltas corregidas · 0 abreviaturas del repo · 2 interpretaciones → van a Supuestos (paso ④).

Las «2 interpretaciones» — que el webhook debe reutilizarse si existe, y que nada debe romperse — NO se corrigen: se marcan como supuestos y se comprueban más adelante contra el repo. Esa separación es la diferencia entre un sistema que te entiende y uno que te pone palabras en la boca.

4. Las preguntas resuelven lo que cambia el plan

Máximo 3 preguntas. Este caso genera una:

pregunta 1/3: «¿Stripe en modo test hasta terminar la fase 2, o directo a producción?»

Y deja dos supuestos escritos:

• Supuesto A (si no respondes): modo test hasta f2 — queda ESCRITO como supuesto, no como hecho.
• Supuesto B: «ya hay algo del webhook» → el agente NO lo adivina: lo comprobará el scout en la fase ① del run.

5. El prompt formalizado, completo

El detalle extra viene del REPO, no de la imaginación. Los seis bloques:

OBJETIVO: migrar la pasarela de pagos a Stripe en fases, sin romper la facturación actual. ALCANCE: src/lib/billing/* (pasarela) · routes/api/webhooks/stripe · panel admin de cobros (con skill-ui). FUERA DE ALCANCE: facturación fiscal VERIFACTU · multi-moneda · checkout público v2 — NO se tocan. CRITERIOS (verificables por comando): suite billing en verde · webhook idempotente (replay de eventos) · arquitectura hexagonal en verde. SUPUESTOS: modo test hasta f2 (a validar). SKILLS: skill-pagos, skill-ui, implement-safely.

Nota lo que hace el bloque FUERA DE ALCANCE: la frase original decía «k no se rompa na»; el formalizado lo convierte en una lista negra concreta de módulos intocables. Eso es traducir una intención a algo verificable.

6. Los documentos nacen en borrador

• specs/f0 — lo que hay HOY, medido (la foto del presente).
• specs/f1 — pasarela + webhook, con sus criterios: [ ] suite billing verde · [ ] webhook replay idempotente.
• specs/f2 — reembolsos (queda PENDIENTE: la próxima tarea empieza ahí).
• ADR-0033 — solo si hay decisión nueva con calado. Elegir Stripe ya se decidió (ADR-0004): se reutiliza.

Todo BORRADOR: no vale nada hasta que tú lo valides.

7. Tú validas — una sola confirmación

Ves junta la pantalla de decisión: el prompt formalizado + el delta + los supuestos + los specs borrador.

«¿Empezamos así o corriges algo?»

Si terminas tu mensaje con «auto», ni se pregunta — salvo destructivo: borrar o migrar datos pregunta SIEMPRE. Este es el punto barato de arreglar; después cuesta 100× más.

8. Qué revisar TÚ en esta pantalla

Checklist práctica antes de darle al botón:

• ¿El FUERA DE ALCANCE cubre todo lo que consideras intocable?
• ¿Los supuestos dicen lo que tú dirías si preguntaran?
• ¿Los criterios son verificables por comando, o alguno es una opinión («que quede bonito»)?
• ¿Las fases parten el riesgo donde tú lo partirías?

Si algo no cuadra, se corrige AQUÍ. Una tarea no está cerrada porque el agente diga «listo»: se cierra con evidencia grabada en su spec. Y el push sigue siendo una decisión tuya, humana.