/project-bootstrap toma lo que dejó /project-foundation (PRD, SRS) y el DESIGN.md, y levanta la base técnica: backend con base de datos, auth y tipos, frontend con el design system, y las piezas de integración que el proyecto pida. Corre una vez por proyecto; después, cada historia construye encima.
Producto, arquitectura y tokens visuales.
Qué se monta y qué features suma. Lo apruebas tú.
Esquema, RLS, auth, clientes y tipos.
Design system desde DESIGN.md, layout, páginas demo.
OpenAPI, rutas, bearer, URLs, tipos. Solo las que hagan falta.
/project-foundation responde qué se construye. Esta skill responde cómo se para el repo para empezar a construirlo.
Las fases base (backend y frontend) crean: tablas, RLS, seeds, clientes, middleware, layout, tema, la config de Tailwind, páginas y credenciales de demo. Sobre una app viva, cada uno de esos pasos pisaría algo. Por eso el veredicto lo da un script, nunca la IA mirando el árbol: un gate que el agente puede satisfacer escribiendo un valor creíble no es un gate.
# al entrar, antes del plan de la sesión; el veredicto y el exit code van a plan.md bun run bootstrap:guard # exit 0 = greenfield · exit 2 = app existente (con las señales) · --json
La base (backend y después frontend) se monta siempre y en ese orden. Las piezas incrementales son independientes entre sí: se eligen por necesidad y el resto se salta.
Es el orden canónico para una IA que arranca en frío. Cada una alimenta una decisión distinta del scaffolding.
El inventario de features y el alcance del MVP: deciden qué se monta.
Las decisiones de infraestructura: base de datos, hosting, proveedor de auth, runtime. El esquema de la base sale del ERD de la arquitectura.
Paleta, tipografía y tokens. Es la entrada obligatoria del frontend: tiene que existir antes de la fase 2.
Identidad del proyecto, stack del backend y del frontend, motor de base de datos y las URLs de cada ambiente.
Si hay scaffolding previo, se detecta y se parchea en el lugar. Nunca se pisa lo que alguien ya editó.
Las dos corren en el hilo principal, sin subagentes, incluso la primera vez: así "retomar o empezar" es siempre una decisión explícita.
Busca .session/project-bootstrap/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, fases, riesgos y checklist de verificación.
Con sesión previa: retomar, reiniciar (lo anterior se archiva) o abortar (no se toca nada).
Con plan nuevo: qué piezas incrementales se suman sobre la base. Sin tu aprobación, no arranca la fase 1.
.session/project-bootstrap/plan.md en estado draft, que pasa a approved cuando lo apruebas.
Cada fase que termina deja una entrada en progress.md: si la sesión se corta, se retoma desde ahí.
Levanta la base de datos, la auth y la capa de acceso, y fija las convenciones que va a seguir cada endpoint futuro. Se hace una sola vez, antes de los sprints.
Verifica el estado de git y las herramientas. Sin el MCP de Supabase se detiene todo: crea tablas y políticas con él, no con scripts SQL a mano.
Crea las tablas fundacionales (no el ERD entero), índices, RLS por tabla y datos semilla realistas. Arma los clientes de Supabase, el middleware de sesión y la configuración centralizada. Consulta la documentación oficial antes de instalar cada dependencia.
El proyecto de Supabase: uno existente (das su ID) o uno nuevo.
Cómo se manejan los archivos de entorno: la IA no crea un .env sin consultarte. Los commits los haces tú.
Tablas con RLS en la base, clientes en src/lib/supabase/, configuración en src/lib/config.ts, tipos generados en src/types/supabase.ts.
Documentación en .context/backend-setup.md y .context/api-auth.md.
Monta el proyecto, el design system, el layout y unas pocas páginas demo que prueban que todo encaja. No implementa features: eso queda para cada historia.
Antes de nada, confirma que el backend existe: lee src/types/supabase.ts y los clientes de Supabase, y se detiene si faltan. Con ellos arma helpers de tipos para los componentes.
Mapea los tokens de DESIGN.md a la configuración de Tailwind y a variables CSS sin preguntarte colores: el archivo ya es la fuente. Monta el proyecto en el directorio actual, sin generadores que crean subcarpetas.
El package manager.
La estrategia de componentes: shadcn/ui, componentes desde cero o Headless UI con estilos propios. Esa pregunta sigue en pie aunque haya DESIGN.md.
Qué páginas demo se construyen (dos o tres, las más representativas del dominio).
Componentes en src/components/ui/, layout en src/components/layout/, páginas demo, estilos globales.
.context/design-system.md documenta paleta, componentes y uso.
Cada pieza suma una capacidad sobre la base. Son independientes entre sí y cada una corre en su propio subagente. Antes de escribir, cada una mira qué hay en el repo y decide su alcance: completo si ya hay endpoints o estructura previa, parcial si el terreno está vacío.
| Pieza | Qué agrega | Dónde queda | Requiere |
|---|---|---|---|
| OpenAPI | Spec generada desde schemas Zod en /api/openapi y la UI de Scalar en /api/docs. El schema se define una vez, junto al tipo: la documentación no se duplica. | src/lib/openapi/ | backend base |
| Rutas de API | Carpetas por dominio, validación con Zod, errores estandarizados y un endpoint de ejemplo; con OpenAPI presente, los endpoints del SRS quedan registrados en la spec. | src/app/api/ | backend base |
| Bearer token | Auth por header Authorization para Postman, curl o apps externas, sin romper la auth por cookies del navegador. | src/lib/supabase/server.ts y las rutas protegidas | backend base |
| URLs por ambiente | Un helper que detecta el ambiente (development, staging, production) y arma la URL base correcta. Te pregunta las URLs de staging y producción. | src/lib/urls.ts | backend base |
| Tipos de Supabase | El pipeline esquema → TypeScript, un script de regeneración en package.json y los clientes tipados con Database. | src/types/supabase.ts | frontend base |
Cada fase cierra con el verificador liviano de etapa y la sesión termina con el pie de herramientas usadas. Un chequeo que falla se reporta tal cual: nada de arreglos inventados para un stack desconocido, la IA te pregunta.
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 referencia. Nombras la skill y describes la pieza, en español o en inglés.
La barra carga la skill; el resto de la frase elige la fase o la pieza.
Sin barra: nombras la skill en la frase.
Mismo patrón que OpenCode, CLI o Desktop.
| Si dices algo como… | La IA lee |
|---|---|
| "setup del backend" · "scaffold the server" | backend-setup.md |
| "inicializar el frontend" · "design system + project skeleton" | frontend-setup.md |
| "configurar OpenAPI" · "API docs UI" | openapi-setup.md |
| "API routes setup" · "middleware" | api-routes-setup.md |
| "bearer token authentication" · "protect routes" | bearer-token-support.md |
| "env vars setup" · "URL builder" | env-url-setup.md |
| "supabase types generation" | supabase-types-setup.md |
las referencias viven en .agents/skills/project-bootstrap/references/ · si el pedido no coincide con ninguna fila, la IA cae en backend o frontend según el lado del stack, y te lo avisa
Deja el PRD y el SRS con las decisiones de arquitectura de las que sale el stack.
Produce el DESIGN.md que el frontend necesita. El flujo de pantallas por historia está en el deck Del plano al producto.
Convierte el PRD en épicas e historias en Jira. Deck: Product management.
Lleva cada historia de plan a código, review y deploy, sobre esta base.
Un tema aparte; puede correr en cualquier momento después de la base.
Con la infraestructura arriba, genera la página /qa y un artefacto de credenciales para probar la app por base de datos, API y UI.