devAlice
← AI Agents

Plantillas de prompt — reutilizar tareas de IA que haces a diario

Deja de informar al agente de IA desde cero — plantillas de revisión de código, depuración, refactorización, tests y documentación.

Después de una semana con un agente de IA, se repiten los mismos tipos de solicitudes a diario: "revisar este código", "rastrear este bug", "escribir tests". En lugar de volver a establecer el contexto cada vez, las plantillas de prompt reutilizables ahorran tiempo, aumentan la consistencia y mejoran la calidad del output.

Esta guía cubre cinco plantillas diarias (revisión de código, depuración, refactorización, tests, documentación) y cómo almacenarlas.

TL;DR

  1. Plantilla = contexto + tarea + formato de salida + restricciones
  2. Almacenamiento: ~/.prompts/ o gestionado con chezmoi
  3. Herramientas de expansión: Raycast Snippets, @docs de Cursor, slash commands de Claude Code
  4. Cuatro elementos de una buena plantilla: rol / entradas / formato de salida / prohibiciones

1. Cuatro elementos de una buena plantilla de prompt

Los marcadores de posición se muestran como [...] (para evitar conflictos MDX/JSX).

Eres un [rol].

Contexto: [contexto]

Tarea: [qué hacer]

Formato de salida: [cómo responder]

Restricciones:

  • [prohibición 1]
  • [prohibición 2]

Cuatro secciones claras ayudan al modelo a separar qué abordar de qué ignorar.

2. Plantilla 1: revisión de código

Eres un revisor de código senior para proyectos en [lenguaje].

Contexto:

  • Código en revisión: [pegar código o @archivo]
  • Convenciones del proyecto: [enlace o pegar guía de estilo relevante / .cursorrules]
  • Enfoque del revisor: [corrección | seguridad | rendimiento | legibilidad]

Tarea: Revisar el código. Identificar:

  1. Bugs o errores lógicos (severidad: crítico / mayor / menor)
  2. Problemas de seguridad (validación de entrada, secretos, autenticación)
  3. Problemas de rendimiento (solo si son obvios O(n^2) o de memoria)
  4. Violaciones de estilo contra las convenciones del proyecto
  5. Sugerencias para mayor claridad

Formato de salida: RESUMEN: [veredicto general en un párrafo] [CRÍTICO] (línea N): [problema] -> [corrección] [MAYOR] ... [MENOR] ... [ESTILO] ... [SUGERENCIA] ...

Restricciones:

  • No reescribir el archivo completo. Señalar y sugerir.
  • No ser quisquilloso con el estilo si .cursorrules no lo impone.
  • Si no se encuentran problemas en un nivel, omitir esa sección.

Uso

Chat lateral de Cursor: @code-review.md + @src/auth/login.ts + enfoque: seguridad.

Claude Code: almacenar la plantilla en .claude/commands/review.md e invocar con /review src/auth/login.ts.

3. Plantilla 2: depuración de bugs

Eres un asistente de depuración.

Contexto:

  • Mensaje de error: [pegar stack trace completo]
  • Código donde ocurre: [pegar reproducción mínima o @archivo]
  • Qué intenté: [hipótesis descartadas]
  • Comportamiento esperado: [qué debería pasar]

Tarea:

  1. Identificar la causa raíz más probable (no solo los síntomas)
  2. Sugerir una corrección
  3. Sugerir un test para prevenir regresión

Formato de salida: CAUSA RAÍZ: [una frase] EXPLICACIÓN: [2-3 párrafos del por qué] CORRECCIÓN: [código parcheado] TEST DE REGRESIÓN: [código de test]

Restricciones:

  • No adivinar. Si necesitas más información (logs, archivo completo), preguntar.
  • Si 2+ hipótesis son igualmente probables, presentar ambas con señales discriminadoras.
  • No decir simplemente "probar X" — explicar el modelo.

La sección "Qué intenté" es crítica: evita que el modelo vuelva a sugerir cosas que ya se descartaron.

4. Plantilla 3: refactorización

Eres un asistente de refactorización para [lenguaje].

Contexto:

  • Código actual: [pegar o @archivo]
  • Punto de dolor: [legibilidad | duplicación | testabilidad | rendimiento]
  • Restricciones:
    • Debe preservar la API pública
    • No debe romper los tests existentes

Tarea: Refactorizar preservando el comportamiento. Mostrar:

  1. El código refactorizado
  2. Diff vs original
  3. Tradeoffs de este enfoque vs como máximo 1 alternativa

Formato de salida: REFACTORIZACIÓN: [código nuevo] DIFF:

  • Eliminado: [qué]
  • Añadido: [qué]
  • Renombrado: [antiguo -> nuevo] TRADEOFF: [este enfoque]: [pros/contras] [alternativa]: [pros/contras] RECOMENDACIÓN: [cuál y por qué]

Restricciones:

  • No cambiar el comportamiento. Si crees que el comportamiento debería cambiar, señalarlo por separado.
  • Mantener compatibilidad con los tests — mostrar cómo los tests existentes siguen pasando.
  • No introducir nuevas dependencias sin petición explícita.

5. Plantilla 4: escritura de tests

Eres un escritor de tests para [lenguaje] (Vitest, Jest, Pytest, etc.).

Contexto:

  • Código a probar: [pegar o @archivo]
  • Estilo de tests existente: [pegar test de ejemplo o @archivo]
  • Enfoque de cobertura: [camino feliz | casos extremos | modos de fallo | todos]

Tarea: Escribir tests que:

  1. Cubran el camino feliz
  2. Cubran al menos 3 casos extremos (valores límite, entrada vacía, casos de error)
  3. Sean deterministas (sin tiempos/redes inestables sin mock)
  4. Sigan el estilo de tests existente

Formato de salida: un único archivo de tests en [lenguaje].

Restricciones:

  • Usar la misma biblioteca de aserciones que los tests existentes
  • Mockear las dependencias externas (no golpear red/BD reales)
  • Mantener cada test enfocado (un tema de aserción por test)
  • Nombrar los tests descriptivamente: "devuelve X cuando Y"
  • NO escribir tests que simplemente reflejen la implementación. Probar el comportamiento.

6. Plantilla 5: documentación

Eres un escritor técnico.

Contexto:

  • Código: [pegar o @archivo]
  • Audiencia: [principiante | intermedio | experto]
  • Tipo de doc: [sección README | JSDoc | tutorial | referencia]

Tarea: Escribir documentación que:

  1. Declare el propósito en 1 frase
  2. Muestre un ejemplo de uso mínimo
  3. Liste parámetros/retornos con tipos
  4. Note casos extremos o advertencias (si los hay)

Formato de salida: markdown o formato específico JSDoc/TypeDoc.

Restricciones:

  • Sin relleno. Ser directo.
  • Los ejemplos de código deben ser ejecutables / pegables
  • Si la API es compleja, enlazar a una referencia más profunda en lugar de volcar todo
  • Para especificidades de biblioteca/framework, preferir la terminología oficial

7. Almacenamiento y gestión de plantillas

Opción A: slash commands de Claude Code

Guardar las plantillas en ~/.claude/commands/review.md. En el CLI: /review src/foo.ts inyecta el system prompt automáticamente.

Opción B: @docs de Cursor

Cursor → Configuración → Características → Docs → Añadir → URL o ruta local. En el chat: @my-review-template.

Opción C: Raycast Snippets

Vía Raycast Snippets de mac/productivity:

  • Añadir Snippet: pegar la plantilla completa
  • Palabra clave: !review
  • En cualquier campo de texto, escribir !review → se expande

Opción D: directorio simple + alias

Guardar cada plantilla como .md en ~/.prompts/. .zshrc:

alias prompt='ls ~/.prompts'

prompt → listar → cat ~/.prompts/review.md | pbcopy → pegar en cualquier lugar.

Integración con chezmoi

Añadir ~/.prompts/ al árbol de dotfiles de chezmoi. Disponible en cualquier máquina nueva de inmediato.

8. Evolución de la plantilla

La primera plantilla llega al 70% de calidad. Mejorarla a medida que se usa:

  1. Los resultados suelen ser demasiado largos: añadir "Mantener bajo N líneas" o "Solo el diff".
  2. El agente de IA sigue desviándose: reforzar las Restricciones (prohibiciones concretas).
  3. Falta contexto: añadir campos de entrada explícitos como "Qué intenté".
  4. Las salidas son inconsistentes: mostrar un ejemplo del formato de salida.
  5. Demasiado conservador: "Recomendar la mejor opción, no todas las opciones".

Una nota de una línea al final de cada fase. A lo largo de un año, los patrones propios quedan codificados en un activo reutilizable.

9. Antipatrones

Demasiado abstracto

❌ "Sé un buen revisor de código." ✅ "Eres un revisor senior. Identifica bugs / seguridad / estilo. Output en formato X."

Objetivo vago

❌ "Mejora esto." ✅ "Hazlo más legible. No cambies el comportamiento. Muestra el diff."

Formato de salida ausente

Cada modelo produce una estructura diferente; la comparación y la automatización se resienten.

Demasiado larga: restricciones de "precaución"

"Y también X. Y quizás Y. No olvidar Z." → el modelo pierde el foco de prioridad. Mantener 3–5 restricciones esenciales.

Siempre en coreano

Los prompts en coreano en un codebase en inglés son ineficientes en tokens. Si el contexto del código es en inglés, los prompts en inglés producen mejores resultados.

Verificación

  1. Revisar el mismo código con y sin la plantilla: comparar consistencia y completitud.
  2. Aplicar chezmoi en una máquina nueva → ~/.prompts/ disponible de inmediato.
  3. Disparador !review de Raycast → se expande en cualquier campo de texto.
  4. /review file.ts en Claude Code → misma estructura de respuesta.
  5. Después de una semana de uso, mejorar una plantilla por semana (nota de una línea).

Solución de problemas

El agente de IA ignora la plantilla

  • Las plantillas largas hacen que el modelo olvide las instrucciones a mitad. Mantener bajo 200 líneas.
  • Volver a declarar la restricción más importante al final (sesgo de recencia).
  • @docs de Cursor puede comprimir el contexto: extraer solo los elementos esenciales.

El slash command no funciona

  • Claude Code: verificar el nombre y la ubicación del archivo en ~/.claude/commands/foo.md.
  • Cursor: los slash commands dependen del modelo seleccionado.

El formato de salida se rompe

Mostrar un ejemplo explícito de formato. Usar instrucciones directas como "Usar exactamente este formato:".

Respuestas demasiado largas

Añadir "Máximo N líneas." o "Solo el diff, sin explicación."

Idioma mezclado en la respuesta

Declarar tanto el idioma del prompt como el de la salida. "Responder en coreano." o "Responder en inglés."

Referencias

Registro de cambios

  • 2026-05-12: Primer borrador. Cinco plantillas + cuatro opciones de almacenamiento + evolución + cinco antipatrones + cinco casos de solución de problemas.