10 patrones de prompts peligrosos en Claude Code | Qué evitar y alternativas seguras

¿Escribes prompts pensando “ya lo entenderá”? Claude Code ejecuta las instrucciones literalmente. Las instrucciones vagas o peligrosas producen resultados no deseados.

Este artículo cubre 10 patrones de prompts peligrosos que han causado incidentes reales, junto con alternativas seguras para cada uno. Si reconoces alguno de estos patrones después de leerlo, cámbialo de inmediato.

---

Patrón 1: “Lee todo y comprende el proyecto entero”

Por qué es peligroso

❌ "Lee todo este repositorio y entiéndelo antes de implementar"

Ejecutar esto en un repositorio con cientos de archivos hace explotar el contexto. Consume decenas de miles de tokens y el procesamiento se detiene con el error Prompt is too long. Si se detiene a mitad de la lectura, la implementación procede desde una comprensión incompleta.

Además, si existen archivos con .env o claves secretas, todos se cargan en el contexto.

Alternativa segura

✅ "Revisa la estructura del directorio src/api/ y lee solo los archivos relacionados con auth"
✅ "Lee únicamente package.json y README primero para obtener una visión general del proyecto"
✅ "Usa Grep para encontrar archivos relacionados con autenticación antes de leerlos"

Punto clave: Limita explícitamente el alcance de lo que se debe leer. Claude Code intentará leer ampliamente si no se especifica.

---

Patrón 2: “Si hay un error, reintenta automáticamente”

Por qué es peligroso

❌ "Si hay un error al llamar a la API externa, reintenta automáticamente hasta que tenga éxito"

Si un servicio externo está caído, seguirá golpeando la API en un bucle infinito. Hay incidentes reales con decenas de miles de llamadas en una hora, con facturas que se disparan a cientos o miles de euros. Esto es especialmente común con trabajos batch nocturnos que se ejecutan sin ser notados hasta la mañana.

Alternativa segura

✅ "Si hay un error, reintenta hasta 3 veces.
   Espera 1 segundo antes del 1er reintento, 4 segundos antes del 2º, 16 segundos antes del 3º.
   Si los 3 fallan, registra el error y detén el procesamiento"

✅ "Usa el siguiente código para los reintentos:
   withRetry(fn, { maxAttempts: 3, baseDelayMs: 1000 })"

---

Patrón 3: “Conéctate directamente a la BD de producción y verifica”

Por qué es peligroso

❌ "Conéctate a la BD de producción en DATABASE_URL, verifica el número de usuarios y luego haz correcciones"

Lo que comienza como “solo verificar” conlleva el riesgo de que las consultas de corrección posteriores se ejecuten contra la BD de producción. Si después de un SELECT accidentalmente sigue un DELETE o UPDATE, los datos de producción desaparecen. Conectarse a producción fácilmente desencadena operaciones más allá del alcance previsto.

Alternativa segura

✅ "Conéctate a la BD de desarrollo (DATABASE_URL_DEV) y verifica el número de usuarios.
   No te conectes a producción"

✅ "Genera la consulta pero no la ejecutes.
   La revisaré y la ejecutaré yo mismo"

✅ En CLAUDE.md:
"Está prohibido ejecutar consultas contra DATABASE_URL de producción.
 Verifica primero en staging, solo ejecuta después de la aprobación del usuario"

---

Patrón 4: Pegar claves API directamente en el prompt

Por qué es peligroso

❌ "Usa QIITA_TOKEN=abc123def456 para publicar en Qiita"
❌ "Usa sk-ant-api03-xxxxx para llamar a la API de Anthropic"

El contenido escrito en un prompt se guarda como historial de conversación. Se pasa tal cual cuando se delega a sub-agentes. Permanece en los registros del directorio local .claude/ y puede filtrarse al exterior sin querer a través de herramientas de backup o al compartir código.

Alternativa segura

✅ "Usa QIITA_TOKEN de .env para ejecutar scripts/qiita-publish.mjs"
   ← El valor del token solo existe en .env; solo el nombre de la variable va en el prompt

✅ Lee desde variables de entorno en tu script:
   const token = process.env.QIITA_TOKEN;
   if (!token) throw new Error("QIITA_TOKEN no está configurado");

---

Patrón 5: “Resuelve el conflicto y haz push a producción”

Por qué es peligroso

❌ "Hay un conflicto con la rama main. Resuélvelo y haz push a producción"

git push --force puede ser elegido como medio para “resolver el conflicto”. Esto arriesga borrar los commits de los compañeros de equipo. Además, “hacer push a producción” puede resultar en un push directo que omite CI/CD.

Alternativa segura

✅ "Verifica el conflicto con main y propón una estrategia de merge.
   Espera mi aprobación antes de hacer realmente el merge y el push"

✅ En CLAUDE.md:
"git push --force está prohibido.
 Si se necesita force, usa --force-with-lease y confirma con el usuario"

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ]
  }
}

---

Patrón 6: “Elimina todos los archivos viejos y limpia”

Por qué es peligroso

❌ "Elimina todos los archivos de dist/, .cache/ y los logs antiguos para limpiar"

Como “viejo” es ambiguo, pueden eliminarse archivos necesarios. En particular, los directorios .cache/ pueden contener datos críticos específicos del SO o de herramientas. Especificar múltiples directorios a la vez resulta en rm -rf dist .cache logs/, que puede cascadear a rutas no deseadas.

Alternativa segura

✅ "Elimina solo el contenido del directorio site/dist/.
   Deja el directorio en sí. No toques ningún otro directorio"

✅ "Muéstrame la lista de archivos a eliminar antes de borrarlos para que pueda confirmar.
   Elimina después de que apruebe"

---

Patrón 7: “Aprueba todo automáticamente y ejecútalo de una vez”

Por qué es peligroso

❌ "Salta todas las confirmaciones intermedias y ejecútalo todo hasta el final"
❌ "Ejecútalo con la opción --dangerously-skip-permissions"

El flujo de aprobación es un mecanismo de seguridad. Saltarlo permite que Claude Code proceda con lo que juzga como “más eficiente”. Eso podría significar rm -rf, force push o escrituras en la BD de producción—todo sin confirmación.

Alternativa segura

✅ "Primero lista los pasos para esta tarea.
   Después de mi aprobación, ejecuta un paso a la vez y confirma el resultado en cada paso"

✅ Para automatización, solo permite operaciones de confianza:
   "allow": ["Read(**)", "Glob(**)", "Bash(npm run test)"]

---

Patrón 8: “Actualiza las migraciones y limpia la BD”

Por qué es peligroso

❌ "Los archivos de migración están desordenados. Ordénalos y ponlos al día"

“Ordenar” puede interpretarse como eliminar archivos de migración antiguos. Si desaparece el historial de migraciones, configurar nuevos entornos o hacer rollback se vuelve imposible. Si se ejecuta un comando tipo migrate reset, los datos de producción podrían borrarse.

Alternativa segura

✅ "Muestra la lista de archivos de migración y solo señala duplicados o problemas.
   No hagas ningún cambio"

✅ "Verifica las migraciones no aplicadas y muestra el SQL que se ejecutaría.
   Ejecuta después de mi aprobación"

✅ En CLAUDE.md:
"No eliminar archivos de migración.
 Siempre obtener confirmación del usuario antes de ejecutar migraciones con ALTER/DROP"

---

Patrón 9: “Actualiza todos los paquetes a la última versión”

Por qué es peligroso

❌ "Los paquetes npm están desactualizados. Actualiza todo a la última versión"

npm update o npm install paquete@latest puede subir versiones principales. Si hay breaking changes incluidos, el build local puede pasar pero el servicio podría caerse después del despliegue en producción. La rotura en cascada de dependencias también es común.

Alternativa segura

✅ "Ejecuta npm outdated y muestra la lista de paquetes que se pueden actualizar.
   Revisaré por separado todo lo que suba una versión principal"

✅ "Actualiza solo los paquetes con vulnerabilidades de seguridad (detectados por npm audit)"

✅ "Actualiza solo react y next.js a la última versión menor.
   No subas la versión principal"

---

Patrón 10: “Despliega primero, los tests pueden esperar”

Por qué es peligroso

❌ "Escribiré los tests después, despliega primero por ahora"
❌ "CI es lento, sáltalo con --no-verify y haz push"

Los tests y CI no son “lentos”—te están “protegiendo”. El peor patrón es descubrir bugs en producción por primera vez después de saltártelos. --no-verify deshabilita todo incluidos los git hooks, por lo que el escaneo de secretos y el lint también se omiten.

Alternativa segura

✅ "Escribe primero los tests y despliega después de que pasen.
   Aunque la cobertura sea insuficiente, los caminos principales están bien"

✅ "Investiga por qué CI es lento y aceléralo aprovechando el caché.
   No lo saltes"

✅ En CLAUDE.md:
"--no-verify está prohibido.
 Nunca uses ningún medio para saltarte CI"

---

Resumen: 3 principios para escribir prompts seguros

Principio 1: Especifica el alcance explícitamente “Todo”, “todos” y “entero” son palabras de peligro. Especifica exactamente qué leer, qué cambiar y qué eliminar.

Principio 2: Mantén los pasos de confirmación Inserta “verificar”, “proponer” o “mostrar la lista” antes de “ejecutar”. Especialmente para operaciones que afectan a producción.

Principio 3: Nunca pongas secretos en los prompts Las claves API, contraseñas y cadenas de conexión van en .env. Solo los nombres de variables van en los prompts.

Frase peligrosa	Alternativa segura
”Lee todo"	"Lee solo el directorio [X]"
"Reintenta automáticamente"	"Reintenta hasta 3 veces, luego detente"
"Conéctate a la BD de producción"	"Verifica en la BD de desarrollo, yo lo ejecuto en producción"
"Elimina todo y limpia"	"Elimina solo [X], muéstrame la lista primero"
"Ejecútalo todo de una vez"	"Déjame confirmar los pasos primero, luego procede”

Claude Code solo sigue instrucciones—no tiene intención maliciosa. El peligro está en la persona que da instrucciones vagas. Desarrollar el hábito de escribir instrucciones específicas y con alcance claramente definido es el camino más rápido para prevenir incidentes.

Artículos relacionados

• 7 incidentes de producción reales con Claude Code y procedimientos de recuperación completos
• La guía completa de mejores prácticas de seguridad de Claude Code
• La guía completa de permisos de Claude Code

Referencias

• Guía oficial de seguridad de Claude Code
• OWASP LLM Application Security