El contexto justo para avanzar

Antes de empezar

• Una sesión funcional de Codex o Claude Code con acceso a tu proyecto. Cuenta, modelo y herramientas dependen del proveedor; INMC no entrega créditos ni acceso.
• Un síntoma, el resultado esperado y una reproducción segura. Prefiere fallos simulados y cuentas de prueba; elimina credenciales y datos privados de clientes.
• Las instrucciones del proyecto y su sistema de pruebas, si existe. El prompt orienta al modelo; conserva los controles reales de permisos del proveedor.

Cómo usarlo

1. Reemplaza los campos con un solo fallo. Si la tarea ya es clara y trivial, usa una comprobación adecuada sin imponer un paso de planificación.
2. Pide el brief de cinco líneas. Confirma que las rutas fueron inspeccionadas y que la causa propuesta tiene evidencia o está marcada sin verificar.
3. Revisa preparación, acción y condición de éxito. Establece primero el fallo en una prueba segura o marca NO EJECUTADO; proponer una prueba no equivale a ejecutarla.
4. Autoriza una corrección pequeña cuando el alcance esté claro. Repite la prueba e inspecciona el resultado real, con un reintento o caso límite. Evita refactors ajenos.
5. Guarda resultado y casos pendientes. Con poca capacidad, termina en un punto útil y continúa después. No se promete un ahorro fijo ni una cantidad de prompts restantes.

EJEMPLO ILUSTRATIVO

Hazlo concreto.

Ejemplo creado por INMC, no una ejecución real de un modelo: en un proyecto de demo, el botón de acceso queda cargando cuando se rechaza una petición simulada. Debe mostrar un error y permitir reintentar. Proporciona el síntoma y la ruta del proyecto. El brief debe localizar el manejador real del estado de carga y su prueba, o marcarlos SIN VERIFICAR. Comprobación propuesta: rechaza la petición simulada una vez, envía, observa error y botón habilitado; envía otra vez y confirma que acepta el reintento. No uses contraseñas reales ni deduzcas que una simulación valida el acceso en producción.

Salida esperada

• Un brief de cinco líneas con objetivo, evidencia, rutas inspeccionadas, dudas y una comprobación. Una posible causa, como no restablecer el estado de carga, sigue SIN VERIFICAR hasta tener evidencia en el código.
• En la demo: preparación = rechazar una petición simulada; acción = enviar y reintentar; éxito = error visible, fin de carga y reintento aceptado. Son condiciones esperadas, no resultados afirmados.
• Registro PASA, FALLA o NO EJECUTADO, comando o pasos manuales reales, resultado observado y límites. Antes de acceder: “NO EJECUTADO; falta inspeccionar el sistema de pruebas y las rutas reales.”

Revisa el resultado

• Las rutas reales sustituyen las suposiciones; no se afirma una causa sin evidencia.
• El fallo se reproduce o figura como NO EJECUTADO. El comando procede del proyecto, no de un script inventado.
• Tras autorizar la corrección, se revisan rechazo y reintento. La simulación se etiqueta; una cuenta real queda sin verificar hasta probarla aparte.
• El brief no modifica archivos ajenos, producción, credenciales ni permisos.

Si el resultado falla

• Propone reescribir todo: repite el síntoma y pide la ruta afectada mínima y una condición de aceptación.
• No existe sistema de pruebas: pide una comprobación manual segura con preparación, acción y resultado esperado. Déjala NO EJECUTADO hasta realizarla; no instales otro framework automáticamente.
• La reproducción inicial no falla: conserva la observación, revisa entorno y simulación, y solicita un dato faltante. No declares una corrección ni fuerces un fallo.
• La simulación pasa, pero el acceso real falla: mantén producción como ruta sin verificar. Inspecciona el error con acceso aprobado; nunca pegues contraseñas o tokens de sesión.
• El modelo ignora un límite: usa los controles de permisos de la herramienta y detén la tarea. El prompt no es un sandbox.