--- name: quickstart-163f30e3a60d description: > Interactive tutorial — guides new developers through the full SpecBox Engine pipeline with a demo project. Use when the user says "quickstart", "tutorial", "getting started", "learn engine", or needs onboarding to the engine. context: direct triggers: - quickstart - tutorial - getting started - learn engine - onboarding --- # /quickstart — Tutorial Guiado Interactivo Tutorial interactivo que guia a nuevos desarrolladores a traves del pipeline completo del SpecBox Engine con un micro-proyecto de ejemplo. ## Uso ``` /quickstart ``` --- ## Paso 0: Preparacion del entorno demo ### 0.1 Crear directorio demo Crea el directorio `~/quickstart-demo/` con una estructura minima de proyecto Flutter (sin necesidad de Flutter SDK real): ``` ~/quickstart-demo/ pubspec.yaml # Minimal — solo nombre y descripcion lib/ main.dart # Placeholder .quality/ baselines/ evidence/ logs/ scripts/ CLAUDE.md # Generado por el Engine .claude/ settings.json # Config basica ``` **pubspec.yaml** contenido: ```yaml name: quickstart_demo description: Proyecto demo para aprender SpecBox Engine version: 1.0.0 environment: sdk: ">=3.0.0 <4.0.0" ``` **lib/main.dart** contenido: ```dart // Placeholder — este archivo seria tu app Flutter real void main() { print('Quickstart Demo - SpecBox Engine'); } ``` ### 0.2 Mensaje de bienvenida Mostrar: ``` === SpecBox Engine — Tutorial Quickstart === Bienvenido al tutorial interactivo del SpecBox Engine. En los proximos minutos vas a recorrer el pipeline completo que este sistema usa para desarrollar software de forma agentica. Proyecto demo creado en: ~/quickstart-demo/ Vamos a pasar por 4 etapas: 1. /prd — Definir requisitos (PRD + User Stories) 2. Review — Revisar lo generado 3. /plan — Planificar la implementacion 4. /implement — Ver como se ejecutaria (modo dry-run) Cada etapa incluye una explicacion de que esta pasando y por que. ``` --- ## Paso 1: Etapa PRD (simulada) ### 1.1 Bloque explicativo Mostrar al usuario: ``` --- Etapa 1/4: /prd (Product Requirements Document) --- Que es: El PRD es el documento que define QUE hay que construir. El Engine descompone cada feature en una jerarquia: US (User Story) → UC (Use Case) → AC (Acceptance Criteria) Cada AC pasa por el "Definition Quality Gate" que rechaza criterios vagos. Esto garantiza que todo es testable y medible. Para este demo, vamos a definir una feature sencilla: "Como usuario, quiero ver una lista de tareas pendientes." ``` ### 1.2 Generar PRD demo Crear el archivo `~/quickstart-demo/doc/prd/demo-prd.md` con contenido: ```markdown # PRD: Lista de Tareas ## Feature Como usuario, quiero ver una lista de tareas pendientes para organizar mi dia. ## User Stories ### US-01: Visualizacion de tareas Como usuario quiero ver mis tareas en una lista scrollable. #### UC-001: Pantalla principal con lista - AC-01: La pantalla muestra un ListView con todas las tareas almacenadas - AC-02: Cada item muestra titulo, fecha y estado (pendiente/completada) - AC-03: Si no hay tareas, muestra mensaje "No hay tareas pendientes" #### UC-002: Filtro por estado - AC-04: Existe un toggle para filtrar entre "todas", "pendientes" y "completadas" - AC-05: El filtro se aplica instantaneamente sin recarga ``` ### 1.3 Explicar resultado ``` El PRD define 1 User Story con 2 Use Cases y 5 Acceptance Criteria. En un proyecto real, /prd tambien: - Crea work items en Trello o Plane - Genera un PDF de evidencia - Valida que cada AC sea especifico y testable (Definition Quality Gate) ``` --- ## Paso 2: Etapa Review ### 2.1 Bloque explicativo ``` --- Etapa 2/4: Review --- Antes de planificar, siempre se revisa el PRD generado. Esto es un checkpoint humano — el Engine no avanza sin tu OK. En este momento revisarias: - Que las User Stories cubren el scope deseado - Que los Use Cases son atomicos (1 UC = 1 feature testable) - Que los Acceptance Criteria son medibles y no ambiguos El PRD demo esta en: ~/quickstart-demo/doc/prd/demo-prd.md ``` ### 2.2 Mostrar el PRD Leer y mostrar el contenido del PRD generado en el paso anterior. ``` Todo correcto — el PRD es sencillo y claro. Avanzamos a la planificacion. ``` --- ## Paso 3: Etapa Plan (simulada) ### 3.1 Bloque explicativo ``` --- Etapa 3/4: /plan (Plan Tecnico) --- Que es: El plan tecnico define COMO implementar cada UC. Incluye fases de desarrollo, dependencias, y (si hay UI) genera disenos visuales con Google Stitch. Cada fase del plan se ejecuta despues por /implement de forma autonoma — por eso el plan debe ser preciso y completo. ``` ### 3.2 Generar plan demo Crear el archivo `~/quickstart-demo/doc/plans/UC-001_plan.md` con contenido: ```markdown # Plan Tecnico: UC-001 — Pantalla principal con lista ## Stack: Flutter ## Patron: feature-first ## Fases ### Fase 1: Modelo de datos - Crear `lib/features/tasks/domain/task.dart` con clase Task (id, title, date, completed) - Crear `lib/features/tasks/data/task_repository.dart` con datos mock ### Fase 2: UI — ListView - Crear `lib/features/tasks/presentation/pages/task_list_page.dart` - Implementar ListView.builder con TaskTile widget - Implementar estado vacio ("No hay tareas pendientes") ### Fase 3: Tests - Unit test para Task model - Widget test para TaskListPage (con datos y sin datos) ## Acceptance Criteria Mapping - AC-01 → Fase 2 (ListView.builder) - AC-02 → Fase 1 (Task model) + Fase 2 (TaskTile) - AC-03 → Fase 2 (estado vacio) ``` ### 3.3 Explicar resultado ``` El plan mapea cada AC a fases concretas de implementacion. En un proyecto real, /plan tambien: - Genera disenos UI con Google Stitch (si el proyecto tiene pantallas) - Crea artefactos VEG (Visual Experience Generation) por audiencia - Sube el plan como evidencia al gestor de proyecto (Trello/Plane) ``` --- ## Paso 4: Etapa Implement (dry-run) ### 4.1 Bloque explicativo ``` --- Etapa 4/4: /implement (Dry-Run) --- Que es: /implement lee el plan y ejecuta cada fase de forma autonoma. Un Orchestrator (AG-01) coordina agentes especializados: - AG-01: Feature Generator (implementa codigo) - AG-02: UI/UX Designer (design-to-code desde Stitch) - AG-04: QA Validation (tests + lint) - AG-08: Quality Auditor (GO/NO-GO final) - AG-09: Acceptance Tester + Validator En modo dry-run mostramos lo que HARIA cada fase sin ejecutar codigo real. ``` ### 4.2 Simular ejecucion Mostrar la siguiente simulacion (NO ejecutar nada real): ``` [DRY-RUN] Implement UC-001: Pantalla principal con lista [Fase 1/3] Modelo de datos > Crearia: lib/features/tasks/domain/task.dart > Crearia: lib/features/tasks/data/task_repository.dart > Checkpoint guardado: .quality/evidence/UC-001/checkpoint.json (phase: 1) [Fase 2/3] UI — ListView > Crearia: lib/features/tasks/presentation/pages/task_list_page.dart > Crearia: lib/features/tasks/presentation/widgets/task_tile.dart > Checkpoint guardado (phase: 2) [Fase 3/3] Tests > Crearia: test/features/tasks/domain/task_test.dart > Crearia: test/features/tasks/presentation/task_list_page_test.dart > Checkpoint guardado (phase: 3) [Quality Gate] AG-08 Quality Auditor > Verificaria: lint errors = 0, coverage >= baseline, no test regressions > Veredicto simulado: GO [Acceptance] AG-09a Acceptance Tester > Generaria tests E2E desde AC-01, AC-02, AC-03 > Ejecutaria tests con evidencia (screenshots) [Acceptance] AG-09b Acceptance Validator > Verificaria cada AC implementado + testeado + evidenciado > Veredicto simulado: ACCEPTED [PR] Crearia pull request: feat/UC-001-task-list-page > Branch: feat/UC-001-task-list-page > Target: main > Titulo: feat(tasks): implement task list page with empty state ``` --- ## Paso 5: Resumen final ### 5.1 Mostrar resumen ``` === Tutorial Completado === Conceptos aprendidos: 1. PRD: Define QUE construir (US → UC → AC) 2. Definition Quality Gate: Rechaza AC vagos antes de implementar 3. Plan Tecnico: Define COMO implementar cada UC en fases 4. Implement Autopilot: Ejecuta fases con agentes especializados 5. Quality Gates: Lint, coverage y tests con politica ratchet 6. Acceptance Engine: Tests E2E + validacion independiente por AC 7. Self-Healing: Si algo falla, el Engine intenta reparar automaticamente 8. Merge Secuencial: Solo merge si AG-08=GO + AG-09=ACCEPTED Para profundizar: - docs/getting-started.md — Guia completa de inicio - docs/commands.md — Referencia de todos los commands - docs/agent-teams.md — Como funcionan los agentes - docs/architecture.md — Patrones por stack Proyecto demo en: ~/quickstart-demo/ Puedes explorar los archivos generados para ver la estructura. Para onboardear tu proyecto real, ejecuta: /quickstart no es necesario de nuevo — usa directamente: → onboard_project (o el wizard interactivo del MCP) → /prd para definir tu primera feature ``` ### 5.2 Limpiar (opcional) NO borrar el directorio demo. El usuario puede querer explorarlo. --- ## Reglas - No requiere Flutter SDK instalado — todo es simulado/placeholder - No ejecutar comandos reales de build, test o lint - Cada bloque explicativo debe tener entre 3 y 5 lineas - El /implement es siempre dry-run — mostrar lo que haria, no hacerlo - Total de interaccion activa: < 5 minutos - Idioma: espanol --- Source attribution: EmbedBuild Original project: https://github.com/EmbedBuild/specbox-engine/blob/0d7a27c30d728b068215b9486667272160ed0d4e/.claude/skills/quickstart/SKILL.md License: Apache-2.0 License information: https://www.apache.org/licenses/LICENSE-2.0 Original upstream instructions; downloaded from Mega AI Hub. ## Upstream license notice Business Source License 1.1 Parameters Licensor: Jesus Perez Sanchez (Embed Build) Licensed Work: SpecBox Engine v5.11.0 Copyright (c) 2026 Jesus Perez Sanchez Additional Use Grant: You may use the Licensed Work for non-production purposes, including personal evaluation, academic research, educational use, and contributing modifications back to the Licensed Work. Production use is permitted only in projects developed jointly with Embed Build under a separate written agreement. Change Date: 2030-03-26 Change License: Apache License, Version 2.0 License text copyright (c) 2017 MariaDB Corporation Ab, All Rights Reserved. "Business Source License" is a trademark of MariaDB Corporation Ab. ----------------------------------------------------------------------------- Terms The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work. The Licensor may make an Additional Use Grant, above, permitting limited production use. Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate. If your use of the Licensed Work does not comply with the requirements currently in effect as described in this License, you must purchase a commercial license from the Licensor, its affiliated entities, or authorized resellers, or you must refrain from using the Licensed Work. All copies of the original and modified Licensed Work, and derivative works of the Licensed Work, are subject to this License. This License applies separately for each version of the Licensed Work and the Change Date may vary for each version of the Licensed Work released by Licensor. You must conspicuously display this License on each original or modified copy of the Licensed Work. If you receive the Licensed Work in original or modified form from a third party, the terms and conditions set forth in this License apply to your use of that work. Any use of the Licensed Work in violation of this License will automatically terminate your rights under this License for the current and all other versions of the Licensed Work. This License does not grant you any right in any trademark or logo of Licensor or its affiliates (provided that you may use a trademark or logo of Licensor as expressly required by this License). TO THE EXTENT PERMITTED BY APPLICABLE LAW, THE LICENSED WORK IS PROVIDED ON AN "AS IS" BASIS. LICENSOR HEREBY DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS OR IMPLIED, INCLUDING (WITHOUT LIMITATION) WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, AND TITLE. MariaDB hereby grants you permission to use this License's text to license your works, and to refer to it using the trademark "Business Source License", as long as you comply with the Covenants of Licensor below. Covenants of Licensor In consideration of the right to use this License's text and the "Business Source License" name and trademark, Licensor covenants to MariaDB, and to all other recipients of the licensed work to be provided by Licensor: 1. To specify as the Change License the GPL Version 2.0 or any later version, or a license that is compatible with GPL Version 2.0 or a later version, where "compatible" means that software provided under the Change License can be included in a program with software provided under GPL Version 2.0 or a later version. Licensor may specify additional Change Licenses without limitation. 2. To either: (a) specify an additional grant of rights to use that does not impose any additional restriction on the right granted in this License, as the Additional Use Grant; or (b) insert the text "None". 3. To specify a Change Date. 4. Not to modify this License in any other way. # Mega AI Hub resource metadata Creator / publisher: EmbedBuild Original project: https://github.com/EmbedBuild/specbox-engine/blob/0d7a27c30d728b068215b9486667272160ed0d4e/.claude/skills/quickstart/SKILL.md Attribution basis: Source repository record Fields of work: Development & Engineering, Product Management Roles: Backend Developer, Frontend Developer, Growth Product Manager, Product Manager, Technical Product Manager Specialties: Backend, Mobile Tools: Specbox Engine Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: d92ecd7f47566c501bb4e13e9c38efae7cc138a178a1c9bae95e470bf1b89409