/project-foundation ordena la definición de un producto nuevo: por qué se construye (Constitución), qué se construye (PRD y SRS) y cómo encaja el sistema en su mundo (Discovery). Deja los documentos que todas las skills que vienen después dan por hechos.
Modelo de negocio y contexto de mercado.
Problema, personas, journeys y el corte del MVP.
Traspaso a /design-system: sale el DESIGN.md.
Contrato técnico y las primeras decisiones de arquitectura.
Mapas de negocio, guía de desarrollo, plan maestro y glosario.
Se invoca al inicio, antes de montar la infraestructura y antes de sembrar el backlog. Si el alcance cambia mucho a mitad de camino, se vuelve a correr solo la fase que hace falta.
Una app cuyo código ya existe no tiene un producto que definir: su fundación es lo que el código hace, escrito. Aplica cuando .template/installer.lock.json dice adopted: true (el mismo dato que lee /project-context) o cuando pides documentar una app existente que no tiene contenido en .context/PRD/ ni .context/SRS/. Un proyecto que ya tiene PRD y SRS conserva la cadena completa.
| Fase | En una app existente |
|---|---|
| 1 Constitución, 2 PRD, 3 SRS | No corren. Si el equipo ya tiene documentos de producto reales, los puede entregar; nada se inventa para llenar una fase. |
| 2.5 Diseño | No corre desde aquí. El DESIGN.md sale del tema vivo con /design-system extract, opcional y por su cuenta. |
| 4 · pasos 1 a 3 y 5 | Los modos de /project-context, que leen el código y el bloque stack:. Un mapa ya generado no se regenera: solo se refresca por su propio modo si quedó viejo. |
| 4 · paso 4, guía de desarrollo | Se reconstruye desde el código: estructura de carpetas, convenciones y comandos salen de la app, de su package.json y del bloque stack:, nunca de los defaults del boilerplate. |
| 4 · paso 6, glosario | Se siembra con los mapas, los identificadores del código, los textos de la UI viva, los ADRs existentes y los nombres de épica del tracker. Si el archivo ya existe, se salta. |
Cada fase consume lo que dejó la anterior: por eso van en secuencia. Adentro de una fase, varias piezas son independientes y corren en paralelo.
Varias entradas pueden no existir todavía al inicio. Cuando falta una, la skill lo avisa como entrada faltante en vez de inventar el contenido.
Lo que traigas como semilla: un texto pegado, un link a un documento, la transcripción de un audio.
Si ya hay un PRD, re-invocar una fase lo refina en el lugar; no lo reescribe desde cero.
Personas, modelo de negocio y mercado de una investigación previa. Se muestran; nunca se reemplazan por inventos.
Links, PDFs, notas de analistas. Opcional, pero es lo que más mejora la Constitución.
Identidad del proyecto: nombre, clave, dominio, URLs de cada ambiente. Si falta, se crea o se completa durante esta misma pasada.
Las dos cosas pasan en el hilo principal antes de cualquier fase, incluso la primera vez: así "retomar o empezar" es siempre una decisión explícita.
Busca .session/project-foundation/progress.md. Si existe, lee el plan y las últimas entradas y te muestra el objetivo, la última fase cerrada y la próxima.
Si no existe, redacta plan.md: objetivo, entradas, enfoque, el desglose de fases (1, 2, 2.5, 3 y los pasos de Discovery), riesgos y checklist de verificación.
Con sesión previa: retomar, reiniciar (lo anterior se archiva con sufijo -aborted) o abortar (no se toca nada).
Con plan nuevo: qué entregables de Constitución, PRD, SRS y Discovery se producen. Sin tu aprobación no arranca la fase 1.
.session/project-foundation/plan.md en draft, que pasa a approved cuando lo apruebas.
Cada fase que cierra deja una entrada en progress.md: si la sesión se corta, se retoma desde ahí.
El problema que vale la pena resolver, a quién sirve, cómo gana dinero y en qué competencia vive. Sin esto, el PRD no tiene ancla.
Arma el Business Model Canvas (segmentos, propuesta de valor, canales, ingresos, costos, métricas), un problem statement y las hipótesis que el MVP tiene que validar.
Después, un análisis de mercado liviano: competidores directos, oportunidad y tendencias.
Aportas la evidencia: entrevistas, datos de analítica, pedidos de stakeholders, fuentes de mercado.
Sin investigación, el hueco queda marcado como [PLACEHOLDER] y la IA te pregunta. No completa con datos inventados.
.context/business/business-model.md y .context/business/market-context.md.
Formaliza el problema, nombra a los usuarios, corta el MVP y traza los recorridos de punta a punta. Responde qué y por qué; el cómo es del SRS.
Problema, solución, KPIs de éxito y métricas del MVP. Las demás piezas parten de aquí.
Usuarios objetivo, objetivos, dolores, nivel de adopción tecnológica.
Épicas con historias de alto nivel, lo que entra (must have) y una sección explícita de lo que queda afuera.
Happy path, caminos alternativos y casos borde por persona.
personas, alcance y journeys corren en paralelo una vez redactado el executive summary
Redacta cada pieza desde su referencia y cablea las referencias cruzadas: las personas aparecen en los journeys.
El corte del MVP: qué entra y qué queda para después. Personas, problema y KPIs llevan evidencia citada.
.context/PRD/*.md: un archivo por pieza, o un prd.md consolidado.
Antes de cerrar la arquitectura, la skill le pasa la posta a /design-system, que produce el DESIGN.md en la raíz del proyecto.
Invoca /design-system con la Constitución y el PRD como entrada. El camino por defecto es npx getdesign más un matcher que elige una marca del catálogo; los otros caminos están en esa skill.
Si ya existe un DESIGN.md y no pediste un rebrand, el paso se saltea.
DESIGN.md en la raíz, o donde diga design_md_path en .agents/project.yaml.
Convierte el PRD en requisitos formales, restricciones, arquitectura y contrato de API. Es lo que lee /project-bootstrap para montar el código.
Uno por historia del PRD, con entrada, procesamiento, salida y validaciones.
Performance, seguridad, escalabilidad, accesibilidad, confiabilidad. Métricas medibles, no "debe ser rápido".
Diagrama del sistema, modelo de datos, justificación del stack con sus trade-offs, flujo de datos y seguridad.
La especificación OpenAPI de los endpoints, por dominio.
las cuatro piezas corren en paralelo una vez cerrado el PRD
Con la arquitectura redactada, promueve a ADR cada decisión que pasa el doble filtro: es arquitectónica y difícil de revertir. Modelo de auth, acceso a datos, contrato de errores, tenancy, topología de deploy, frameworks con lock-in.
Lo que ya aprobaste (está en el PRD o SRS que firmaste) se escribe Accepted, citando dónde lo aprobaste. Solo lo que sigue abierto va como Proposed.
.context/SRS/, los registros .context/ADR/ADR-NNNN-*.md y el índice .context/ADR/README.md actualizado.
Esta fase no genera los mapas por su cuenta: los pide a /project-context, modo por modo. Así el mismo generador sirve después, desde cualquier sesión, cuando el esquema o las features cambian.
| Paso | Quién lo hace | Qué necesita antes | Qué deja |
|---|---|---|---|
| 1 · mapa de datos | /project-context data | nada | el mapa dentro de business-data-context |
| 2 · mapa de features | /project-context features | el paso 1 (avisa si falta, no bloquea) | el mapa dentro de business-feature-context |
| 3 · mapa de API | /project-context api | los pasos 1 y 2 informan, no bloquean | el mapa dentro de business-api-context |
| 4 · guía de desarrollo | esta skill | el mapa de datos generado (obligatorio) | .context/business/project-dev-guide.md |
| 5 · plan maestro opcional | /project-context master-plan | el mapa de datos (obligatorio) y el de features (recomendado) | .context/master-implementation-plan.md |
| 6 · glosario del dominio | esta skill, una sola vez | PRD, SRS, mapas y ADRs como semilla | .context/business/domain-glossary.md |
Después de cualquier fase la skill confirma lo mismo. Cuando pasa la checklist del plan al final de Discovery, archiva.
Los antipatrones completos viven en SKILL.md y viajan en el registro compacto que reciben los subagentes (.agents/skills/REGISTRY.md).
Esta skill no tiene modos con nombre: lo que pides elige la fase y la referencia. Nombras la skill y describes lo que necesitas, en español o en inglés.
La barra carga la skill; el resto de la frase elige la fase.
Sin barra: nombras la skill en la frase.
Mismo patrón que OpenCode, CLI o Desktop.
| Si dices algo como… | La IA va a |
|---|---|
| "constitución del proyecto" · "análisis de mercado" | fase 1, referencias constitution-* |
| "user personas" · "MVP scope" · "user journeys" | fase 2, referencias prd-* |
| "design system" · "paleta" · "branding" | traspaso a /design-system |
| "definir SRS" · "tech stack" · "API contracts" | fase 3, referencias srs-* |
| "record an ADR" · "decisión de arquitectura" | adr-doctrine.md y .context/ADR/README.md |
| "business data map" · "CRUD matrix" · "endpoint catalog" | /project-context data, features o api |
| "guía de desarrollo" · "onboarding" | project-dev-guide.md |
| "master implementation plan" · "what to build first" | /project-context master-plan |
la tabla completa está en SKILL.md → "Specific tasks" · si el pedido no coincide con ninguna fila, la IA elige la fase más cercana y te lo avisa
Genera los mapas de negocio y el plan maestro, y se vuelve a invocar solo cuando algo cambia.
Convierte la arquitectura del SRS y los contratos de API en un backend y un frontend que arrancan. Deck: Project bootstrap.
Convierte el alcance del MVP en épicas e historias en Jira. Deck: Product management.
El ciclo por historia (plan, código, review, deploy), solo cuando la base de código ya existe.