# El contexto justo para avanzar

Convierte un reporte vago en una comprobación pequeña que puedas ejecutar. Corrige el comportamiento demostrable antes de ampliar la tarea.

Úsalo en: Claude Code o Codex · un fallo reproducible

Revisado: 2026-10-27

## 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.

## Prompt para copiar

Ayúdame a diagnosticar un fallo reproducible antes de cambiar código.

Observado: [qué ocurre]. Esperado: [qué debería ocurrir]. Reproducción: [pasos mínimos o entrada simulada]. Proyecto o archivos relevantes: [rutas, si las conoces]. Conservar: [restricciones].

Lee las instrucciones del proyecto e inspecciona el conjunto mínimo útil de archivos. Entrega un brief de cinco líneas: objetivo, evidencia observada, rutas reales relevantes, dudas y la comprobación mínima que reproduce el fallo. Marca rutas y causas SIN VERIFICAR hasta inspeccionarlas; no inventes comandos de prueba.

Para comprobarlo, enumera preparación, acción y condición observable de éxito. Incluye el fallo reportado y un reintento o caso límite. Distingue un resultado simulado de uno con cuenta real. Si no puedes ejecutarlo, escribe NO EJECUTADO y qué falta.

No edites durante este diagnóstico. Termina con el alcance y la comprobación propuestos. Cuando autorice una corrección, cambia solo lo que respalda la evidencia, repite la comprobación relevante e informa el comando y resultado reales o la observación manual. Una prueba correcta no demuestra que todo el producto funcione. No publiques ni cambies credenciales o permisos.

Antes de un seguimiento largo, revisa capacidad y renovación en INMC o el proveedor. Sin lectura significa desconocido; tokens, capacidad del plan y costo de API son distintos.

## Un ejemplo práctico

Escenario ilustrativo, no un caso con resultados medidos.

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.

Flujo de INMC para un fallo concreto, no una tendencia nueva ni un ahorro fijo. Usa el brief si el síntoma o alcance son inciertos; una tarea clara no exige un ritual de planificación. Un prompt no impone permisos por sí solo.

## Referencia oficial

[Claude Code · buenas prácticas](https://code.claude.com/docs/en/best-practices)

[OpenAI · prompts para Codex](https://learn.chatgpt.com/docs/prompting)

[Volver a la biblioteca](https://ineedmycredits.com/es/ideas)

HTML canónico: https://ineedmycredits.com/es/ideas/context-before-code