Frontend Project Bootstrap
Convierte el prototipo UI/UX entregado en un "proyecto frontend estándar del equipo + documentación completa + lista de tareas listas para comenzar", de modo que el código escrito por diferentes personas y diferentes agentes de codificación parezca escrito por la misma persona.
Versión: Ver el primer registro en CHANGELOG.md.
Principios fundamentales
- El prototipo es material de requisitos, no código para copiar al proyecto. Extrae de él pantallas, datos, paletas de colores e interacciones; no copies su implementación. Los archivos originales y las capturas de pantalla se guardan en el repositorio como criterio de aceptación.
- Las normas del equipo se copian tal cual; el contenido del proyecto se completa según el prototipo. Se tratan de forma diferente dos tipos de archivos (ver "Índice de archivos" más abajo).
- Si no estás seguro, pregunta, no adivines. Las preguntas se hacen en rondas en los puntos de pausa, cada una con una respuesta sugerida; un "sí" significa que se acepta la sugerencia.
- No implementes funcionalidades de negocio. Este skill solo crea el esqueleto, páginas en blanco y documentación; las funcionalidades de negocio se desarrollarán más tarde mediante
/implementsiguiendo las tareas. - La validación es obligatoria para considerar finalizado. lint, typecheck, test y build deben pasar sin errores; no deben quedar placeholders; cada pantalla debe tener su captura.
Entrada necesaria
- Prototipo (HTML único, HTML de varias páginas, enlace al archivo de diseño o captura de pantalla) con su versión / fecha de entrega
- Nombre del proyecto y una descripción de una frase
- Ubicación de la carpeta del nuevo proyecto (debe estar vacía o ser un repositorio nuevo; si ya tiene contenido, detente y confirma)
El resto de la información (entorno de despliegue, estado del backend, idioma, modo oscuro) se pregunta en el paso 1; los detalles están en references/workflow-detail.md.
Preparación previa (una vez por máquina)
cd <skill> && npm ci && npx playwright install chromium # Playwright y Prettier para scripts/; no se incluyen en el esqueleto
# Si ya tienes Chromium en la máquina, no es necesario descargarlo; usa CHROMIUM_EXECUTABLE=<ruta> al ejecutar el script de capturas
Flujo
Crea una lista de tareas para seguir los siguientes cinco pasos; marca cada paso como completado al finalizar.
Paso 1: Recepción
Primero, confirma que la carpeta del proyecto no existe o está vacía (si tiene contenido, detente y pregunta). Luego, confirma el archivo del prototipo, su versión y la ubicación compartida del equipo.
Pregunta los elementos de la tabla del paso 1 en references/workflow-detail.md que aún no se hayan proporcionado en el mensaje.
Paso 2: Análisis del prototipo y capturas de pantalla
Lee references/prototype-analysis.md, analiza según su método y genera docs/_bootstrap/prototype-analysis.md
(formato: templates/prototype-analysis.md). Si el prototipo es HTML, coloca el archivo original en docs/prototype/,
completa docs/prototype/screens.json (formato: templates/prototype-screens.json) y ejecuta el script de capturas para generar un PNG de cada pantalla.
⏸ Punto de pausa: Según "Punto de pausa" en references/prototype-analysis.md, haz preguntas en rondas: problemas pendientes de confirmar, comportamiento predeterminado para estados faltantes,
modo de enrutamiento (history / hash), estado del backend. Una vez recibidas las respuestas, regístralas en las secciones 11 y 12 del archivo de análisis y continúa.
Paso 3: Creación del esqueleto
Copia assets/skeleton/ (excluyendo node_modules), ejecuta npm ci, luego, según el paso 3 de references/workflow-detail.md,
modifica el nombre, la paleta de colores, el modo de enrutamiento, las rutas y el menú, las páginas en blanco y los códigos de permisos. Mantén la funcionalidad de ejemplo Item hasta que se complete la primera funcionalidad real.
Paso 4: Generación de documentos
Según la tabla de correspondencias del paso 4 de references/workflow-detail.md, copia y completa. Todos los <!-- FILL: --> deben completarse según sus instrucciones y eliminar el comentario;
todos los {{PLACEHOLDER}} deben reemplazarse. Si no se sabe, escribe "Pendiente de confirmar", no inventes.
Paso 5: Validación, commit y reporte
npm run lint && npm run typecheck && npm test && npm run build
node <skill>/scripts/check-placeholders.mjs <project>
Las cuatro comprobaciones deben pasar sin errores (lint sin warnings), el script de verificación debe devolver 0 ERRORES para considerar finalizado; luego realiza el primer commit.
El formato del reporte está en el paso 5 de references/workflow-detail.md.
Cuando el usuario no esté presente: para las preguntas con respuesta sugerida, adopta la sugerencia y márcala como "Adoptada (provisional)"; para las que no tengan sugerencia, escribe "Pendiente de confirmar" y continúa con normalidad; ambos casos deben listarse en el reporte. La única situación para detenerse es cuando la carpeta del proyecto ya tiene contenido.
Índice de archivos
Copiar tal cual (solo se puede cambiar el nombre, no modificar el contenido)
| Ruta | Copiar a | Contenido |
|---|---|---|
assets/skeleton/ | Raíz del proyecto | Esqueleto ejecutable: configuraciones, capa de API, hooks de datos, DataBoundary, permisos, i18n, theme, MSW, pruebas, CI (Azure DevOps), plantilla de PR, funcionalidad de ejemplo Item |
references/standards/ | docs/conventions/ | 18 normas de desarrollo del equipo + índice |
references/adr-baseline/ | docs/adr/ | ADR 0001–0016 + índice |
templates/agents/ | docs/agents/ | Configuración de tracker y domain docs para skills de mattpocock (local markdown, single-context) |
Completar según el prototipo
| Plantilla | Salida |
|---|---|
templates/prototype-analysis.md | docs/_bootstrap/prototype-analysis.md |
templates/prototype-screens.json | docs/prototype/screens.json (entrada para el script de capturas) |
templates/README.md, AGENTS.md, ARCHITECTURE.md, GLOSSARY.md | Raíz del proyecto |
templates/CLAUDE.md | Raíz del proyecto (archivo de enlace para Claude Code: comentario de una línea más @AGENTS.md, copia literal) |
templates/prototype-README.md | docs/prototype/README.md |
templates/adr-router-mode.md | docs/adr/0017-router-mode.md |
templates/api-interface-auth.md, api-interface.md, api-checklist.md | docs/api/ |
templates/feature-spec.md | docs/specs/<feature>.md |
templates/task.md, tasks-README.md, task-remove-example.md | docs/tasks/ |
templates/adr.md, bug-report.md, etc. | Guardar una copia en docs/templates/ para uso futuro |
Documentación y herramientas
| Ruta | Cuándo leer |
|---|---|
references/workflow-detail.md | Cada paso: acciones, comandos y tabla de archivos |
references/prototype-analysis.md | Paso 2 |
scripts/screenshot-prototype.mjs | Paso 2 (también al actualizar el prototipo) |
scripts/check-placeholders.mjs | Paso 5 |
Integración con skills de mattpocock
La salida de este skill es la entrada para mattpocock/skills; no es necesario ejecutar /setup-matt-pocock-skills en el proyecto
(si se ejecuta, solo actualizará ## Agent skills en AGENTS.md y docs/agents/; no permitas que escriba en CLAUDE.md).
| Su skill | Correspondencia aquí |
|---|---|
/grill-with-docs, grilling | El punto de pausa del paso 2 es el mismo tipo de entrevista; para cambios de diseño futuros, úsalo directamente; los términos van en GLOSSARY.md, las decisiones en docs/adr/0018+ |
domain-modeling | Lee y escribe GLOSSARY.md (mismo formato) y docs/adr/ (formato del equipo, ver docs/agents/domain.md) |
/to-spec, /to-tickets | No usar. Las especificaciones ya están en docs/specs/ (numeradas con Gherkin), las tareas ya están en docs/tasks/ (con rutas de archivo por capa y componentes reutilizables) |
/implement | Modo de implementación de la primera versión: una tarea por vez desde docs/tasks/<ID>-*.md, desde main en una rama creada con la tarea; llama a tdd y code-review |
tdd | Los seams ya están definidos en "Testing seams" en AGENTS.md, no es necesario discutirlos |
/implement-spec | Se puede usar pero no se ha probado: cada worktree necesita npm ci (husky prepare), Azure DevOps no tiene integración de PR borrador |
Compatibilidad con herramientas de agente
AGENTS.md es la única fuente de reglas. opencode y Kimi Code CLI leen directamente AGENTS.md en la raíz del proyecto;
Claude Code lee CLAUDE.md, por lo que el esqueleto incluye un archivo de enlace que solo contiene @AGENTS.md. No escribas reglas adicionales en el archivo de enlace.
Actualizar este skill
Para cambiar las normas del equipo, modifica este skill (standards, adr-baseline, skeleton juntos), regístralo en CHANGELOG.md y aumenta la versión;
no modifiques solo en proyectos individuales. Las desviaciones de un proyecto individual se escriben como ADR de ese proyecto (a partir de 0017).
Después de modificar el skeleton, ejecuta lint, typecheck, test y build en assets/skeleton/; después de modificar Markdown, ejecuta npm run format.