Mejores prompts para Claude Code: ejemplos para programar mejor

Revisa @src/auth/ y @tests/auth/.

Quiero entender:

1. cómo funciona actualmente el login
2. dónde se crean las sesiones
3. cómo se refrescan los tokens
4. qué tests cubren este flujo

No modifiques ningún archivo todavía.

Devuélveme primero un mapa del flujo.

Analiza este proyecto antes de modificar nada.

Quiero que identifiques:

- propósito principal
- arquitectura
- directorios importantes
- punto de entrada
- modelos de datos
- servicios principales
- autenticación
- dependencias externas
- sistema de tests
- comandos de build y desarrollo

Después explícame el flujo general
como si estuvieras incorporando
a un nuevo desarrollador al equipo.

No hagas cambios todavía.

Traza el flujo completo de [FUNCIONALIDAD].

Empieza en la interfaz
y sigue la ejecución hasta la base de datos.

Indica:

1. archivos involucrados
2. funciones llamadas
3. endpoints o AJAX utilizados
4. validaciones
5. consultas SQL
6. respuestas devueltas
7. posibles puntos de fallo

Incluye rutas de archivos
y nombres de funciones.

No modifiques código.

Quiero crear [DESCRIPCIÓN DE LA FEATURE].

Antes de programar,
entrevístame para definir correctamente
los requisitos.

Pregunta solamente cosas que
realmente puedan cambiar
la implementación.

Cubre:

- UX
- arquitectura
- permisos
- datos
- seguridad
- casos límite
- errores
- compatibilidad
- rendimiento
- pruebas

Cuando tengas suficiente información,
crea una especificación técnica completa
en SPEC.md.

Todavía no implementes nada.

Investiga cómo implementar [FEATURE].

Antes de proponer una solución:

1. encuentra los archivos relacionados
2. identifica patrones existentes que podamos reutilizar
3. revisa modelos y dependencias
4. identifica posibles efectos secundarios
5. detecta riesgos de seguridad
6. identifica qué tests deberían añadirse

Después crea un plan paso a paso.

Para cada paso indica:

- archivo
- cambio
- motivo
- riesgo
- forma de verificarlo

No escribas código todavía.

Implementa el plan aprobado.

Respeta estrictamente:

- la arquitectura existente
- las convenciones del proyecto
- las APIs públicas actuales
- compatibilidad existente

No hagas refactors no relacionados.

Después:

1. ejecuta los tests relevantes
2. ejecuta lint/typecheck si existe
3. corrige cualquier fallo provocado por tus cambios
4. revisa git diff
5. confirma que no se modificó nada fuera del alcance

Al final resume:
- archivos modificados
- tests ejecutados
- riesgos pendientes.

Tenemos este error:

[PEGA AQUÍ EL ERROR]

Pasos para reproducirlo:

[PASOS]

Quiero que:

1. reproduzcas el problema
2. traces el flujo relacionado
3. identifiques la causa raíz
4. escribas un test que reproduzca el bug
5. implementes la corrección mínima
6. ejecutes el test
7. ejecutes tests relacionados para evitar regresiones

No ocultes el error
ni desactives validaciones para que pase.

Corrige la causa raíz.

Investiga este problema,
pero NO modifiques código todavía.

Síntoma:

[DESCRIBIR PROBLEMA]

Determina:

- dónde comienza el fallo
- qué función introduce el comportamiento incorrecto
- por qué ocurre
- desde cuándo podría ocurrir
- si existen errores relacionados
- qué otros módulos podrían estar afectados

Revisa git history si ayuda.

Propón entre 2 y 3 soluciones,
explicando ventajas,
riesgos y complejidad.

Recomienda una.

Refactoriza @RUTA_ARCHIVO.

Objetivo:

[OBJETIVO]

Restricciones:

- no cambies comportamiento externo
- mantén las APIs públicas
- evita nuevas dependencias
- conserva compatibilidad
- no modifiques archivos no relacionados

Antes de editar,
identifica qué tests protegen
el comportamiento actual.

Después del refactor:

1. ejecuta esos tests
2. ejecuta lint/typecheck
3. compara el comportamiento anterior y nuevo
4. revisa el diff buscando cambios accidentales.

Analiza @RUTA_MODULO
y sus tests actuales.

Identifica comportamientos importantes
que no estén cubiertos.

Prioriza:

- entradas inválidas
- valores límite
- errores
- permisos
- estados vacíos
- concurrencia si corresponde
- regresiones probables

Sigue exactamente
el framework y estilo
de los tests existentes.

Añade únicamente tests
que aporten cobertura significativa.

Ejecuta los tests al terminar
y corrige cualquier fallo.

Necesito crear este endpoint:

POST /v1/orders

Antes de programar:

1. encuentra endpoints similares
2. identifica convenciones de controllers
3. revisa validaciones
4. revisa autenticación y autorización
5. identifica formato estándar de errores

Implementa el endpoint siguiendo
los patrones existentes.

Debe incluir:

- validación de entrada
- permisos
- tratamiento de errores
- respuesta consistente
- tests exitosos
- tests de errores
- documentación mínima

No introduzcas un nuevo patrón
si ya existe uno equivalente.

Audita el acceso a base de datos
de @RUTA_MODULO.

Busca específicamente:

- SQL injection
- consultas N+1
- índices faltantes
- queries innecesarias
- transacciones incorrectas
- condiciones de carrera
- bloqueos
- paginación ineficiente
- datos sensibles expuestos

No cambies código todavía.

Devuélveme una tabla con:

severidad | archivo | línea | problema | impacto | solución

Solo incluye problemas
que puedas justificar
con evidencia del código.

Usa un subagent especializado
para revisar este proyecto
buscando vulnerabilidades reales.

Revisa:

- SQL injection
- XSS
- CSRF
- command injection
- path traversal
- autenticación
- autorización
- exposición de secretos
- validación de uploads
- SSRF
- datos sensibles
- permisos excesivos

Para cada hallazgo incluye:

- severidad
- archivo y línea
- escenario de explotación
- impacto
- corrección recomendada

No reportes problemas teóricos
sin una ruta plausible de explotación.

Analiza @RUTA
buscando problemas de rendimiento.

No optimices todavía.

Identifica primero:

- operaciones repetidas
- consultas N+1
- loops costosos
- llamadas de red innecesarias
- archivos cargados repetidamente
- cálculos duplicados
- falta de caché
- objetos demasiado grandes
- operaciones síncronas bloqueantes

Ordena los hallazgos
por impacto esperado.

Para cada uno indica
cómo podríamos medir
el rendimiento antes y después.

Analiza este plugin WordPress completo.

Antes de modificar nada,
identifica:

- archivo principal
- clases
- hooks actions
- hooks filters
- shortcodes
- endpoints REST
- AJAX
- cron jobs
- tablas personalizadas
- opciones wp_options
- integración WooCommerce
- assets CSS/JS
- permisos y nonces

Después crea un mapa de arquitectura.

Finalmente revisa:

- seguridad
- rendimiento
- compatibilidad
- código duplicado
- consultas SQL
- posibles errores

No hagas cambios todavía.

Tenemos un fallo AJAX en WordPress.

Síntoma:
[DESCRIBIR]

Traza el flujo completo desde:

JavaScript
→ request
→ wp_ajax / wp_ajax_nopriv
→ callback PHP
→ validación nonce
→ permisos
→ consulta
→ wp_send_json_*

Comprueba:

- action correcto
- nonce
- capability
- parámetros POST
- sanitización
- prepared statements
- JSON devuelto
- errores JavaScript

Encuentra la causa raíz
antes de editar.

Revisa todos los cambios actuales con git diff.

Antes de hacer commit:

1. identifica cambios accidentales
2. revisa debugging temporal
3. verifica archivos sensibles
4. ejecuta los tests relevantes
5. ejecuta lint/typecheck si corresponde

Si todo está correcto:

- crea un commit descriptivo
- no incluyas archivos no relacionados
- crea el pull request

En el PR incluye:

- problema
- solución
- archivos principales
- pruebas realizadas
- posibles riesgos.

Usa un subagent con contexto limpio
para revisar el diff actual.

No asumas que la implementación es correcta.

Comprueba:

- requisitos no implementados
- bugs
- regresiones
- edge cases
- problemas de seguridad
- tests faltantes
- cambios fuera de alcance

Compara el resultado
contra PLAN.md si existe.

Reporta solamente problemas
que afecten corrección,
seguridad
o requisitos.

No reportes preferencias de estilo
sin impacto real.

Analiza @RUTA_MODULO
y crea documentación técnica
para desarrolladores.

Incluye:

- propósito
- arquitectura
- flujo principal
- clases y funciones públicas
- datos de entrada
- datos de salida
- errores posibles
- dependencias
- ejemplos de uso
- comandos de test

No describas línea por línea.

Prioriza información
que ayude a otro desarrollador
a mantener o extender el módulo.

Necesito migrar:

[TECNOLOGÍA ACTUAL]
→
[TECNOLOGÍA NUEVA]

No empieces modificando todo.

Primero:

1. identifica todos los archivos afectados
2. agrúpalos por tipo
3. detecta dependencias entre grupos
4. identifica incompatibilidades
5. define una estrategia incremental
6. define pruebas para cada fase
7. establece cómo hacer rollback

Prueba la estrategia
primero en 2 o 3 archivos.

Si funciona,
propón cómo paralelizar
el resto de la migración.

Usa la captura adjunta
como referencia visual.

Implementa la interfaz
siguiendo los componentes
y estilos existentes del proyecto.

No introduzcas librerías nuevas.

Después de implementar:

1. ejecuta la aplicación
2. captura el resultado
3. compara ambas imágenes
4. identifica diferencias visibles
5. corrige las diferencias importantes

Repite hasta que el resultado
sea visualmente consistente.

cat error.log | claude -p "
Analiza estos logs.

Identifica:

- errores únicos
- patrones repetidos
- primer error relevante
- errores probablemente derivados
- componente responsable
- hipótesis de causa raíz

Ordénalos por prioridad
y dime qué debería investigar primero.
"

La última ejecución de CI falló.

Analiza:

[LOG O COMANDO]

Quiero que determines:

1. cuál es el primer error real
2. cuáles son errores secundarios
3. qué cambio reciente puede haberlo causado
4. cómo reproducirlo localmente
5. cuál es la corrección mínima

Reproduce el fallo localmente.

Corrige la causa raíz
y vuelve a ejecutar
la misma comprobación
hasta que pase.

Necesito integrar esta API:

[URL DOCUMENTACIÓN]

Primero revisa la documentación oficial.

Después analiza
cómo este proyecto
integra servicios externos actualmente.

Diseña la integración respetando:

- patrones existentes
- variables de entorno
- timeouts
- retries
- manejo de errores
- rate limits
- logging
- secretos
- tests

No inventes endpoints
ni parámetros.

Si la documentación
no especifica algo,
indícalo explícitamente.

Necesito crear [FEATURE].

Antes de programar,
encuentra en el proyecto
la implementación existente
más parecida.

Usa esa implementación
como patrón para:

- estructura
- nombres
- arquitectura
- manejo de errores
- estilos
- tests

No copies lógica innecesaria.

Explícame primero
qué ejemplo utilizarás
y por qué.

Después implementa la feature
siguiendo ese patrón.

Antes de considerar esta tarea terminada,
verifica el resultado de forma independiente.

Comprueba:

1. requisitos originales
2. git diff
3. tests relevantes
4. lint
5. typecheck
6. build
7. errores de runtime si corresponde
8. seguridad básica
9. cambios fuera de alcance

No me digas simplemente que funciona.

Muéstrame evidencia:

- comandos ejecutados
- resultado de tests
- archivos modificados
- cualquier limitación pendiente.

OBJETIVO

Quiero conseguir:

[RESULTADO]


CONTEXTO

Archivos o módulos relevantes:

[RUTAS]


RESTRICCIONES

- no cambies [X]
- mantén compatibilidad con [Y]
- no añadas dependencias salvo necesidad
- sigue patrones existentes


PROCESO

1. investiga el código actual
2. identifica la causa o arquitectura
3. crea un plan
4. implementa solamente después de entenderlo


VERIFICACIÓN

Después:

- ejecuta tests
- ejecuta lint/typecheck
- revisa git diff
- comprueba casos límite


RESULTADO FINAL

Resume:

- qué cambiaste
- qué archivos modificaste
- qué verificaciones ejecutaste
- riesgos o limitaciones pendientes.

/clear

Usa subagents para investigar:

1. cómo funciona la autenticación
2. dónde se almacenan sesiones
3. qué código maneja refresh tokens

No modifiquen archivos.

Quiero solamente
un resumen consolidado
con rutas,
funciones
y riesgos relevantes.