Domina
Claude Code
como un senior

Analiza esta codebase sin modificar archivos.

Objetivo: entender cómo está organizado el proyecto y cómo trabajar con él de forma segura.

Revisa:
1. Stack principal.
2. Estructura de carpetas.
3. Arquitectura aparente.
4. Módulos principales.
5. Comandos de instalación, desarrollo, test, lint y build.
6. Flujo de datos principal.
7. Configuración relevante.
8. Riesgos técnicos o deuda aparente.
9. Qué debería contener CLAUDE.md.

Devuelve: resumen ejecutivo, mapa de carpetas, comandos detectados, riesgos, recomendaciones.
No modifiques archivos.

Quiero implementar la feature: [describe la feature].

Antes de modificar archivos:
1. Localiza el código relevante.
2. Resume cómo funciona actualmente.
3. Propón un plan incremental.
4. Indica qué archivos tocarías.
5. Indica qué tests crearías o modificarías.
6. Espera mi confirmación.

Restricciones:
- No añadas dependencias sin pedir permiso.
- No refactorices partes no relacionadas.
- Mantén el estilo existente.
- Mantén la arquitectura actual.

Validación final:
- Ejecuta tests relacionados.
- Ejecuta lint/typecheck/build si aplica.
- Resume cambios, riesgos y archivos modificados.

Hay un bug en [describe el comportamiento].

Información disponible:
- Comportamiento esperado: [describe]
- Comportamiento actual: [describe]
- Error/log/test fallido: [pega lo relevante]

Tarea:
1. Investiga la causa probable.
2. Localiza los archivos relevantes.
3. No modifiques nada hasta explicar la causa raíz.
4. Propón la corrección mínima.
5. Añade o ajusta tests para evitar regresión.
6. Ejecuta validaciones relacionadas.

Evita refactors no relacionados.

Quiero refactorizar [zona concreta] sin cambiar comportamiento.

Antes de tocar código:
1. Analiza el estado actual.
2. Identifica problemas concretos.
3. Propón un plan por pasos pequeños.
4. Indica cómo validaremos que no cambia el comportamiento.
5. Espera confirmación.

Durante el refactor:
- No cambies comportamiento funcional.
- No mezcles feature nueva.
- Mantén commits pequeños si procede.
- Añade tests si no existen y son necesarios.

Al terminar:
- Ejecuta tests relacionados.
- Resume qué cambió y qué no cambió.

Quiero añadir tests para [módulo/funcionalidad].

Primero:
1. Analiza los tests existentes.
2. Detecta framework, estilo, helpers, fixtures y convenciones.
3. Propón una lista de casos a cubrir.
4. Espera confirmación si hay dudas importantes.

Después:
- Crea tests siguiendo el estilo existente.
- Prioriza casos críticos y edge cases.
- No cambies código productivo salvo que detectes un bug claro y me lo expliques.
- Ejecuta los tests relacionados.

Devuelve:
- Casos cubiertos.
- Casos no cubiertos y por qué.
- Comando usado para validar.

Quiero investigar un problema de rendimiento en [zona].

No optimices todavía.

Primero:
1. Identifica posibles cuellos de botella.
2. Distingue evidencia real de suposiciones.
3. Propón cómo medir el problema.
4. Propón mejoras ordenadas por impacto/riesgo.

Después de mi confirmación:
- Implementa solo la mejora de menor riesgo y mayor impacto.
- Añade medición o prueba si es posible.
- Ejecuta validaciones.

Evita microoptimizaciones sin evidencia.

Revisa esta parte del proyecto desde seguridad.

No modifiques archivos.

Busca:
1. Problemas de autenticación.
2. Problemas de autorización.
3. Validación de entrada insuficiente.
4. Exposición de datos sensibles.
5. Manejo incorrecto de secretos.
6. Errores que filtran información.
7. Dependencias sospechosas.
8. Riesgos de inyección.
9. Configuración insegura.

Devuelve:
- Hallazgos críticos.
- Hallazgos medios.
- Mejoras recomendadas.
- Plan de corrección incremental.

Documenta el módulo [nombre].

Analiza el código existente y genera documentación en Markdown con:
1. Propósito del módulo.
2. Flujo principal.
3. Archivos importantes.
4. Decisiones técnicas.
5. Cómo ejecutar o probar.
6. Casos de uso.
7. Riesgos conocidos.
8. Posibles mejoras futuras.

No inventes comportamiento. Si algo es inferencia, márcalo como inferencia.

Prepara una descripción de pull request basada en el diff actual.

Incluye:
1. Resumen.
2. Cambios principales.
3. Motivación.
4. Cómo se ha validado.
5. Riesgos.
6. Capturas o notas manuales si aplica.
7. Checklist de revisión.

No modifiques archivos.

Explícame cómo funciona [archivo/módulo/flujo].

Quiero una explicación técnica pero clara:
1. Qué problema resuelve.
2. Cómo entra la información.
3. Qué transformaciones ocurren.
4. Qué dependencias usa.
5. Qué devuelve o modifica.
6. Qué edge cases contempla.
7. Qué riesgos tiene.
8. Qué cambiarías si hubiera que mejorarlo.

No modifiques archivos.

Quiero migrar código legacy de [origen] a [destino].

No modifiques todavía.

Primero:
1. Analiza el comportamiento actual.
2. Identifica dependencias y efectos secundarios.
3. Propón tests de caracterización para proteger el comportamiento.
4. Diseña una migración incremental.
5. Señala riesgos.

Después de confirmar:
- Migra por partes pequeñas.
- Mantén compatibilidad si es necesario.
- Ejecuta tests tras cada paso importante.
- Documenta decisiones.

Quiero diseñar la arquitectura para [sistema/módulo/feature].

No escribas código todavía.

Dame:
1. Objetivo del diseño.
2. Restricciones.
3. Alternativas posibles.
4. Comparación de alternativas.
5. Arquitectura recomendada.
6. Estructura de carpetas propuesta.
7. Interfaces principales.
8. Flujo de datos.
9. Riesgos.
10. Plan incremental de implementación.
11. ADR en Markdown.

Prioriza simplicidad, mantenibilidad y testabilidad.