Aprende a minimizar el contexto sensible en Claude Code con plantillas de prompt prácticas, flujos para compartir archivos y pasos de redacción que siguen permitiendo ayuda útil para programar.
“Contexto” es todo lo que le entregas a un modelo para que trabaje: fragmentos de código, trazas de stack, archivos de configuración, variables de entorno, muestras de base de datos, capturas de pantalla e incluso mensajes previos en la misma conversación. Más contexto puede acelerar la depuración, pero también aumenta las probabilidades de pegar algo que no tenías intención de compartir.
El exceso de información suele ocurrir bajo presión. Un bug bloquea una entrega, la autenticación falla justo antes de una demo, o una prueba inestable solo falla en CI. En ese momento es fácil pegar el archivo entero, luego todo el log, luego la configuración completa “por si acaso”. Las costumbres del equipo pueden empujar en la misma dirección: en revisiones y depuraciones la visibilidad total es normal, incluso cuando solo hace falta una pequeña porción.
Los riesgos no son hipotéticos. Un pegado puede filtrar secretos, datos de clientes o detalles internos del sistema. Ejemplos comunes incluyen:
El objetivo no es ser secreto. Es compartir la porción más pequeña que todavía reproduzca el problema o explique la decisión, para obtener la misma calidad de ayuda con menos exposición.
Un modelo mental simple: trata al asistente como a un compañero externo útil que no necesita tu repo entero. Empieza con una pregunta precisa (“¿Por qué esta petición devuelve 401?”). Luego comparte solo lo que sostiene esa pregunta: la entrada que falla, el resultado esperado, el resultado real y la ruta de código estrecha implicada.
Si una llamada de login falla, normalmente no necesitas todo el módulo de auth. Una pareja request/response saneada, la función que construye los headers y las claves de configuración relevantes (con valores reemplazados) suele ser suficiente.
Cuando pides ayuda para programar, “contexto” no es solo código fuente. Es cualquier cosa que pueda ayudar a alguien a iniciar sesión, identificar a una persona o mapear tus sistemas. Empieza por saber qué es tóxico pegar.
Las credenciales convierten un fragmento útil en un incidente. Esto incluye claves API y tokens, claves privadas, cookies de sesión, URLs firmadas, secretos de OAuth, contraseñas de base de datos y tokens “temporales” impresos en logs.
Una sorpresa común son las filtraciones indirectas. Un mensaje de error puede incluir encabezados completos con un Authorization bearer, o un volcado de variables de entorno en modo debug.
Cualquier dato vinculado a una persona puede ser sensible, aunque parezca inofensivo. Vigila emails, nombres, teléfonos, direcciones, IDs de clientes, IDs de empleados, tickets de soporte con conversaciones y detalles de pago.
Si necesitas datos para reproducir un bug, intercambia registros reales por otros ficticios pero realistas. Conserva la forma (campos y tipos), no la identidad.
Hechos “aburridos” internos son valiosos para atacantes y competidores: hostnames, IPs, nombres de repos, IDs de tickets, nombres de proveedores, términos contractuales y URLs de servicios internos.
Incluso una sola traza de stack puede revelar rutas de carpetas con nombres de usuario o clientes, convenciones de nombres de servicio y pistas de cuenta en la nube (nombres de buckets, cadenas de región).
No todo el código es igualmente sensible. Las piezas más riesgosas son las que codifican cómo funciona tu negocio: reglas de precios y descuentos, controles antifraude, lógica de recomendación, plantillas de prompts para funciones LLM y documentos estratégicos.
Si necesitas ayuda con un bug, comparte la función más pequeña que lo reproduce, no el módulo completo.
Los detalles sensibles a menudo vienen acompañando en sitios que no notas: comentarios con nombres, mensajes de commit, TODOs que referencian clientes y trazas de stack pegadas “tal cual”. Los archivos de configuración son especialmente riesgosos porque mezclan ajustes inofensivos con secretos.
Una regla práctica: si el texto ayudaría a alguien a entender tu sistema más rápido que un ejemplo en limpio, trátalo como sensible y redáctalo o reemplázalo.
El mejor momento para reducir la exposición es antes de abrir el editor. Una pausa de 30 segundos para definir el resultado suele recortar mucho de lo que vas a compartir.
Empieza nombrando el resultado que quieres en una frase. ¿Estás tratando de encontrar la causa de un bug, obtener un plan de refactor seguro o diseñar tests? Cada objetivo necesita entradas distintas. Las búsquedas de bugs suelen necesitar una traza y una función pequeña. Las preguntas de refactor suelen necesitar solo las interfaces públicas y un ejemplo corto de uso actual.
Luego elige un “artefacto mínimo” que pruebe el problema. Escoge lo más pequeño que siga fallando: una prueba que falla, el fragmento más pequeño que dispara el error, un extracto corto del log alrededor de la falla o un ejemplo simplificado de configuración con marcadores.
Cuando describas datos, prefiere formas en lugar de valores. “El objeto User tiene id (UUID), email (string), role (enum), createdAt (timestamp)” casi siempre basta. Si necesitas ejemplos, usa falsos que coincidan con el formato, no registros reales.
Sé estricto con los archivos. Comparte solo el módulo que estás cambiando más las interfaces que toca. Si una función llama a otro módulo, a menudo solo necesitas la firma y una breve descripción de lo que devuelve. Si un bug implica una petición a otro servicio, puede bastar con la forma de la petición, una lista de nombres de encabezado (no sus valores) y la forma de la respuesta esperada.
Define límites firmes que nunca salgan de tu máquina: claves API, certificados privados, tokens de acceso, datos de clientes, URLs internas, volcados completos del repo y logs de producción en bruto. Si depuras un 401, comparte el flujo de auth y el mensaje de error, pero reemplaza el token por TOKEN_REDACTED y el email por [email protected].
Una buena redacción no es solo esconder secretos. Mantiene la estructura del problema intacta para que el asistente aún pueda razonar. Quitar demasiado produce consejos genéricos. Quitar muy poco te arriesga a filtrar datos.
Elige un estilo de placeholder y úsalo en código, config y logs. La consistencia facilita seguir el flujo.
Si el mismo token aparece en tres sitios, no lo reemplaces de tres maneras distintas. Usa placeholders como API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1 e incrementa según haga falta (TOKEN_2, TOKEN_3).
Una pequeña leyenda ayuda sin revelar valores reales:
TOKEN_1: bearer token usado en Authorization headerCUSTOMER_ID_1: identificador interno usado en una búsqueda de BDAPI_KEY_1: clave usada para llamar al proveedor de pagosAlgunos bugs dependen de longitud y estructura (parsing, validación, firmas, regex). En esos casos, reemplaza cadenas únicas por valores ficticios que tengan la misma apariencia.
Por ejemplo:
Así puedes decir “el token falla la validación” sin exponer el token real.
Al compartir JSON, conserva las claves y reemplaza los valores. Las claves muestran lo que el sistema espera; los valores son a menudo la parte sensible.
En lugar de:
{"email":"[email protected]","password":"SuperSecret!","mfa_code":"123456","customer_id":"c8b1..."}
Comparte:
{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}
La misma idea para SQL: conserva nombres de tablas, joins y condiciones, pero elimina literales.
WHERE user_id = USER_ID_1 AND created_at \u003e DATE_1Si una función contiene reglas de negocio o lógica propietaria, descríbela. Conserva lo que afecta al bug: entradas, salidas, efectos secundarios y manejo de errores.
Ejemplo de resumen que sigue siendo útil:
“signRequest(payload) toma un JSON, añade timestamp y nonce, luego crea una firma HMAC SHA-256 desde method + path + body. Devuelve {headers, body}. El error ocurre cuando el payload incluye caracteres no ASCII.”
Eso suele bastar para diagnosticar problemas de encoding, canonicalización y firmas sin exponer la implementación completa.
Al final de tu prompt, indica qué eliminaste y qué conservaste. Evita idas y vueltas y reduce la probabilidad de que te pidan pegar más.
Ejemplo:
“Redacted: tokens, emails, customer data, full request bodies. Kept: endpoint paths, status codes, header names, stack trace frames, and the exact error text.”
Trata al asistente como a un compañero que solo necesita la parte en la que trabajas. Comparte interfaces y contratos en lugar de archivos completos: firmas de función, tipos, formas de petición/respuesta y el texto exacto del error.
Un repro mínimo en lenguaje natural suele bastar: la entrada usada, lo esperado, lo que pasó en su lugar y unas notas del entorno (versión runtime, OS, versión del framework). No necesitas todo el historial del proyecto.
Plantillas que funcionan bien:
Un bloque de configuración saneada es un punto intermedio útil. Muestra qué perillas existen sin exponer secretos:
# sanitized
DB_HOST: "\u003cset\u003e"
DB_PORT: "5432"
DB_USER: "\u003cset\u003e"
DB_PASSWORD: "\u003credacted\u003e"
JWT_SECRET: "\u003credacted\u003e"
OAUTH_CLIENT_ID: "\u003cset\u003e"
OAUTH_CLIENT_SECRET: "\u003credacted\u003e"
Ejemplo de prompt seguro:
“Login falla con 401. Esperado 200. Respuesta real: ‘invalid token’. Entorno: Node 20, dev local, sincronización de tiempo activada. Contrato de petición: Authorization: Bearer \u003credacted\u003e. Pasos de verificación: el token se emite en /auth/login y se usa en /me. ¿Cuáles son las causas principales (skew de reloj, mismatch de audience, mismatch de secreto de firma), y qué comprobación única confirma cada una?”
Un hábito fiable es tratar el compartir como empaquetar una reproducción mínima. Comparte lo suficiente para diagnosticar el problema y nada más.
Un enfoque práctico es una “carpeta de compartir” temporal separada del repo real. Copia archivos allí manualmente en lugar de compartir todo el proyecto. Eso fuerza decisiones intencionales.
Mantén el flujo simple:
Después de construir la carpeta, léela como un externo. Si un archivo no ayuda a depurar el problema específico, no pertenece.
Al redactar, evita romper el código o los logs. Reemplaza valores con placeholders evidentes que mantengan tipo y estructura. Por ejemplo, cambia:
DATABASE_URL=postgres://user:[email protected]:5432/app
por:
DATABASE_URL=postgres://user:REDACTED@localhost:5432/app
Si el bug depende de la respuesta de un tercero, escribe la forma de la respuesta en tu README e incluye un archivo JSON sintético que coincida. Puedes obtener depuración significativa sin compartir tráfico real.
Usa un bucle repetible para no improvisar bajo presión.
Escribe dos frases primero.
Recopila las entradas mínimas. Lleva solo lo que ayuda a reproducir o razonar sobre el problema: un pequeño fragmento alrededor de la línea que falla, el texto exacto del error, versiones relevantes y 3 a 5 pasos para reproducir.
Redacta sin aplanar la estructura. Reemplaza secretos con placeholders y conserva la forma intacta. Elimina identificadores que no afecten el comportamiento (nombres de proyecto, tenant IDs, emails). Mantén los placeholders consistentes.
API_KEY=sk_live_...
becomes
API_KEY=\u003cAPI_KEY\u003e
customer-1234-prod-db
becomes
\u003cDB_HOST_PROD\u003e
Haz preguntas focalizadas. Acompaña “¿Cuál es la causa más probable?” con “¿Qué debería cambiar?” Si quieres un parche, pide un cambio limitado al fragmento que proporcionaste y exige que las suposiciones vayan etiquetadas.
Verifica localmente, luego añade un detalle nuevo. Prueba la sugerencia. Si falla, añade solo un detalle nuevo (la siguiente línea del stack trace, un flag de config, un repro más estrecho). No pegues de golpe un archivo entero.
Esta divulgación incremental suele darte una respuesta real mientras mantienes secretos y código no relacionados fuera del prompt.
Una situación común: el login funciona en tu laptop y en staging, pero falla en producción. Necesitas ayuda rápida, pero no puedes pegar tokens reales, emails de usuarios, hostnames internos o tu middleware de auth completo.
Empieza con lo que puedes observar: forma de petición y respuesta, código de estado y una traza corta. Si es tema de JWT, también puedes compartir detalles no sensibles del header (como el algoritmo esperado) y datos de tiempo (como deriva del reloj). Conserva todo lo demás como placeholders.
Un paquete seguro suele incluir:
Luego haz una pregunta enfocada. Las fallas de auth solo en producción suelen venir de skew de reloj, issuer/audience incorrectos, claves de firma distintas, rotación de claves o diferencias de proxy/headers.
Patrón de prompt:
I have a production-only login/auth failure. Locally it passes.
Observed behavior:
- Endpoint: POST /api/login
- Production response: 401 with message "invalid token" (generic)
- Staging/local: 200
Sanitized request/response:
- Authorization: Bearer \u003cJWT_REDACTED\u003e
- Expected claims: iss=\u003cISSUER_PLACEHOLDER\u003e, aud=\u003cAUDIENCE_PLACEHOLDER\u003e
- Token validation library: \u003cLIB_NAME_AND_VERSION\u003e
Sanitized log snippet:
\u003cPASTE 5-10 LINES WITH TOKENS/EMAILS/HOSTS REDACTED\u003e
Question:
Given this, what are the top causes of JWT validation failing only in production, especially clock skew or claim mismatch? What specific checks and log lines should I add to confirm which one it is?
Cuando recibas hipótesis, valida de forma segura con cambios que puedas mantener. Añade logging temporal que imprima solo hechos no sensibles (exp, iat, ahora y el código de razón del fallo). Escribe una prueba pequeña que alimente un token fixture seguro (o un token generado localmente) y afirme el comportamiento del validador para casos límite.
Un plan simple:
La forma más rápida de perder los beneficios de privacidad es compartir “una pequeña cosa” que en silencio contiene todo. Pegar un .env o un archivo de configuración completo es el clásico ejemplo. Incluso si borras secretos obvios, esos archivos suelen incluir hostnames internos, nombres de servicio, feature flags y pistas de entorno que mapean tu sistema.
Las trazas completas de stack son otra fuga frecuente. Pueden incluir usernames, nombres de máquina, nombres de repos y rutas absolutas como /Users/alex/company-payments/.... A veces incluyen query strings, encabezados HTTP u objetos de error con tokens. Si necesitas la traza, copia solo los marcos relevantes y reemplaza rutas con placeholders consistentes.
Los payloads reales de clientes son riesgosos aún cuando son “pequeños”. Un solo cuerpo JSON puede incluir emails, direcciones, IDs de pedidos o notas en texto libre. Lo más seguro es generar un payload falso con la misma forma y casos límite (campos faltantes, cadenas largas, caracteres extraños), sin valores reales.
Placeholders inconsistentes también causan problemas. Si USER_ID significa “customer id” en un sitio y “internal account id” en otro, obtendrás un diagnóstico equivocado. Elige un esquema y úsalo.
Si tu mensaje ayudaría a un extraño a iniciar sesión, localizar tus servidores o identificar un cliente, necesita otra pasada.
Cuando intentas ser cuidadoso, la velocidad es tu enemigo. Una rutina corta te ayuda a obtener respuestas útiles manteniendo datos sensibles fuera del prompt.
Haz una pasada para secretos y luego otra para identificadores que aún exponen tu sistema:
Después de redactar, conserva la forma. Deja tipos, esquemas, nombres de campos, códigos de estado y ejemplos de estructura de payload intactos, pero cambia valores reales por placeholders.
Para mantener consistencia (especialmente bajo presión), escribe un pequeño conjunto de reglas de redacción y reutilízalas. Para equipos, conviértelo en una plantilla compartida con dos bloques: “lo que comparto” (archivos, funciones, endpoints) y “lo que no comparto” (secretos, datos de producción, dominios internos).
Si quieres una capa extra de seguridad, haz tus experimentos en un entorno aislado y deja los cambios reversibles. En Koder.ai (koder.ai), el modo de planificación puede ayudarte a esbozar el cambio más pequeño necesario para probar una hipótesis, y snapshots más rollback facilitan intentar una corrección sin arrastrar contexto sensible extra a tus prompts.
Comienza con la porción más pequeña que pueda responder tu pregunta: la entrada que falla, lo esperado frente a lo real, y la ruta de código estrecha implicada.
Un paquete por defecto útil es:
No pegues:
.env completos/volcados de configuración o logs de producción en brutoSi ayudaría a un desconocido a iniciar sesión, identificar a una persona o mapear tus sistemas, redacta o resume.
Usa placeholders consistentes para que el flujo siga siendo legible.
Ejemplo de esquema:
TOKEN_1, TOKEN_2API_KEY_1USER_ID_1, Preserva el formato cuando el bug dependa de parseo o validación.
Casos comunes:
8-4-4-4-12Esto mantiene el comportamiento realista sin exponer el valor real.
Comparte claves y estructura, reemplaza valores.
Para JSON:
Para SQL:
Ejemplo:
Haz un resumen en términos de entradas, salidas y la regla específica que afecta el bug.
Un resumen práctico incluye:
Esto suele dar el mismo valor de depuración sin revelar la implementación.
Un prompt seguro y simple incluye:
También incluye una nota de redacción como:
“Redacted: tokens, emails, customer data, internal hostnames. Kept: endpoint paths, status codes, header names, exact error text.”
Porque suelen contener todo a la vez:
Una alternativa más segura es una plantilla de configuración:
Usa divulgación incremental:
Así mantienes el alcance pequeño y previenes fugas accidentales bajo presión.
Un paquete práctico es:
Luego pregunta:
CUSTOMER_ID_1EMAIL_1Agrega una breve leyenda cuando haga falta:
TOKEN_1: bearer token usado en /meCUSTOMER_ID_1: identificador interno usado en la búsqueda de base de datosWHERE user_id = USER_ID_1 AND created_at \u003e DATE_1\u003cset\u003e o \u003credacted\u003e