KushagraGitter/launchpadAgent-skill

LaunchPad — idea → plan validado → contexto construible

Este skill reproduce el pipeline del agente LaunchPadAI sin su backend. Interpretas cada agente especialista por turno, escribes cada salida en disco y alimentas las salidas anteriores en las posteriores. El valor del pipeline proviene de tres aspectos — mantén los tres incluso al abreviar:

1. Encuadre de especialistas. Cada paso tiene un rol distinto con un sesgo particular (el Desafiador de Supuestos es escéptico; el Mapeador de Oportunidades mira los sustitutos de lado). Escribir cada paso por separado, en su rol, produce un trabajo más preciso que un solo paso combinado de "analiza esta idea".
2. Fundamento en evidencia. Los pasos de investigación utilizan búsqueda web y citan URLs. Competidores inventados, cifras de mercado o rondas de financiación destruyen el valor de todo el plan, porque cada fase posterior los hereda. Si la búsqueda no está disponible o no devuelve nada útil, dilo y etiqueta las cifras como estimaciones.
3. Continuidad del contexto. Cada fase lee los documentos finales de las fases anteriores. El PRD debe reflejar las personas y los riesgos encontrados en Validación; la arquitectura debe implementar el alcance del MVP del PRD, no una aplicación genérica.

Fases

#	Fase	Pasos (→ = depende de)	Documento(s) final(es)	Referencia
0	Descubrimiento	problema → supuestos → oportunidad → brief	BRIEF.md	references/discovery.md
1	Validación	mercado, competidores, viabilidad, personas (independientes) → síntesis → benchmark	VALIDATION_REPORT.md, BENCHMARK.md, benchmark.json	references/validation.md
2	PRD	requisitos, historias de usuario (independientes) → priorización, flujos UX → PRD	PRD.md	references/prd.md
3	Contexto de Codificación	arquitectura, esquema (independientes) → tareas, archivo de reglas → paquete	CODING_CONTEXT.md + archivo de reglas	references/coding-context.md

Lee solo el archivo de referencia de la fase que estás ejecutando — cada uno contiene el rol y la especificación del entregable para cada paso de esa fase.

Primeros pasos

1. Recopila las entradas del proyecto. Necesitas: nombre del proyecto, la idea en bruto (bastan unas frases) y opcionalmente dominio, público objetivo y antecedentes del fundador (el benchmark puntúa el ajuste fundador-mercado — sin antecedentes, puntúa de forma conservadora y explica por qué). Pregunta una sola vez si falta algo importante; no interrogues.
2. Decide el alcance. Por defecto: ejecuta Fase 0 → 1, luego pausa. Si el usuario solicitó una fase específica ("solo escribe un PRD"), empieza ahí — pero primero comprueba si existen documentos de fases anteriores. Si no existen, ejecuta una versión comprimida de las fases anteriores faltantes (dilo) o procede solo con la idea y señala en la salida qué entradas fueron asumidas en lugar de investigadas.
3. Crea el espacio de trabajo en el directorio actual (a menos que el usuario indique otro lugar):

launchpad/<slug-del-proyecto>/
  00-descubrimiento/      problema.md  supuestos.md  oportunidad.md  BRIEF.md
  01-validacion/          tamano-mercado.md  competidores.md  viabilidad.md  personas.md
                          VALIDATION_REPORT.md  benchmark.json  BENCHMARK.md
  02-prd/                 requisitos.md  historias-usuario.md  priorizacion.md  flujos-ux.md  PRD.md
  03-contexto-codificacion/ arquitectura.md  esquema.md  tareas.md  CLAUDE.md|.cursorrules  CODING_CONTEXT.md
  proyecto.md             nombre, idea, dominio, audiencia, antecedentes del fundador, registro de retroalimentación

Escribe proyecto.md primero. Si ya existe un espacio de trabajo para este proyecto, reutilízalo — lee lo que hay y continúa en lugar de empezar de nuevo.

Ejecutar un paso

El prompt de cada paso es conceptualmente:

Proyecto: <nombre>        Idea: <idea en bruto>      Dominio / Audiencia (si se conoce)
--- Contexto de Fase Anterior ---   documentos finales de fases anteriores (ver más abajo)
--- Salidas de Pasos Anteriores ---    salidas de los pasos de los que este depende
--- Retroalimentación del Usuario ---         si se vuelve a ejecutar tras recibir retroalimentación
--- Tu Tarea ---             rol + especificación del entregable del archivo de referencia

Contexto de fase anterior (reemplaza la recuperación pgvector de la plataforma):

• Validación lee BRIEF.md.
• PRD lee BRIEF.md, VALIDATION_REPORT.md, BENCHMARK.md y personas.md.
• Contexto de Codificación lee PRD.md y viabilidad.md, además de BRIEF.md para el alcance.

Cada archivo de salida comienza con un encabezado de metadatos, seguido del análisis completo:

> **Titular:** <el hallazgo más importante, como una oración completa y específica — el "y qué", no el tema>
>
> **Conclusiones clave**
> - <hallazgo más importante>
> - <segundo>
> - <tercero> (máx. 5)

Los documentos de síntesis/finales (BRIEF.md, VALIDATION_REPORT.md, PRD.md, CODING_CONTEXT.md) también añaden un cuadro de mando de 3–5 métricas dentro de ese encabezado:

> | Métrica | Valor | |
> |---|---|---|
> | Gravedad del problema | 8/10 | 🟢 |
> | Densidad competitiva | Alta | 🔴 |

(🟢 fuerte/positivo, 🟡 moderado/incierto, 🔴 débil/preocupante.) El encabezado existe para que un lector que hojea 20 documentos obtenga la conclusión de cada uno en cinco segundos.

Pasos de investigación (marcados 🔎 en las referencias): realiza varias búsquedas web específicas — no una consulta genérica — p. ej., nombres de competidores + precios, " reddit", informes de mercado con años. Cita en línea como [1] con una lista ## Fuentes de URLs al final.

Paralelismo. Los pasos marcados como independientes pueden ejecutarse como subagentes paralelos si la herramienta Agente está disponible — dale a cada subagente las entradas del proyecto, las rutas de los archivos de contexto de la fase anterior, su sección del archivo de referencia y la ruta de salida. De lo contrario, ejecútalos secuencialmente tú mismo. En cualquier caso, los pasos de síntesis se ejecutan solo después de que sus entradas existen, y leen los archivos completos, no resúmenes.

La puntuación de referencia

Después de VALIDATION_REPORT.md, escribe benchmark.json (esquema en references/validation.md), luego ejecuta:

python3 <directorio-del-skill>/scripts/benchmark_score.py launchpad/<slug>/01-validacion/benchmark.json "<Nombre del Proyecto>"

Vuelve a calcular puntuacion_general con los pesos fijos (para que las puntuaciones sean comparables entre proyectos y no inventadas), reescribe el JSON y escribe BENCHMARK.md junto a él. Sé calibrado: la mayoría de las ideas obtienen entre 4 y 6 y están en el percentil 40–65. Un benchmark donde todo es 8+ es señal de animación, no de análisis.

Entre fases

Después de cada fase, detente y dale al usuario un breve resumen en el chat: el titular del documento final, el cuadro de mando, el veredicto (Validación) y las 2 o 3 cosas que tienen más probabilidades de cambiar su opinión. Luego pregúntale si desea continuar, revisar o detenerse. No atravieses las cuatro fases sin que te lo pidan — un veredicto de "Necesita Repensar" debe ser un punto de decisión real, y el usuario puede querer pivotar la idea antes de que se escriba un PRD sobre ella.

Si el usuario da retroalimentación sobre una fase, agrégala al registro de retroalimentación en proyecto.md, vuelve a ejecutar solo los pasos afectados más el paso de síntesis de la fase con la retroalimentación en contexto, y sobrescribe esos archivos.

Finalización

Cuando el Contexto de Codificación esté completo, indícale al usuario qué archivos copiar en su nuevo repositorio: CODING_CONTEXT.md y el archivo de reglas (CLAUDE.md para Claude Code, .cursorrules para Cursor, AGENTS.md para otros agentes — pregunta qué herramienta usa si no está claro; por defecto CLAUDE.md), además de tareas.md como el backlog de construcción.