# Prompts y Engineering para Vibe Coding

## Fundamentos del Prompt Engineering en Vibe Coding

### ¿Por qué es Crítico el Prompt Engineering?

El prompt engineering en Vive Coding no es opcional - es la diferencia entre:
- **Éxito**: Aplicaciones funcionales creadas en días
- **Fracaso**: Semanas de debugging y frustraciones

**Estadísticas reales**:
- Prompts mal estructurados: 10% de éxito
- Prompts optimizados: 80%+ de éxito
- Tiempo ahorrado: De meses a días de desarrollo

## Estructura XML: La Base de Todo

### ¿Por qué XML funciona mejor?

**Base científica**:
- Los modelos de IA detectan y clasifican mejor la información estructurada
- Inspirado en system prompts de empresas como Cursor ($9B valuación)
- Separa claramente contexto, evitando confusión entre secciones

### Anatomía de un Prompt XML Efectivo

```xml
<meta>
[Objetivo claro y específico del proyecto]
</meta>

<inspirations>
[Referencias específicas con razones]
</inspirations>

<guidelines>
[Directrices técnicas específicas]
</guidelines>

<practicalities>
[Consideraciones prácticas implementables]
</practicalities>

<context>
[Contexto detallado del proyecto]
</context>
```

**Ejemplo malo (genérico)**:
```
Crea una aplicación web moderna que sea bonita y funcional
```

**Ejemplo bueno (estructurado)**:
```xml
<meta>
Crear una aplicación web estilo Netflix para gestión de cursos online con dashboard administrativo y reproductor de video personalizado.
</meta>

<inspirations>
- Netflix: Interfaz de navegación por categorías y reproductor inmersivo
- Udemy: Sistema de progreso y estructura de cursos
- Notion: Diseño minimalista y organización intuitiva
</inspirations>
```

## Prompts para Vibe Planning

### Prompt 1: Arquitectura Técnica

**Template optimizada**:
```xml
<meta>
Crear una [TIPO_APP] que permita [FUNCIONALIDAD_PRINCIPAL].
La aplicación debe [OBJETIVOS_ESPECÍFICOS_MEDIBLES].
</meta>

<inspirations>
- [APP_REFERENCIA_1]: [CARACTERÍSTICA_ESPECÍFICA_A_REPLICAR]
- [APP_REFERENCIA_2]: [ELEMENTO_DISEÑO_O_UX]
- [APP_REFERENCIA_3]: [FUNCIONALIDAD_TÉCNICA]
</inspirations>

<guidelines>
Stack técnico obligatorio:
- Frontend: [FRAMEWORK_ESPECÍFICO] con [LENGUAJE]
- Backend: [FRAMEWORK_BACKEND] con [LENGUAJE]  
- Base de datos: [TIPO_DB_ESPECÍFICA]
- Estilo: [FRAMEWORK_CSS] con estética [ESTILO_ESPECÍFICO]
- Patrones: [PATRONES_ARQUITECTURA]
</guidelines>

<practicalities>
- Desarrollo containerizado con Docker Compose
- APIs [TIPO_API] para comunicación
- Autenticación [TIPO_AUTH]
- Almacenamiento [ESTRATEGIA_STORAGE]
- Deploy en [TIPO_HOSTING]
</practicalities>

<context>
[USUARIOS_OBJETIVO]: [DESCRIPCIÓN_DETALLADA]
[CASOS_USO_ESPECÍFICOS]: [ESCENARIOS_REALES]
[BUSINESS_LOGIC]: [REGLAS_NEGOCIO_ESPECÍFICAS]
</context>
```

### Prompt 2: Features y Funcionalidades

**Template de Features**:
```xml
<mvp_core>
Funcionalidades imprescindibles para el lanzamiento:
1. [FUNCIONALIDAD_1]: [DESCRIPCIÓN_ESPECÍFICA]
2. [FUNCIONALIDAD_2]: [DESCRIPCIÓN_ESPECÍFICA]
[...continuar con todas las MVP features]
</mvp_core>

<user_stories>
Como [TIPO_USUARIO] quiero [ACCIÓN_ESPECÍFICA] para [BENEFICIO_CONCRETO]:
- Usuario anónimo: "poder registrarme con email/password para acceder a la plataforma"
- Usuario registrado: "crear prompts optimizados desde ideas de máximo 2 líneas"
- Usuario premium: "exportar documentación generada en formatos PDF y Markdown"
</user_stories>

<technical_specs>
Para cada funcionalidad definir:
- Endpoint de API necesario
- Estructura de datos
- Validaciones requeridas
- Estados de la aplicación
- Flujo de información
</technical_specs>

<constraints>
Restricciones técnicas y de negocio:
- Rendimiento: [MÉTRICAS_ESPECÍFICAS]
- Seguridad: [REQUIREMENTS_MÍNIMOS]
- Escalabilidad: [LÍMITES_INICIALES]
- Presupuesto: [RESTRICCIONES_COSTO]
</constraints>
```

### Prompt 3: Plan de Acción

**Template de Plan**:
```xml
<project_structure>
Crear plan de desarrollo paso a paso donde cada tarea sea completamente independiente y ejecutable.
Orden lógico: infraestructura -> backend -> frontend -> integración -> funcionalidades.
</project_structure>

<task_requirements>
Cada tarea debe incluir:
- Objetivo claro y medible
- Archivos específicos a crear/modificar
- Comandos exactos a ejecutar
- Criterios de verificación
- Dependencias de tareas anteriores
</task_requirements>

<implementation_guidelines>
- Utilizar Docker para servicios
- Metodología TDD básica
- Git workflow con ramas feature
- Verificación incremental
- Documentación inline
</implementation_guidelines>

<output_format>
Formato: "Tarea X.Y: [TÍTULO_DESCRIPTIVO]"
Incluir subtareas numeradas
Especificar archivos y directorios exactos
Proporcionar comandos específicos de verificación
</output_format>
```

## Prompts para Vibe Design

### Análisis de Prompts Visuales

**Por qué usar referencias visuales**:
- Las AIs procesan mejor imágenes de referencia que descripciones textuales
- Reduce ambigüedad en interpretación de "estético" o "profesional"
- Acelera iteraciones de diseño

### Template para Vibe Design

```xml
<design_goal>
Crear diseño [TIPO_INTERFAZ] inspirado en [REFERENCIAS_ESPECÍFICAS] 
para [TIPO_USUARIOS] con enfoque en [OBJETIVO_UX].
</design_goal>

<visual_references>
Adjunto imágenes de:
1. [IMAGEN_1]: Layout y estructura general
2. [IMAGEN_2]: Paleta de colores y tipografía
3. [IMAGEN_3]: Componentes específicos (botones, forms, etc.)
</visual_references>

<design_system>
- Paleta: [COLORES_ESPECÍFICOS_HEX]
- Tipografía: [FUENTES_ESPECÍFICAS]
- Espaciado: [SISTEMA_GRID]
- Componentes: [LIBRERÍA_UI]
- Iconografía: [ESTILO_ICONOS]
</design_system>

<responsive_strategy>
- Mobile-first approach
- Breakpoints: [PÍXELES_ESPECÍFICOS]
- Touch interactions optimized
- Performance considerations
</responsive_strategy>
```

## Prompts para Vibe Coding

### Contextualización Efectiva

**Template de contexto para editores**:
```
# Project Context
Located in: `/path/to/project`
Documentation: `docs/` folder contains architecture.md and features.md
Design references: `design/` folder contains visual mockups

## Current Task
[TAREA_ESPECÍFICA_DEL_PLAN_DE_ACCIÓN]

## Implementation Requirements
- Follow existing code patterns
- Maintain consistency with previous implementations
- Use established error handling
- Include necessary imports and dependencies

## Verification
After implementation, verify:
1. [CRITERIO_1]
2. [CRITERIO_2]
3. [CRITERIO_3]
```

### Prompts de Debugging

**Template para resolución de errores**:
```xml
<error_context>
Error encontrado: [MENSAJE_ERROR_EXACTO]
Archivo afectado: [RUTA_ARCHIVO]
Línea: [NÚMERO_LÍNEA]
</error_context>

<current_implementation>
Código actual que falla:
```[LENGUAJE]
[CÓDIGO_PROBLEMÁTICO]
```
</current_implementation>

<expected_behavior>
Comportamiento esperado:
- [DESCRIPCIÓN_ESPECÍFICA]
- [RESULTADO_DESEADO]
</expected_behavior>

<debug_request>
Por favor:
1. Identifica la causa raíz del error
2. Proporciona solución específica
3. Explica por qué ocurre el problema
4. Sugiere prevención de errores similares
</debug_request>
```

## Prompts Específicos por Herramienta

### Claude Code

**Aprovechando comandos específicos**:
```
/init - Para crear documentación inicial del proyecto
/memory show - Para verificar contexto actual
/clear - Para limpiar contexto cuando sea necesario

# Context optimization for Claude Code
Utiliza el servidor MCP de Context 7 para consultas de documentación oficial.
No busques en internet antes de consultar MCP.

Implementa tarea por tarea siguiendo el plan de acción.
Verifica cada implementación antes de continuar.
```

### Cursor

**Optimización para Cursor**:
```
# Cursor-specific instructions
Use codebase context (@codebase) when referencing existing patterns
Reference specific files with @filename when needed
Utilize Composer for multi-file operations

Follow established project conventions:
- File naming: [CONVENCIÓN]
- Code formatting: [ESTILO]
- Import organization: [PATRÓN]
```

### Gemini CLI

**Aprovechando memoria de Gemini**:
```
/memory add "Este proyecto se levanta con docker-compose up"
/memory add "Usar Tailwind para estilos, no CSS puro"
/memory add "FastAPI para backend, Next.js para frontend"

# Gemini-specific context
Revisar archivo gemini.md para contexto completo del proyecto.
Mantener consistencia con decisiones arquitectónicas previas.
```

## Técnicas Avanzadas de Prompting

### Chain of Thought para Arquitectura

```xml
<thinking_process>
Vamos a razonar paso a paso sobre la arquitectura:

1. Tipo de aplicación: [ANÁLISIS]
2. Usuarios esperados: [ANÁLISIS] 
3. Carga de trabajo: [ANÁLISIS]
4. Escalabilidad requerida: [ANÁLISIS]
5. Complejidad técnica: [ANÁLISIS]

Por tanto, la arquitectura óptima sería: [CONCLUSIÓN]
</thinking_process>
```

### Few-Shot Examples

**Proporcionando ejemplos concretos**:
```xml
<examples>
Ejemplo similar 1:
- Proyecto: Plataforma de cursos
- Stack usado: Next.js + FastAPI + PostgreSQL
- Resultado: [DESCRIPCIÓN_ÉXITO]

Ejemplo similar 2:
- Proyecto: SaaS de productividad  
- Stack usado: React + Django + MySQL
- Resultado: [DESCRIPCIÓN_ÉXITO]

Para nuestro proyecto aplicar patrones similares adaptados.
</examples>
```

### Constraint-Based Prompting

```xml
<hard_constraints>
Restricciones que NO pueden violarse:
- Presupuesto máximo: [CANTIDAD]
- Tiempo de desarrollo: [PLAZO]
- Tecnologías prohibidas: [LISTA]
- Rendimiento mínimo: [MÉTRICAS]
</hard_constraints>

<soft_constraints>  
Preferencias (pueden ajustarse si es necesario):
- Preferir tecnologías populares
- Minimizar dependencias externas
- Priorizar mantenibilidad sobre performance extremo
</soft_constraints>
```

## Mejores Prácticas de Prompting

### DO's Fundamentales

1. **Especificidad sobre Generalización**
   - ✅ "Dashboard estilo Netflix con navegación lateral y reproductor centrado"
   - ❌ "Dashboard bonito y moderno"

2. **Contexto Progresivo**
   - ✅ Información en capas: básico → intermedio → avanzado
   - ❌ Todo el contexto de una vez

3. **Verificación Incremental**
   - ✅ "Implementa esta feature y verifica que funciona antes de continuar"
   - ❌ "Implementa todas las features de una vez"

4. **Referencias Concretas**
   - ✅ "Como Notion para organización, como Stripe para pagos"
   - ❌ "Con buena UX y sistema de pagos"

### DON'Ts Críticos

1. **Prompts Vagos**
   - ❌ "Crea una app que haga dinero"
   - ❌ "Hazlo profesional y escalable"

2. **Sobrecargar Contexto**
   - ❌ Pegar 50 páginas de documentación de una vez
   - ❌ Incluir información irrelevante

3. **Saltar Verificaciones**
   - ❌ Continuar sin verificar que la implementación anterior funciona
   - ❌ Acumular errores entre tareas

4. **Ignorar Herramientas Específicas**
   - ❌ Usar el mismo prompt para Claude Code y Cursor
   - ❌ No aprovechar comandos específicos de cada herramienta

## Plantillas Listas para Usar

### Prompt de Inicio de Proyecto
```xml
<project_initialization>
Voy a iniciar un nuevo proyecto de [TIPO] usando metodología Vibe Coding.

Contexto del proyecto:
- Documentación: carpeta docs/ contiene architecture.md, features.md, plan.md
- Diseños: carpeta design/ contiene mockups de referencia
- Setup: usar Docker para desarrollo

Primera tarea del plan de acción:
[COPIAR_TAREA_1_COMPLETA_DEL_PLAN]

Implementar esta tarea completamente antes de continuar con la siguiente.
</project_initialization>
```

### Prompt de Debugging Universal
```xml
<debug_session>
Error encontrado en implementación actual:

Síntoma: [DESCRIPCIÓN_PROBLEMA]
Error específico: [MENSAJE_ERROR]
Ubicación: [ARCHIVO_Y_LÍNEA]

Contexto del proyecto disponible en:
- docs/architecture.md
- docs/features.md  
- Implementaciones previas funcionando

Por favor diagnostica y soluciona manteniendo consistencia con el resto del código.
</debug_session>
```

### Prompt de Optimización
```xml
<optimization_request>
La implementación actual funciona pero requiere optimización:

Área a optimizar: [ESPECÍFICA]
Problema actual: [DESCRIPCIÓN]
Objetivo: [MÉTRICA_ESPECÍFICA]

Mantener:
- Funcionalidad existente
- Compatibilidad con código actual
- Patrones establecidos del proyecto

Optimizar sin romper funcionalidades existentes.
</optimization_request>
```

## Métricas de Éxito de Prompts

### KPIs de Prompt Effectiveness

1. **Tasa de Implementación Correcta**
   - Meta: >80% primera vez
   - Medición: Funcionalidad implementada sin errores

2. **Tiempo de Iteración**  
   - Meta: <5 iteraciones por tarea
   - Medición: Prompts adicionales necesarios

3. **Consistencia Arquitectónica**
   - Meta: 100% adherencia a decisiones previas
   - Medición: Violaciones de patrones establecidos

4. **Claridad de Output**
   - Meta: Cero ambigüedades
   - Medición: Preguntas de clarificación necesarias

### Indicadores de Prompt Malo

- **Red flags**:
  - La IA pide clarificaciones básicas
  - Implementaciones inconsistentes con el proyecto
  - Errores repetitivos en similar contexto
  - Soluciones genéricas en lugar de específicas

### Optimización Continua

**Proceso de mejora**:
1. **Documentar**: Qué prompts funcionan mejor para qué tareas
2. **Iterar**: Refinar prompts basado en resultados
3. **Personalizar**: Adaptar prompts a tu estilo de proyecto
4. **Compartir**: Con la comunidad para feedback y mejora

## Próximos Pasos

Una vez dominado el prompt engineering:
1. **Aplicar a Vibe Design**: Usar prompts visuales efectivos
2. **Integrar con herramientas**: Personalizar para Claude Code/Cursor/etc.
3. **Desarrollar templates propios**: Crear prompts específicos para tu dominio
4. **Automatizar workflow**: Crear secuencias de prompts para tareas comunes