flyee 0.1.0

package/core/workflows/page-build.md

@@ -0,0 +1,296 @@
+---
+description: Build **new pages** or **extend existing pages** using the **validated Design System**.  This workflow governs **composition only**. It **does NOT** create visual identity, tokens, or component primitives.
+---
+
+## HARD PRECONDITIONS (NON-NEGOTIABLE)
+
+Execution MUST be **BLOCKED** unless **ALL** conditions below are met:
+
+```text
+design_system.validated === true
+design_system.tokens === "ready"
+design_system.components !== "missing"
+```
+
+❌ If any condition fails → **ABORT execution**
+✅ Output blocking reason + required corrective command
+
+---
+
+## INPUT (MANDATORY)
+
+```text
+/page-build
+mode: create | extend
+page: /app/[route]/page.tsx
+reference: screenshot | figma | image
+goal: short description of what is being built
+```
+
+### Optional
+
+```text
+constraints:
+- must preserve layout
+- desktop-first
+- mobile-priority
+```
+
+---
+
+## REQUIRED INPUT VALIDATION
+
+Before execution, confirm:
+
+- Layout reference provided (image / figma)
+- Copy status:
+  - provided | generate placeholder
+- Data source:
+  - static | mock | external (schema only)
+
+If any item is missing:
+→ Ask explicitly before proceeding
+→ Do NOT infer product decisions
+
+---
+
+## MODE DEFINITIONS (ABSOLUTE)
+
+### `mode: create`
+
+Used to **create a new page or route**.
+
+### `mode: extend`
+
+Used to **add a section or feature** to an **existing page**.
+
+Mode **MUST** be explicitly declared.
+Implicit mode detection is **forbidden**.
+
+---
+
+## WORKFLOW STEPS
+
+---
+
+## 1️⃣ Visual Analysis (MANDATORY)
+
+Analyze the reference and extract:
+
+### Layout Structure
+
+* Grid type (1, 2, 3 columns)
+* Presence of sidebar, header, footer
+* Container widths and spacing rhythm
+
+### Section Breakdown
+
+* Identify logical UI sections
+* Name each section by purpose
+* Define section boundaries clearly
+
+### Content Hierarchy
+
+* Primary headings
+* Supporting content
+* CTAs and key actions
+
+❌ If no reference is provided → **BLOCK execution**
+
+---
+
+## 2️⃣ Component Mapping (Design System First)
+
+Map every visual element to **existing Design System components**.
+
+```text
+PRIORITY ORDER:
+1. Custom project components
+2. shadcn/ui components
+3. Composition of primitives
+```
+
+❌ Creating new components here is forbidden
+→ Must use `/ds-components`
+
+Use shadcn MCP for verification when needed.
+
+---
+
+## 3️⃣ MODE-SPECIFIC EXECUTION
+
+---
+
+### 🔹 MODE: CREATE (New Page)
+
+#### Allowed
+
+* Create `/app/[route]/page.tsx`
+* Compose full page layout
+* Use validated components only
+* Request missing components via `/ds-components`
+
+#### Forbidden
+
+* Introducing new visual patterns
+* Defining tokens or styles
+* Altering global layout systems
+
+---
+
+### 🔹 MODE: EXTEND (Section / Feature)
+
+#### Additional HARD RULES
+
+```text
+- MUST preserve existing page layout contract
+- MUST NOT refactor unrelated sections
+- MUST scope changes to ONE section boundary
+- MUST NOT alter grid or global spacing
+```
+
+#### Required Pattern
+
+* New section MUST be extracted into its own component:
+
+```text
+components/sections/[SectionName].tsx
+```
+
+* Page file only composes the new section
+
+❌ If more than one top-level section is modified
+→ **BLOCK execution**
+→ Require new `/page-build` with `mode=create`
+
+---
+
+## 4️⃣ Page Composition
+
+### Page File Rules
+
+* No inline styles
+* No hardcoded values
+* Use Tailwind + CSS variables only
+
+```tsx
+<div className="bg-background text-foreground">
+```
+
+* Layout logic stays shallow
+* Complex logic moves to section components
+
+---
+
+## 5️⃣ Responsive Behavior (MANDATORY)
+
+Define behavior explicitly:
+
+* Mobile (<768px)
+* Tablet (768–1024px)
+* Desktop (>1024px)
+
+Must use Tailwind breakpoints.
+Ad-hoc media queries are forbidden.
+
+---
+
+## 6️⃣ Interactivity & State
+
+Allowed:
+
+* Local state
+* Component state
+* Loading / empty / error states
+
+Forbidden:
+
+* New visual variants
+* New design primitives
+
+---
+
+## 7️⃣ Metadata & Routing
+
+```tsx
+export const metadata = {
+  title: "...",
+  description: "..."
+}
+```
+
+Routing must follow App Router conventions.
+
+---
+
+## 8️⃣ Compliance Check (HARD GATE)
+
+Before completion, validate:
+
+```text
+✓ Uses Design System components only
+✓ No hardcoded colors or spacing
+✓ No token creation or mutation
+✓ Layout rules respected
+✓ Mode-specific rules respected
+```
+
+❌ Any failure → **BLOCK completion**
+
+---
+
+## OUTPUT (MANDATORY)
+
+```text
+Page Build: SUCCESS
+Mode: create | extend
+Page: /app/...
+Sections Created/Modified: [list]
+Design System Compliance: PASS
+Next Allowed Action: Feature logic or navigation wiring
+```
+
+---
+
+## POST-CONDITIONS
+
+### On SUCCESS
+
+* Page or section is approved
+* Design System remains immutable
+* Feature development may proceed
+
+### On FAILURE
+
+* No UI is considered valid
+* No downstream workflow may proceed
+
+---
+
+## GOVERNANCE RULES (ABSOLUTE LAW)
+
+* `/page-build` is the ONLY authorized workflow for page UI
+* Components MUST come from `/ds-components`
+* Tokens MUST already be validated
+* No silent refactors
+* No design drift
+
+---
+
+## RELATED WORKFLOWS
+
+* `/next-step`
+* `/ds-components`
+* `/ds-validate`
+* `/ds-styleguide`
+
+---
+
+## FINAL PRINCIPLE
+
+> **Design System defines identity.
+> Components define capability.
+> Page Build defines composition.
+> Features never define style.**
+
+---

package/core/workflows/plan.md

@@ -0,0 +1,89 @@
+---
+description: Create project plan using project-planner agent. No code writing - only plan file generation.
+---
+
+# /plan - Project Planning Mode
+
+$ARGUMENTS
+
+---
+
+## 🔴 CRITICAL RULES
+
+1. **NO CODE WRITING** - This command creates plan file only
+2. **Use project-planner agent** - NOT Antigravity Agent's native Plan mode
+3. **Socratic Gate** - Ask clarifying questions before planning
+4. **Dynamic Naming** - Plan file named based on task
+
+---
+
+## Task
+
+Use the `project-planner` agent with this context:
+
+```
+CONTEXT:
+- User Request: $ARGUMENTS
+- Mode: PLANNING ONLY (no code)
+- Output: docs/PLAN-{task-slug}.md (dynamic naming)
+
+NAMING RULES:
+1. Extract 2-3 key words from request
+2. Lowercase, hyphen-separated
+3. Max 30 characters
+4. Example: "e-commerce cart" → PLAN-ecommerce-cart.md
+
+RULES:
+1. Follow project-planner.md Phase -1 (Context Check)
+2. Follow project-planner.md Phase 0 (Socratic Gate)
+3. Create PLAN-{slug}.md with task breakdown
+4. DO NOT write any code files
+5. REPORT the exact file name created
+```
+
+---
+
+## Expected Output
+
+| Deliverable | Location |
+|-------------|----------|
+| Project Plan | `docs/PLAN-{task-slug}.md` |
+| Task Breakdown | Inside plan file |
+| Agent Assignments | Inside plan file |
+| Verification Checklist | Phase X in plan file |
+
+---
+
+## After Planning
+
+Tell user:
+```
+[OK] Plan created: docs/PLAN-{slug}.md
+
+Next steps:
+- Review the plan
+- Run `/create` to start implementation
+- Or modify plan manually
+```
+
+---
+
+## Naming Examples
+
+| Request | Plan File |
+|---------|-----------|
+| `/plan e-commerce site with cart` | `docs/PLAN-ecommerce-cart.md` |
+| `/plan mobile app for fitness` | `docs/PLAN-fitness-app.md` |
+| `/plan add dark mode feature` | `docs/PLAN-dark-mode.md` |
+| `/plan fix authentication bug` | `docs/PLAN-auth-fix.md` |
+| `/plan SaaS dashboard` | `docs/PLAN-saas-dashboard.md` |
+
+---
+
+## Usage
+
+```
+/plan e-commerce site with cart
+/plan mobile app for fitness tracking
+/plan SaaS dashboard with analytics
+```

package/core/workflows/prd.md

@@ -0,0 +1,255 @@
+---
+description: Create Product Requirements Document (PRD). Captures problem, personas, requirements, MVP scope, and roadmap in structured format.
+skills: document-registry
+---
+
+# /prd - Product Requirements Document Workflow
+
+$ARGUMENTS
+
+---
+
+## 🎯 PROPÓSITO
+
+Workflow para criação de **PRD (Product Requirements Document)** - documento de requisitos de produto que:
+1. Define o problema e contexto de negócio
+2. Identifica personas e stakeholders
+3. Captura requisitos funcionais e não-funcionais
+4. Estabelece escopo do MVP
+5. Cria roadmap de features
+
+```
+┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
+│   DISCOVERY  │───▶│   DOCUMENT   │───▶│   VALIDATE   │───▶│   APPROVE    │
+│  (Socratic)  │    │    (PRD)     │    │  (Checklist) │    │   (Human)    │
+└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘
+```
+
+---
+
+## 🧩 SUBCOMMANDS
+
+| Comando | Ação |
+|---------|------|
+| `/prd new [nome]` | Cria novo PRD a partir do template |
+| `/prd validate [arquivo]` | Valida completude do PRD |
+| `/prd status` | Mostra status dos PRDs do projeto |
+
+---
+
+## 🔴 FLUXO
+
+### Phase 1: DISCOVERY (`/prd new`)
+
+#### Trigger
+```
+/prd new [nome-do-projeto]
+```
+
+#### Agentes Envolvidos
+- `product-owner` - Lead do discovery
+- `project-planner` - Estruturação
+
+#### Skill
+- `brainstorming` - Socratic Gate obrigatório
+
+#### Socratic Gate (3 NÍVEIS - OBRIGATÓRIO)
+
+**Nível 1: Problema e Contexto**
+| # | Pergunta | Campo PRD |
+|---|----------|-----------|
+| 1 | 🎯 Qual problema estamos resolvendo? | Problem Statement |
+| 2 | 🌍 Qual o contexto de mercado/negócio? | Market Context |
+| 3 | 💡 Qual a visão de sucesso? | Vision |
+| 4 | 📊 Como mediremos o sucesso? | Success Metrics |
+
+**Nível 2: Usuários e Jornadas**
+| # | Pergunta | Campo PRD |
+|---|----------|-----------|
+| 5 | 👥 Quem são os principais usuários? (personas) | Target Users |
+| 6 | 🎭 Quais os perfis de cada persona? | User Personas |
+| 7 | 🗺️ Qual a jornada atual do usuário? | Current Journey |
+| 8 | ⚠️ Quais são as principais frustrações? | Pain Points |
+
+**Nível 3: Requisitos e Escopo**
+| # | Pergunta | Campo PRD |
+|---|----------|-----------|
+| 9 | 📦 Quais funcionalidades são essenciais (MVP)? | MVP Features |
+| 10 | 🚀 O que pode ficar para fases futuras? | Future Features |
+| 11 | 🔐 Requisitos de segurança/compliance? | Non-Functional |
+| 12 | ⏰ Qual o prazo esperado para MVP? | Timeline |
+
+#### Ações
+1. **Executar Socratic Gate** completo (todas as perguntas)
+2. **Copiar template** de `.agent/templates/prd-template.md`
+3. **Criar arquivo** em `docs/PRD-{nome-do-projeto}.md`
+4. **Preencher PRD** com respostas coletadas
+5. **Registry:** `document-registry` — criar entry `PRD-{nome}` no INDEX.md com status `draft`
+
+#### Output Esperado
+```
+[OK] PRD criado: docs/PRD-{nome}.md
+[OK] INDEX.md entry criada: PRD-{nome} (draft)
+[OK] Status: Rascunho
+[NEXT] Execute /prd validate docs/PRD-{nome}.md
+```
+
+---
+
+### Phase 2: VALIDATE (`/prd validate`)
+
+#### Trigger
+```
+/prd validate docs/PRD-{nome}.md
+```
+
+#### Agente Envolvido
+- `product-owner` - Validação de completude
+
+#### Validações Realizadas
+
+| Categoria | Verificação |
+|-----------|-------------|
+| **Problema** | Problem Statement está claro e específico? |
+| **Personas** | Pelo menos 2 personas definidas? |
+| **MVP** | Features do MVP claramente delimitadas? |
+| **Métricas** | KPIs de sucesso definidos? |
+| **Riscos** | Riscos identificados com mitigações? |
+
+#### Output Esperado
+```markdown
+## PRD Validation Report
+
+### ✅ Seções Completas
+- [x] Problem Statement
+- [x] User Personas
+- [x] MVP Features
+
+### ⚠️ Itens Incompletos
+- [ ] Success Metrics não quantificados
+- [ ] Timeline sem datas específicas
+
+### ❌ Seções Faltando
+- [ ] Competitive Analysis
+
+### 📊 Score: 80% Completo
+
+### Recomendação
+[Próximos passos para completar]
+```
+
+---
+
+### Phase 3: APPROVE (Humano)
+
+#### Trigger
+Após validação, o **humano** deve:
+
+1. **Revisar** o PRD completo
+2. **Ajustar** itens incompletos
+3. **Aprovar** marcando no documento:
+   ```markdown
+   - [x] **Aprovado para Discovery Técnico**
+   ```
+
+#### 🔴 REGRA DE OURO
+> A IA **NÃO** pode prosseguir para `/tdd` ou `/discovery` sem aprovação humana do PRD.
+
+---
+
+### Phase 4: NEXT STEPS
+
+Após aprovação do PRD, sugerir:
+
+```
+🎉 PRD APROVADO!
+
+Próximos passos disponíveis:
+
+1. /tdd new → Technical Design Document (RECOMENDADO - define arquitetura)
+2. /discovery → Brainstorm técnico + User Stories + Tasks no Flyee
+3. /demand → Gerar proposta comercial (se for projeto cliente)
+4. /new-project → Fluxo completo automatizado (PRD já aprovado → TDD → Testes → Código)
+```
+
+### Phase 4.1: RASTREABILIDADE (Obrigatório)
+
+> [!IMPORTANT]
+> **Após criar o SDD**, o documento deve referenciar este PRD:
+> ```markdown
+> PRD Fonte: docs/PRD-{nome}.md
+> ```
+
+**Regra de Ouro:** Todo SDD DEVE ter um PRD aprovado como fonte.
+
+---
+
+## 📁 Estrutura de Arquivos
+
+```
+projeto/
+├── docs/
+│   ├── INDEX.md                        # Document Registry
+│   ├── PRD-meu-produto.md              # PRD do projeto
+│   └── design/
+│       └── SDD-meu-produto.md          # SDD (gerado após PRD)
+```
+
+---
+
+## 🔄 Status Lifecycle
+
+```
+[Rascunho] → [Em Revisão] → [Aprovado] → [Em Discovery] → [Concluído]
+```
+
+| Status | Significado |
+|--------|-------------|
+| Rascunho | Sendo escrito, discovery em andamento |
+| Em Revisão | Validação e ajustes finais |
+| Aprovado | Pronto para próximas fases |
+| Em Discovery | Gerando SDD/Discovery técnico |
+| Concluído | Projeto iniciado |
+
+---
+
+## 🔗 INTEGRAÇÃO COM OUTROS WORKFLOWS
+
+| De | Para | Como |
+|----|------|------|
+| `/prd` | `/discovery` | PRD alimenta brainstorm com contexto |
+| `/prd` | `/tdd` | Seções de MVP → Fluxos técnicos |
+| `/prd` | `/demand` | Escopo → Estimativa comercial |
+
+---
+
+## 🔴 REGRAS CRÍTICAS
+
+1. **Socratic Gate é OBRIGATÓRIO** - Não pular perguntas
+2. **Humano aprova PRD** - Nunca auto-aprovar
+3. **PRD antes de SDD** — PRD define O QUÊ, SDD define COMO
+4. **Um produto = Um PRD** - Não misturar produtos/projetos
+
+---
+
+## Usage Examples
+
+```bash
+# Criar PRD para novo produto
+/prd new meu-app-fitness
+
+# Validar PRD existente
+/prd validate docs/PRD-meu-app-fitness.md
+
+# Ver status de todos os PRDs
+/prd status
+
+# Fluxo completo
+/prd new ecommerce-platform
+# [Responder perguntas do Socratic Gate]
+# [Revisar PRD gerado]
+/prd validate docs/PRD-ecommerce-platform.md
+# [Ajustar conforme necessário]
+# [Aprovar manualmente no documento]
+/discovery  # Continua para discovery técnico
+```

package/core/workflows/preview.md

@@ -0,0 +1,81 @@
+---
+description: Preview server start, stop, and status check. Local development server management.
+---
+
+# /preview - Preview Management
+
+$ARGUMENTS
+
+---
+
+## Task
+
+Manage preview server: start, stop, status check.
+
+### Commands
+
+```
+/preview           - Show current status
+/preview start     - Start server
+/preview stop      - Stop server
+/preview restart   - Restart
+/preview check     - Health check
+```
+
+---
+
+## Usage Examples
+
+### Start Server
+```
+/preview start
+
+Response:
+🚀 Starting preview...
+   Port: 3000
+   Type: Next.js
+
+✅ Preview ready!
+   URL: http://localhost:3000
+```
+
+### Status Check
+```
+/preview
+
+Response:
+=== Preview Status ===
+
+🌐 URL: http://localhost:3000
+📁 Project: C:/projects/my-app
+🏷️ Type: nextjs
+💚 Health: OK
+```
+
+### Port Conflict
+```
+/preview start
+
+Response:
+⚠️ Port 3000 is in use.
+
+Options:
+1. Start on port 3001
+2. Close app on 3000
+3. Specify different port
+
+Which one? (default: 1)
+```
+
+---
+
+## Technical
+
+Auto preview uses `auto_preview.py` script:
+
+```bash
+python .agent/scripts/auto_preview.py start [port]
+python .agent/scripts/auto_preview.py stop
+python .agent/scripts/auto_preview.py status
+```
+