[ 0xSYS // ONLINE ]

RYUKAMI LABS

Mejorar Proyectos Fullstack Dev

Se lee en 24 min

Para mejorar un proyecto con agentes de IA como Claude, Codex, Antigravity, Cursor, Copilot, etc. a nivel profesional, no uses un solo prompt tipo:

“Mejora mi proyecto”.

Eso produce cambios genéricos, inconsistentes o peligrosos.

Lo correcto es usar un sistema de prompts + contexto + reglas + validación humana + pruebas.

Te dejo una guía práctica con prompts listos para copiar/pegar.

1. Regla principal: divide el trabajo en fases

No pidas todo de golpe.

Divide el proyecto en:

  1. Auditoría
  2. Plan de mejora
  3. Arquitectura
  4. Refactorización
  5. Buenas prácticas y nomenclatura
  6. Escalabilidad y rendimiento
  7. Seguridad
  8. Testing
  9. Documentación
  10. CI/CD y automatización
  11. Revisión final

Cada fase debe tener su propio prompt.

2. Prepara tu proyecto antes de usar IA

Antes de pedir mejoras, crea archivos clave en tu repositorio.

Archivo recomendado: AGENTS.md o CLAUDE.md

Este archivo le dice al agente cómo debe trabajar.

Ejemplo:

# Reglas para agentes de IA
 
Este proyecto debe mejorarse siguiendo estándares profesionales.
 
## Stack
- Backend: [ej. Node.js + NestJS]
- Frontend: [ej. React + TypeScript]
- Base de datos: [ej. PostgreSQL]
- Infraestructura: [ej. Docker]
 
## Principios obligatorios
- No romper funcionalidad existente.
- Hacer cambios pequeños y revisables.
- Seguir SOLID, Clean Architecture y DRY.
- Mantener consistencia con el código actual.
- No agregar dependencias innecesarias.
- No modificar secretos ni credenciales.
- Toda nueva funcionalidad debe incluir pruebas.
- Preferir claridad sobre clever code.
- Usar nombres descriptivos en inglés o español consistente.
- No eliminar código sin justificación.
- Si algo no está claro, preguntar antes de cambiar.
 
## Calidad esperada
- Código mantenible.
- Arquitectura escalable.
- Buen manejo de errores.
- Logs estructurados.
- Validación de datos.
- Seguridad básica y avanzada.
- Tests unitarios y de integración.
- Documentación clara.
 
## Formato de respuesta esperado
Cuando propongas cambios:
1. Explica el problema.
2. Explica la solución.
3. Muestra archivos afectados.
4. Entrega diff o código completo.
5. Indica riesgos.
6. Indica pruebas necesarias.

Esto mejora muchísimo la calidad de las respuestas.

3. Prompt maestro para auditoría profesional

Este es el primer prompt que deberías usar.

Prompt de auditoría general

Actúa como un Staff Software Engineer y arquitecto de software senior.
 
Tu objetivo es auditar este proyecto como si fuera a producción en una empresa profesional.
 
Contexto del proyecto:
- Nombre: [NOMBRE]
- Stack: [STACK]
- Objetivo: [QUÉ HACE]
- Usuarios esperados: [CANTIDAD O TIPO]
- Estado actual: [DEV / MVP / PRODUCCIÓN]
- Problemas actuales: [LENTO, DESORDENADO, SIN TESTS, ETC.]
 
Quiero que hagas una auditoría completa en estos aspectos:
 
1. Arquitectura
2. Escalabilidad
3. Mantenibilidad
4. Nomenclatura
5. Estructura de carpetas
6. Buenas prácticas
7. Seguridad
8. Rendimiento
9. Testing
10. Manejo de errores
11. Logging y observabilidad
12. Configuración y variables de entorno
13. Dependencias
14. Documentación
15. CI/CD
16. Deuda técnica
 
Para cada aspecto entrega:
 
- Estado actual: crítico / mejorable / aceptable / bueno
- Problemas encontrados
- Riesgo: alto / medio / bajo
- Impacto: alto / medio / bajo
- Solución recomendada
- Ejemplo concreto de mejora
- Prioridad: P0 / P1 / P2
 
No modifiques código todavía.
Solo entrega una auditoría profesional.

4. Prompt para generar un plan de mejora priorizado

Después de la auditoría, usa este.

Basándote en la auditoría anterior, crea un plan de mejora profesional.
 
Objetivo:
Llevar el proyecto a nivel profesional en arquitectura, escalabilidad, buenas prácticas, seguridad, testing y mantenibilidad.
 
Requisitos:
- No romper funcionalidad existente.
- Dividir el trabajo en fases pequeñas.
- Cada fase debe poder hacerse en 1 día o menos.
- Priorizar primero lo crítico y lo que reduzca riesgo.
- Incluir pruebas en cada fase.
- Incluir criterios de aceptación.
 
Entrega el plan en este formato:
 
## Fase 1: [Nombre]
Objetivo:
Por qué importa:
Cambios:
Archivos probables:
Riesgos:
Pruebas necesarias:
Criterio de done:
 
## Fase 2: [Nombre]
...
 
Ordena las fases por prioridad:
P0 = crítico para producción
P1 = importante para calidad
P2 = mejora deseable

5. Prompt para mejorar arquitectura

Este prompt sirve para Claude, Codex, Antigravity, etc.

Actúa como un arquitecto de software senior.
 
Analiza la arquitectura actual del proyecto y propón una arquitectura profesional, escalable y mantenible.
 
Contexto:
- Stack: [STACK]
- Tipo de sistema: [API / WEB / MONOLITO / MICROSERVICIOS]
- Tráfico esperado: [BAJO / MEDIO / ALTO]
- Restricciones: [PRESUPUESTO, EQUIPO, TIEMPO]
- Problemas actuales: [DESORDEN, ACOPLAMIENTO, LENTITUD]
 
Quiero que evalúes:
 
- Separación de capas
- Domain-driven design
- Clean Architecture
- Inyección de dependencias
- Repositorios
- Servicios
- Controladores
- Casos de uso
- DTOs
- Entidades
- Value objects
- Módulos
- Bounded contexts
- Acoplamiento
- Cohesión
- Escalabilidad horizontal
- Manejo de errores
- Observabilidad
 
Entrega:
 
1. Diagnóstico de la arquitectura actual.
2. Arquitectura recomendada.
3. Diagrama textual de capas y módulos.
4. Estructura de carpetas propuesta.
5. Ejemplo de cómo debería verse un módulo completo.
6. Qué no cambiarías y por qué.
7. Plan de migración sin romper el sistema actual.

6. Prompt para escalabilidad

Actúa como un ingeniero de escalabilidad y rendimiento.
 
Evalúa este proyecto para escalar de [X usuarios] a [Y usuarios].
 
Contexto:
- Stack: [STACK]
- Base de datos: [DB]
- Infraestructura actual: [SERVIDOR / CLOUD / DOCKER]
- Operaciones críticas: [LOGIN, PAGOS, REPORTES, ETC.]
- Cuellos de botella conocidos: [DB, CPU, MEMORIA, RED]
 
Analiza:
 
1. Base de datos
   - Índices
   - Queries N+1
   - Conexiones
   - Paginación
   - Caché
   - Réplicas
   - Particionamiento
 
2. Backend
   - Stateless design
   - Concurrencia
   - Rate limiting
   - Colas
   - Workers
   - Background jobs
   - Timeout y retries
 
3. Infraestructura
   - Escalado horizontal
   - Load balancers
   - Contenedores
   - Health checks
   - Autoscaling
 
4. Observabilidad
   - Métricas
   - Logs
   - Tracing
   - Alertas
 
Entrega:
 
- Problemas de escalabilidad actuales.
- Riesgo de cada problema.
- Solución recomendada.
- Cambio mínimo viable.
- Cambio ideal.
- Cómo medir la mejora.

7. Prompt para buenas prácticas y Clean Code

Actúa como un Tech Lead senior.
 
Revisa el código del proyecto y propón mejoras de buenas prácticas.
 
Quiero que evalúes:
 
- Nombres de variables, funciones, clases y archivos.
- Funciones largas.
- Código duplicado.
- Complejidad ciclomática.
- Manejo de errores.
- Validaciones.
- Side effects.
- Acoplamiento.
- Responsabilidad única.
- SOLID.
- DRY.
- KISS.
- YAGNI.
- Magic numbers.
- Código muerto.
- Comentarios innecesarios.
- Consistencia de estilo.
 
Para cada problema entrega:
 
1. Archivo y línea aproximada.
2. Problema.
3. Por qué es malo.
4. Refactor recomendado.
5. Código antes.
6. Código después.
7. Riesgo del cambio.
8. Prueba necesaria.
 
No hagas cambios masivos.
Propón cambios pequeños y seguros.

8. Prompt para nomenclatura profesional

Actúa como un ingeniero senior obsesionado con la claridad del código.
 
Revisa la nomenclatura del proyecto.
 
Objetivo:
Que cualquier desarrollador entienda el código sin mucha documentación.
 
Evalúa:
 
- Nombres de variables
- Nombres de funciones
- Nombres de clases
- Nombres de archivos
- Nombres de carpetas
- Nombres de endpoints
- Nombres de tablas
- Nombres de columnas
- Nombres de eventos
- Nombres de componentes
- Nombres de hooks
- Nombres de tests
 
Reglas:
- Usar nombres claros, específicos y consistentes.
- Evitar abreviaciones confusas.
- Evitar nombres genéricos como data, info, temp, value, item.
- Los booleanos deben leerse como preguntas: isActive, hasPermission.
- Las funciones deben empezar con verbo: getUser, createOrder.
- Las clases deben ser sustantivos: UserService, OrderRepository.
- Mantener consistencia de idioma en todo el proyecto.
 
Entrega:
 
1. Lista de nombres problemáticos.
2. Nombre actual.
3. Nombre propuesto.
4. Razón.
5. Archivos afectados.
6. Si el cambio es seguro o riesgoso.

9. Prompt para estructura de carpetas

Actúa como un arquitecto de software.
 
Propón una estructura de carpetas profesional para este proyecto.
 
Contexto:
- Tipo de proyecto: [API / WEB / FULLSTACK]
- Stack: [STACK]
- Tamaño actual: [PEQUEÑO / MEDIANO / GRANDE]
- Equipo: [1 DEV / VARIOS DEVS]
- Problemas: [DESORDEN, ACOPLAMIENTO, DUPLICACIÓN]
 
Quiero una estructura que favorezca:
 
- Escalabilidad
- Mantenibilidad
- Testing
- Separación de responsabilidades
- Bajo acoplamiento
- Fácil onboarding de nuevos devs
 
Entrega:
 
1. Estructura actual resumida.
2. Estructura recomendada.
3. Explicación de cada carpeta.
4. Qué archivos van dentro.
5. Qué no debe ir ahí.
6. Plan de migración paso a paso.
7. Riesgos de mover archivos.

10. Prompt para seguridad

Actúa como un Application Security Engineer.
 
Haz una revisión de seguridad del proyecto.
 
Contexto:
- Stack: [STACK]
- Tipo de app: [WEB/API]
- Autenticación: [JWT/SESSION/FIREBASE]
- Datos sensibles: [ correos, pagos, tokens, etc.]
- Deploy: [Docker/VPS/Cloud]
 
Evalúa:
 
- Inyección SQL
- XSS
- CSRF
- Validación de entrada
- Autorización
- Autenticación
- Manejo de secretos
- CORS
- Rate limiting
- Exposición de errores
- Logs sensibles
- Dependencias vulnerables
- File upload
- Session management
- Password hashing
- HTTPS
- Headers de seguridad
- Principio de mínimo privilegio
 
Entrega:
 
1. Vulnerabilidades encontradas.
2. Severidad: crítica/alta/media/baja.
3. Explicación del riesgo.
4. Ejemplo de ataque.
5. Solución recomendada.
6. Código de mitigación.
7. Prueba para validar.

11. Prompt para testing

Actúa como un QA Automation Engineer y senior software engineer.
 
Diseña una estrategia de pruebas profesional para este proyecto.
 
Contexto:
- Stack: [STACK]
- Framework de tests actual: [JEST/VITEST/PYTEST/ETC.]
- Cobertura actual: [NINGUNA / BAJA / MEDIA]
- Partes críticas: [AUTH, PAGOS, DB, ETC.]
 
Quiero:
 
1. Tipos de prueba necesarios:
   - Unit tests
   - Integration tests
   - E2E tests
   - Contract tests
   - Performance tests
 
2. Qué probar primero.
3. Qué no vale la pena testear al inicio.
4. Estructura de carpetas para tests.
5. Convenciones de nombres.
6. Ejemplos de tests unitarios.
7. Ejemplos de tests de integración.
8. Mocks recomendados.
9. Datos de prueba.
10. Cómo medir cobertura útil, no solo porcentaje.
 
Entrega un plan priorizado:
P0: tests críticos
P1: tests importantes
P2: tests deseables

12. Prompt para refactorizar sin romper nada

Este es clave.

Actúa como un senior engineer haciendo refactor seguro.
 
Objetivo:
Refactorizar [ARCHIVO/MÓDULO/FEATURE] sin romper funcionalidad existente.
 
Contexto:
- Archivo principal: [RUTA]
- Responsabilidad actual: [QUÉ HACE]
- Problema: [LARGO, ACOPLADO, DUPLICADO, CONFUSO]
- Tests existentes: [SÍ/NO]
 
Reglas obligatorias:
- No cambiar comportamiento externo.
- No agregar features nuevas.
- No cambiar contratos públicos sin avisar.
- Mantener compatibilidad.
- Hacer cambios pequeños.
- Si faltan tests, proponerlos antes de refactorizar.
 
Entrega:
 
1. Riesgos detectados.
2. Tests mínimos necesarios antes de tocar código.
3. Plan de refactor paso a paso.
4. Código refactorizado.
5. Diff sugerido.
6. Cómo verificar que no se rompió.
7. Rollback plan.

13. Prompt para revisión de pull request

Úsalo después de cada cambio.

Actúa como un reviewer senior muy exigente.
 
Revisa este cambio como si fuera un pull request real.
 
Evalúa:
 
- Correctitud
- Legibilidad
- Arquitectura
- Seguridad
- Performance
- Tests
- Edge cases
- Manejo de errores
- Nomenclatura
- Complejidad
- Riesgo de regresión
- Compatibilidad
- Documentación necesaria
 
Entrega:
 
## Resumen
Resumen del cambio.
 
## Problemas críticos
Cosas que bloquean el merge.
 
## Problemas importantes
Deberían corregirse.
 
## Sugerencias
Mejoras opcionales.
 
## Tests faltantes
Qué pruebas agregar.
 
## Decisión final
- Aprobar
- Aprobar con comentarios
- Solicitar cambios

14. Prompt para documentación profesional

Actúa como un technical writer senior.
 
Crea documentación profesional para este proyecto.
 
Necesito:
 
1. README.md
2. ARCHITECTURE.md
3. CONTRIBUTING.md
4. API.md si aplica
5. DATABASE.md si aplica
6. DEPLOY.md
7. TESTING.md
8. ENVIRONMENT.md
 
La documentación debe ser clara, práctica y orientada a nuevos desarrolladores.
 
Incluye:
 
- Qué hace el proyecto.
- Cómo instalarlo.
- Cómo ejecutarlo.
- Cómo correr tests.
- Cómo desplegar.
- Variables de entorno.
- Estructura del proyecto.
- Decisiones arquitectónicas.
- Troubleshooting común.
 
No inventes comandos.
Si falta información, márcala como [FALTA].

15. Prompt para CI/CD

Actúa como un DevOps engineer senior.
 
Diseña un pipeline de CI/CD profesional para este proyecto.
 
Contexto:
- Plataforma: [GitHub Actions / GitLab CI / CircleCI]
- Stack: [STACK]
- Entornos: [DEV / STAGING / PROD]
- Deploy actual: [MANUAL / DOCKER / CLOUD]
 
Quiero un pipeline que incluya:
 
1. Install dependencies
2. Lint
3. Format check
4. Unit tests
5. Integration tests
6. Build
7. Security scan
8. Dependency audit
9. Docker build
10. Deploy a staging
11. Smoke tests
12. Deploy a producción con aprobación manual
 
Entrega:
 
- Archivo YAML completo.
- Explicación de cada job.
- Secrets necesarios.
- Buenas prácticas.
- Cómo evitar deploys rotos.
- Estrategia de rollback.

16. Prompt para observabilidad

Actúa como un Site Reliability Engineer.
 
Propón una estrategia de observabilidad profesional para este proyecto.
 
Evalúa:
 
- Logs estructurados
- Request IDs
- Métricas
- Health checks
- Tracing distribuido
- Alertas
- Dashboards
- Errores monitoreados
- Latencia
- Tasa de error
- Saturación
- Dependencias externas
 
Entrega:
 
1. Qué observar.
2. Dónde instrumentar.
3. Qué logs no deben faltar.
4. Qué métricas son críticas.
5. Qué alertas configurar.
6. Ejemplos de logs estructurados.
7. Ejemplos de dashboards.
8. Herramientas recomendadas.

17. Prompt para base de datos

Actúa como un database engineer senior.
 
Revisa el diseño y uso de base de datos del proyecto.
 
Contexto:
- Motor: [PostgreSQL/MySQL/MongoDB]
- ORM: [Prisma/TypeORM/Sequelize/Mongoose]
- Tablas principales: [USERS, ORDERS, ETC.]
- Problemas: [QUERIES LENTAS, DUPLICACIÓN, N+1]
 
Evalúa:
 
- Normalización
- Índices
- Relaciones
- Constraints
- Migraciones
- Seeds
- N+1 queries
- Paginación
- Transacciones
- Integridad referencial
- Nombres de tablas y columnas
- Tipos de datos
- Soft delete vs hard delete
- Auditoría de registros
 
Entrega:
 
1. Problemas encontrados.
2. Riesgo.
3. Solución.
4. SQL o migración propuesta.
5. Cómo validar rendimiento.

18. Prompt para frontend profesional

Si tu proyecto tiene frontend:

Actúa como un frontend architect senior.
 
Revisa el frontend del proyecto.
 
Contexto:
- Framework: [React/Vue/Angular/Svelte]
- State management: [Redux/Zustand/Context]
- Styling: [Tailwind/CSS Modules/Styled Components]
- Problemas: [RENDERS, COMPONENTES GIGANTES, DESORDEN]
 
Evalúa:
 
- Estructura de carpetas
- Componentes
- Hooks
- Estado local vs global
- Fetching de datos
- Loading states
- Error states
- Empty states
- Accesibilidad
- Performance
- Code splitting
- Formularios
- Validación
- Tests de componentes
- Nomenclatura
 
Entrega:
 
1. Problemas críticos.
2. Refactors recomendados.
3. Ejemplo de componente profesional.
4. Estructura ideal.
5. Plan de mejora por fases.

19. Prompt para backend profesional

Actúa como un backend architect senior.
 
Revisa el backend del proyecto.
 
Contexto:
- Lenguaje: [Node/Python/Java/Go]
- Framework: [Express/Nest/FastAPI/Spring]
- Base de datos: [DB]
- Auth: [JWT/Sessions/OAuth]
 
Evalúa:
 
- Estructura de capas
- Controladores
- Servicios
- Repositorios
- DTOs
- Validación
- Middlewares
- Manejo de errores
- Logging
- Configuración
- Seguridad
- Testing
- Documentación API
- Versionado de API
- Idempotencia
- Rate limiting
- Transacciones
 
Entrega:
 
1. Diagnóstico.
2. Arquitectura recomendada.
3. Ejemplo de endpoint profesional completo.
4. Errores comunes encontrados.
5. Plan de refactor seguro.

20. Prompt para convertir un proyecto simple en arquitectura profesional

Este es muy útil si tu proyecto está desordenado.

Actúa como un arquitecto de software senior.
 
Tengo un proyecto que actualmente es simple/desordenado.
Quiero llevarlo a una arquitectura profesional sin reescribirlo completamente.
 
Contexto:
- Stack: [STACK]
- Tamaño: [PEQUEÑO/MEDIANO]
- Problemas: [CÓDIGO EN UN SOLO ARCHIVO, SIN CAPAS, SIN TESTS]
- Objetivo: [ESCALABILIDAD, MANTENIBILIDAD, PRODUCCIÓN]
 
Necesito un plan incremental.
 
Reglas:
- No reescribir todo de golpe.
- Mantener el sistema funcionando.
- Hacer migración por módulos.
- Introducir pruebas antes de refactorizar.
- Priorizar lo crítico.
 
Entrega:
 
1. Arquitectura objetivo.
2. Capas recomendadas.
3. Módulos a separar primero.
4. Orden exacto de refactorización.
5. Qué tests agregar en cada paso.
6. Cómo evitar regresiones.
7. Ejemplo de un módulo migrado.

21. Prompt multi-agente: arquitecto, desarrollador, reviewer y QA

Si usas agentes con herramientas, puedes simular roles.

Quiero que trabajes con 4 roles profesionales.
 
Rol 1: Arquitecto
- Define la solución.
- Evalúa impacto arquitectónico.
- Detecta riesgos.
- Define contratos y límites de módulos.
 
Rol 2: Desarrollador senior
- Implementa la solución.
- Escribe código limpio.
- Sigue las reglas del proyecto.
- Entrega cambios pequeños.
 
Rol 3: Code reviewer
- Revisa calidad, seguridad y mantenibilidad.
- Detecta malas prácticas.
- Pide tests si faltan.
 
Rol 4: QA engineer
- Define casos de prueba.
- Detecta edge cases.
- Valida regresiones.
- Propone pruebas automáticas.
 
Para cada tarea:
 
1. El arquitecto propone el plan.
2. El desarrollador entrega el código.
3. El reviewer hace observaciones.
4. QA entrega el plan de pruebas.
5. Entrega final con cambios aprobados.
 
No entregues nada sin pasar por los 4 roles.

22. Prompt para que la IA no haga cambios peligrosos

Muy importante.

Antes de modificar código, sigue este protocolo:
 
1. No asumas comportamiento.
2. Si falta contexto, pregunta.
3. Identifica archivos afectados.
4. Identifica contratos públicos afectados.
5. Identifica posibles regresiones.
6. Propón pruebas necesarias.
7. Entrega el cambio mínimo posible.
8. Si el cambio es grande, divídelo en pasos.
9. No ejecutes migraciones destructivas sin confirmación.
10. No elimines datos.
11. No cambies dependencias mayores sin justificación.
12. No modifiques autenticación o pagos sin análisis de riesgo.
 
Si detectas riesgo alto, detente y explica.

23. Prompt para mejorar rendimiento

Actúa como un performance engineer.
 
Analiza el rendimiento del proyecto.
 
Objetivo:
Reducir latencia, consumo de memoria y carga de base de datos.
 
Evalúa:
 
- Queries lentas
- N+1
- Falta de índices
- Caché
- Payloads grandes
- Serialización
- Renders innecesarios
- Bundle size
- Concurrencia
- Blocking operations
- Logs excesivos
- Calls externos sin timeout
 
Entrega:
 
1. Cuellos de botella probables.
2. Cómo medirlos.
3. Solución rápida.
4. Solución estructural.
5. Riesgo de cada cambio.
6. Métrica esperada de mejora.

24. Prompt para API profesional

Actúa como un API designer senior.
 
Revisa y mejora el diseño de la API.
 
Evalúa:
 
- Recursos y nombres
- Verbos HTTP
- Códigos de estado
- Versionado
- Paginación
- Filtros
- Ordenamiento
- Errores estándar
- Rate limiting
- Autenticación
- Autorización
- Idempotencia
- Documentación OpenAPI
- HATEOAS si aplica
- Compatibilidad
 
Entrega:
 
1. Problemas de diseño.
2. Convenciones recomendadas.
3. Ejemplo de endpoint antes y después.
4. Formato estándar de error.
5. Plan de migración sin romper clientes.

25. Prompt para errores y manejo de excepciones

Actúa como un senior engineer.
 
Revisa el manejo de errores del proyecto.
 
Quiero un sistema profesional de errores.
 
Evalúa:
 
- Errores no controlados
- Mensajes ambiguos
- Stack traces expuestos
- Falta de logging
- Errores de validación
- Errores de negocio
- Errores de infraestructura
- Respuestas HTTP inconsistentes
 
Entrega:
 
1. Estrategia de manejo de errores.
2. Jerarquía de errores.
3. Errores de dominio vs errores técnicos.
4. Middleware o handler global.
5. Formato de respuesta de error.
6. Qué loguear.
7. Qué no loguear.
8. Ejemplos de código.

26. Prompt para variables de entorno y configuración

Actúa como un DevOps/software engineer senior.
 
Revisa la configuración del proyecto.
 
Evalúa:
 
- Variables de entorno
- Secrets
- Configuración por ambiente
- Validación de env vars
- Defaults seguros
- Archivos .env
- Configuración centralizada
- Feature flags
 
Entrega:
 
1. Problemas actuales.
2. Lista de variables necesarias.
3. Ejemplo de .env.example.
4. Validación de configuración al iniciar.
5. Buenas prácticas para producción.
6. Qué secretos nunca deben estar en el repo.

27. Prompt para dependencias

Actúa como un software supply chain engineer.
 
Revisa las dependencias del proyecto.
 
Evalúa:
 
- Dependencias innecesarias
- Dependencias duplicadas
- Versiones desactualizadas
- Vulnerabilidades
- Licencias
- Peso
- Mantenibilidad
- Alternativas más simples
 
Entrega:
 
1. Dependencias críticas.
2. Dependencias que se pueden eliminar.
3. Dependencias que se deben actualizar.
4. Riesgos de actualizar.
5. Plan seguro de actualización.

28. Prompt para Definition of Done profesional

Úsalo como checklist final.

Actúa como un engineering manager senior.
 
Define el Definition of Done profesional para este proyecto.
 
Debe incluir:
 
- Código revisado
- Tests pasando
- Cobertura útil
- Lint sin errores
- Build exitoso
- Documentación actualizada
- Seguridad revisada
- Performance aceptable
- Logs correctos
- Manejo de errores
- Configuración documentada
- CI/CD funcionando
- Rollback posible
- Observabilidad básica
- Accesibilidad si aplica
- Validación de datos
- Autorización correcta
 
Entrega:
 
1. Checklist obligatorio para merge.
2. Checklist obligatorio para deploy.
3. Checklist obligatorio para producción.
4. Qué métricas monitorear después del deploy.

29. Checklist profesional para tu proyecto

Cuando la IA te proponga cambios, verifica que cumpla esto.

Arquitectura

  • Capas claras.
  • Bajo acoplamiento.
  • Alta cohesión.
  • No hay lógica de negocio en controladores o UI.
  • Módulos bien definidos.
  • Dependencias en una sola dirección.

Código

  • Nombres claros.
  • Funciones pequeñas.
  • Sin duplicación grave.
  • Sin magia oculta.
  • Errores manejados.
  • Código fácil de borrar/cambiar.

Escalabilidad

  • Stateless backend.
  • Base de datos con índices.
  • Caché donde tenga sentido.
  • Jobs pesados en cola.
  • Paginación.
  • Health checks.

Seguridad

  • Validación de entrada.
  • Autorización correcta.
  • Secretos fuera del código.
  • Passwords hasheados.
  • Rate limiting.
  • CORS configurado.
  • Logs sin datos sensibles.

Testing

  • Tests unitarios críticos.
  • Tests de integración.
  • Tests de endpoints importantes.
  • Datos de prueba.
  • CI corre tests.

Observabilidad

  • Logs estructurados.
  • Request ID.
  • Métricas básicas.
  • Alertas críticas.
  • Health endpoint.

Documentación

  • README claro.
  • Cómo instalar.
  • Cómo correr.
  • Cómo testear.
  • Variables de entorno.
  • Arquitectura explicada.

30. Flujo recomendado con agentes IA

Este es el flujo profesional:

1. Crear rama Git.
2. Dar contexto al agente.
3. Pedir auditoría.
4. Pedir plan priorizado.
5. Elegir una tarea pequeña.
6. Pedir tests antes del cambio.
7. Pedir implementación mínima.
8. Pedir review.
9. Correr tests/lint/build.
10. Hacer commit pequeño.
11. Repetir.

No dejes que la IA haga:

“Refactoriza todo el proyecto”

Mejor:

“Refactoriza solo el módulo de autenticación, sin romper login, agregando tests y siguiendo Clean Architecture”

31. Prompt para cada tarea pequeña

Usa este formato siempre.

Tarea: [NOMBRE]
 
Objetivo:
[QUÉ QUIERES LOGRAR]
 
Archivos relevantes:
[LISTA]
 
Comportamiento actual:
[CÓMO FUNCIONA HOY]
 
Comportamiento deseado:
[CÓMO DEBE FUNCIONAR]
 
Restricciones:
- No romper tests existentes.
- No cambiar contratos públicos.
- No agregar dependencias nuevas sin justificación.
- Mantener estilo actual.
- Cambio pequeño y revisable.
 
Entrega:
1. Plan.
2. Riesgos.
3. Tests necesarios.
4. Código.
5. Cómo verificar.

32. Prompt para que te entregue diffs

Muy útil para Codex/Claude Code.

No reescribas archivos completos si no es necesario.
Entrega los cambios como diff unified.
 
Incluye:
- Ruta del archivo.
- Cambio mínimo.
- Explicación por hunk.
- Riesgo del cambio.
- Prueba para validar.
 
Si el cambio es riesgoso, divídelo en varios diffs pequeños.

33. Prompt para evitar alucinaciones

No inventes librerías, comandos, archivos ni APIs.
Si no estás seguro, dilo.
Si necesitas ver un archivo, pide verlo.
Si necesitas ejecutar un comando, indícalo pero no asumas el resultado.
Basa tus recomendaciones solo en el contexto proporcionado.

34. Prompt para revisión de deuda técnica

Actúa como un CTO técnico.
 
Evalúa la deuda técnica del proyecto.
 
Clasifica la deuda en:
 
1. Deuda crítica
2. Deuda alta
3. Deuda media
4. Deuda baja
 
Para cada elemento entrega:
 
- Descripción
- Impacto en negocio
- Impacto técnico
- Costo de arreglar
- Costo de no arreglar
- Riesgo
- Recomendación
 
Luego entrega un roadmap de 30 días para reducir la deuda sin detener el desarrollo.

35. Prompt para onboarding de nuevos desarrolladores

Actúa como un engineering lead.
 
Crea un plan de onboarding para que un desarrollador junior-semi pueda entender este proyecto en 5 días.
 
Incluye:
 
- Día 1: setup y comprensión general.
- Día 2: arquitectura y flujo de datos.
- Día 3: módulos críticos.
- Día 4: testing y debugging.
- Día 5: primera tarea pequeña.
 
Entrega:
 
1. Checklist diario.
2. Archivos que debe leer.
3. Comandos que debe ejecutar.
4. Preguntas que debe responder.
5. Tarea segura para empezar.

36. Prompt para decisiones arquitectónicas ADR

Actúa como un arquitecto de software.
 
Crea Architecture Decision Records para las decisiones importantes del proyecto.
 
Necesito ADRs para:
 
- Elección de arquitectura
- Elección de base de datos
- Autenticación
- Estructura de carpetas
- Estrategia de testing
- Manejo de errores
- Logging
- Deploy
 
Cada ADR debe tener:
 
1. Título
2. Estado
3. Contexto
4. Decisión
5. Consecuencias
6. Alternativas consideradas
7. Riesgos

37. Prompt para producción

Actúa como un SRE senior.
 
Evalúa si este proyecto está listo para producción.
 
Revisa:
 
- Seguridad
- Performance
- Escalabilidad
- Backups
- Rollback
- Monitoreo
- Alertas
- Logs
- Health checks
- Rate limiting
- Límites de recursos
- Manejo de errores
- Recuperación ante fallos
- Pruebas de carga
- Plan de incidentes
 
Entrega:
 
1. Go / No Go.
2. Riesgos críticos.
3. Tareas obligatorias antes de producción.
4. Tareas recomendables.
5. Checklist final.

38. Prompt para mejorar un módulo específico

Ejemplo práctico:

Actúa como un senior engineer.
 
Vamos a mejorar el módulo de [AUTH/PAGOS/USUARIOS/REPORTES].
 
Objetivo:
Hacerlo profesional, mantenible, seguro y testeable.
 
Archivos actuales:
[PEGAR RUTAS]
 
Problemas:
[CÓDIGO LARGO, SIN VALIDACIÓN, SIN TESTS]
 
Quiero que entregues:
 
1. Diagnóstico.
2. Diseño propuesto.
3. Separación de responsabilidades.
4. DTOs/validaciones.
5. Servicio.
6. Repositorio si aplica.
7. Controlador si aplica.
8. Tests unitarios.
9. Tests de integración.
10. Manejo de errores.
11. Logs.
12. Riesgos.
13. Plan de migración.

39. Prompt para mejorar sin cambiar comportamiento

Quiero mejorar la calidad interna del código sin cambiar comportamiento externo.
 
Haz un refactor seguro.
 
Reglas:
- Primero identifica comportamiento actual.
- Segundo propone tests que congelen el comportamiento.
- Tercero refactoriza.
- Cuarto verifica que los tests siguen pasando.
 
No agregues nuevas features.
No cambies respuestas de API.
No cambies nombres públicos si puede romper clientes.

40. Prompt final de revisión nivel “empresa”

Actúa como un comité técnico senior formado por:
 
- Arquitecto
- Security engineer
- SRE
- QA lead
- Tech lead
 
Evalúen este proyecto para decidir si cumple estándar profesional.
 
Califiquen del 1 al 10:
 
- Arquitectura
- Escalabilidad
- Seguridad
- Testing
- Observabilidad
- Documentación
- Mantenibilidad
- Performance
- DevOps
- Calidad de código
 
Para cada área:
 
1. Nota.
2. Justificación.
3. Problemas principales.
4. Qué falta para llegar a 9/10.
5. Prioridad de mejora.
 
Al final entreguen:
 
- Top 10 problemas.
- Plan de 2 semanas.
- Plan de 30 días.
- Qué no debería pasar a producción todavía.

41. Cómo usar estos prompts según la herramienta

Claude / Claude Code

Úsalo para:

  • Arquitectura.
  • Refactors grandes explicados.
  • Revisión de código.
  • Documentación.
  • Razonamiento profundo.

Buen prompt:

Primero analiza, no modifiques.
Luego propón un plan.
Después entrega cambios pequeños con diff.

Codex / agentes con ejecución

Úsalo para:

  • Ejecutar tests.
  • Aplicar patches.
  • Refactors repetitivos.
  • Crear archivos.
  • Correr lint/build.

Buen prompt:

Ejecuta los tests antes y después del cambio.
Si fallan, revierte o corrige.
No hagas commit sin verificar.

Antigravity / agentes autónomos

Úsalo con más control:

Trabaja solo en esta tarea.
No toques otros módulos.
Genera un reporte de cambios.
Pide confirmación antes de cambios destructivos.

Cursor / IDE con IA

Úsalo para:

  • Cambios locales.
  • Explicación de archivos.
  • Refactors pequeños.
  • Tests de un componente.

Buen prompt:

Usa solo los archivos seleccionados como contexto.
No asumas código que no está visible.

42. Errores comunes al usar IA para mejorar proyectos

No hagas esto:

Mejora todo el proyecto.
Hazlo profesional.
Arregla la arquitectura.
Vuelve el código escalable.

Son prompts demasiado amplios.

Mejor:

Refactoriza el módulo de usuarios para separar controlador, servicio y repositorio.
Agrega validación de DTOs.
No cambies la respuesta actual de la API.
Incluye tests unitarios.

43. Fórmula de prompt profesional

Usa siempre esta estructura:

Rol:
[Senior architect / QA / DevOps / Security]
 
Contexto:
[Proyecto, stack, archivos, problema]
 
Objetivo:
[Qué quieres lograr]
 
Restricciones:
[No romper, no agregar dependencias, mantener API]
 
Formato de salida:
[Plan, diff, tests, riesgos, checklist]
 
Validación:
[Cómo se prueba]

Ejemplo:

Rol: Senior backend engineer.
 
Contexto:
API en Node.js con Express, sin capas, sin validación.
 
Objetivo:
Separar rutas, controladores, servicios y repositorios.
 
Restricciones:
No cambiar respuestas HTTP actuales.
No romper login.
No agregar dependencias nuevas.
 
Formato:
1. Plan.
2. Archivos afectados.
3. Código.
4. Tests.
5. Riesgos.
 
Validación:
Los tests actuales y nuevos deben pasar.

44. Prompt recomendado para empezar hoy

Si quieres empezar ya, usa este:

Actúa como un Staff Engineer.
 
Quiero llevar este proyecto a nivel profesional.
 
Primero no modifiques código.
Haz una auditoría completa.
 
Evalúa:
- Arquitectura
- Escalabilidad
- Seguridad
- Testing
- Nomenclatura
- Estructura
- Performance
- Documentación
- DevOps
- Manejo de errores
- Observabilidad
 
Entrega:
1. Diagnóstico general.
2. Top 10 problemas críticos.
3. Riesgo de cada problema.
4. Solución recomendada.
5. Plan de mejora en fases pequeñas.
6. Qué información necesitas de mí o del repo para continuar.
 
No propongas reescribir todo.
Prioriza mejoras incrementales y seguras.

45. Mi recomendación final

Para mejorar un proyecto con IA a nivel profesional:

  1. No pidas magia.
  2. Da contexto.
  3. Define reglas.
  4. Divide en tareas pequeñas.
  5. Pide auditoría antes de código.
  6. Pide plan antes de implementación.
  7. Pide tests antes de refactorizar.
  8. Pide diffs pequeños.
  9. Valida con lint, tests y build.
  10. Documenta decisiones.

La IA mejora muchísimo cuando la tratas como un ingeniero junior muy rápido pero que necesita:

  • contexto claro,
  • límites claros,
  • criterios de aceptación,
  • y revisión humana.

Si quieres, en el siguiente mensaje te puedo armar un pack completo de prompts profesionales para tu proyecto específico, por ejemplo:

  • pack para backend,
  • pack para frontend,
  • pack para arquitectura,
  • pack para seguridad,
  • pack para testing,
  • pack para escalabilidad,
  • o un mega workflow para Claude/Codex/Antigravity.

Vista Gráfica