flyee 0.1.0

package/core/skills/performance-profiling/scripts/lighthouse_audit.py

@@ -0,0 +1,76 @@
+#!/usr/bin/env python3
+"""
+Skill: performance-profiling
+Script: lighthouse_audit.py
+Purpose: Run Lighthouse performance audit on a URL
+Usage: python lighthouse_audit.py https://example.com
+Output: JSON with performance scores
+Note: Requires lighthouse CLI (npm install -g lighthouse)
+"""
+import subprocess
+import json
+import sys
+import os
+import tempfile
+
+def run_lighthouse(url: str) -> dict:
+    """Run Lighthouse audit on URL."""
+    try:
+        with tempfile.NamedTemporaryFile(suffix='.json', delete=False) as f:
+            output_path = f.name
+        
+        result = subprocess.run(
+            [
+                "lighthouse",
+                url,
+                "--output=json",
+                f"--output-path={output_path}",
+                "--chrome-flags=--headless",
+                "--only-categories=performance,accessibility,best-practices,seo"
+            ],
+            capture_output=True,
+            text=True,
+            timeout=120
+        )
+        
+        if os.path.exists(output_path):
+            with open(output_path, 'r') as f:
+                report = json.load(f)
+            os.unlink(output_path)
+            
+            categories = report.get("categories", {})
+            return {
+                "url": url,
+                "scores": {
+                    "performance": int(categories.get("performance", {}).get("score", 0) * 100),
+                    "accessibility": int(categories.get("accessibility", {}).get("score", 0) * 100),
+                    "best_practices": int(categories.get("best-practices", {}).get("score", 0) * 100),
+                    "seo": int(categories.get("seo", {}).get("score", 0) * 100)
+                },
+                "summary": get_summary(categories)
+            }
+        else:
+            return {"error": "Lighthouse failed to generate report", "stderr": result.stderr[:500]}
+            
+    except subprocess.TimeoutExpired:
+        return {"error": "Lighthouse audit timed out"}
+    except FileNotFoundError:
+        return {"error": "Lighthouse CLI not found. Install with: npm install -g lighthouse"}
+
+def get_summary(categories: dict) -> str:
+    """Generate summary based on scores."""
+    perf = categories.get("performance", {}).get("score", 0) * 100
+    if perf >= 90:
+        return "[OK] Excellent performance"
+    elif perf >= 50:
+        return "[!] Needs improvement"
+    else:
+        return "[X] Poor performance"
+
+if __name__ == "__main__":
+    if len(sys.argv) < 2:
+        print(json.dumps({"error": "Usage: python lighthouse_audit.py <url>"}))
+        sys.exit(1)
+    
+    result = run_lighthouse(sys.argv[1])
+    print(json.dumps(result, indent=2))

package/core/skills/plan-writing/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: plan-writing
+description: Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
+allowed-tools: Read, Glob, Grep
+---
+
+# Plan Writing
+
+> Source: obra/superpowers
+
+## Overview
+This skill provides a framework for breaking down work into clear, actionable tasks with verification criteria.
+
+## Task Breakdown Principles
+
+### 1. Small, Focused Tasks
+- Each task should take 2-5 minutes
+- One clear outcome per task
+- Independently verifiable
+
+### 2. Clear Verification
+- How do you know it's done?
+- What can you check/test?
+- What's the expected output?
+
+### 3. Logical Ordering
+- Dependencies identified
+- Parallel work where possible
+- Critical path highlighted
+- **Phase X: Verification is always LAST**
+
+### 4. Dynamic Naming in Project Root
+- Plan files are saved as `{task-slug}.md` in the PROJECT ROOT
+- Name derived from task (e.g., "add auth" → `auth-feature.md`)
+- **NEVER** inside `.claude/`, `docs/`, or temp folders
+
+## Planning Principles (NOT Templates!)
+
+> 🔴 **NO fixed templates. Each plan is UNIQUE to the task.**
+
+### Principle 1: Keep It SHORT
+
+| ❌ Wrong | ✅ Right |
+|----------|----------|
+| 50 tasks with sub-sub-tasks | 5-10 clear tasks max |
+| Every micro-step listed | Only actionable items |
+| Verbose descriptions | One-line per task |
+
+> **Rule:** If plan is longer than 1 page, it's too long. Simplify.
+
+---
+
+### Principle 2: Be SPECIFIC, Not Generic
+
+| ❌ Wrong | ✅ Right |
+|----------|----------|
+| "Set up project" | "Run `npx create-next-app`" |
+| "Add authentication" | "Install next-auth, create `/api/auth/[...nextauth].ts`" |
+| "Style the UI" | "Add Tailwind classes to `Header.tsx`" |
+
+> **Rule:** Each task should have a clear, verifiable outcome.
+
+---
+
+### Principle 3: Dynamic Content Based on Project Type
+
+**For NEW PROJECT:**
+- What tech stack? (decide first)
+- What's the MVP? (minimal features)
+- What's the file structure?
+
+**For FEATURE ADDITION:**
+- Which files are affected?
+- What dependencies needed?
+- How to verify it works?
+
+**For BUG FIX:**
+- What's the root cause?
+- What file/line to change?
+- How to test the fix?
+
+---
+
+### Principle 4: Scripts Are Project-Specific
+
+> 🔴 **DO NOT copy-paste script commands. Choose based on project type.**
+
+| Project Type | Relevant Scripts |
+|--------------|------------------|
+| Frontend/React | `ux_audit.py`, `accessibility_checker.py` |
+| Backend/API | `api_validator.py`, `security_scan.py` |
+| Mobile | `mobile_audit.py` |
+| Database | `schema_validator.py` |
+| Full-stack | Mix of above based on what you touched |
+
+**Wrong:** Adding all scripts to every plan
+**Right:** Only scripts relevant to THIS task
+
+---
+
+### Principle 5: Verification is Simple
+
+| ❌ Wrong | ✅ Right |
+|----------|----------|
+| "Verify the component works correctly" | "Run `npm run dev`, click button, see toast" |
+| "Test the API" | "curl localhost:3000/api/users returns 200" |
+| "Check styles" | "Open browser, verify dark mode toggle works" |
+
+---
+
+## Plan Structure (Flexible, Not Fixed!)
+
+```
+# [Task Name]
+
+## Goal
+One sentence: What are we building/fixing?
+
+## Tasks
+- [ ] Task 1: [Specific action] → Verify: [How to check]
+- [ ] Task 2: [Specific action] → Verify: [How to check]
+- [ ] Task 3: [Specific action] → Verify: [How to check]
+
+## Done When
+- [ ] [Main success criteria]
+```
+
+> **That's it.** No phases, no sub-sections unless truly needed.
+> Keep it minimal. Add complexity only when required.
+
+## Notes
+[Any important considerations]
+```
+
+---
+
+### Principle 6: UI Component Decomposition Gate (MANDATORY for UI tasks)
+
+> 🔴 **Before listing ANY `[NEW]` UI component in the plan, classify it.**
+> A plan that puts a generic visual concept (Timeline, KpiCard, DataTable) directly inside
+> `features/{name}/components/` without extracting the reusable primitive is **INVALID**.
+
+**For EACH new UI component in the plan, ask:**
+
+| # | Question | If YES | If NO |
+|---|----------|--------|-------|
+| 1 | Is the **visual concept** usable in 2+ features? (e.g. Timeline, StatCard, DataTable) | → Extract generic primitive to `components/ui/` | Continue ↓ |
+| 2 | Could another dev reuse the visual without knowing the business context? | → Extract to `components/ui/` | Continue ↓ |
+| 3 | Is it purely business-specific with no reusable visual? | → OK in `features/{name}/components/` | → `components/ui/` |
+
+**Plan format when decomposition applies:**
+
+```markdown
+## New Components
+
+### Generic (components/ui/) — reusable primitives
+- [NEW] `components/ui/Timeline/` — Vertical timeline with connectors (Atom/Molecule)
+- [NEW] `components/ui/KpiCard/` — Stat card with label, value, trend (Molecule)
+
+### Feature-specific (features/progress/components/) — business orchestrators
+- [NEW] `SprintTimeline.tsx` — Maps sprint data → `<Timeline>` items
+- [NEW] `ProgressOverview.tsx` — Maps project KPIs → grid of `<KpiCard>`
+```
+
+> **Anti-pattern:** `[NEW] features/progress/components/SprintTimeline.tsx` with its own
+> `.module.css` that builds a full timeline visual from scratch. This locks the Timeline
+> concept inside one feature and guarantees duplication when Activity or Deployments need it.
+
+> **Historical Lesson:** `SprintTimeline` and `ProgressOverview` were planned entirely inside
+> `features/progress/` without extracting `Timeline` and `KpiCard` as generic primitives.
+> Result: the visual concepts would be trapped in one feature, forcing duplication later.
+
+---
+
+## Best Practices (Quick Reference)
+
+1. **Start with goal** - What are we building/fixing?
+2. **Max 10 tasks** - If more, break into multiple plans
+3. **Each task verifiable** - Clear "done" criteria
+4. **Project-specific** - No copy-paste templates
+5. **Update as you go** - Mark `[x]` when complete
+
+---
+
+## When to Use
+
+- New project from scratch
+- Adding a feature
+- Fixing a bug (if complex)
+- Refactoring multiple files

package/core/skills/powershell-windows/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: powershell-windows
+description: PowerShell Windows patterns. Critical pitfalls, operator syntax, error handling.
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+---
+
+# PowerShell Windows Patterns
+
+> Critical patterns and pitfalls for Windows PowerShell.
+
+---
+
+## 1. Operator Syntax Rules
+
+### CRITICAL: Parentheses Required
+
+| ❌ Wrong | ✅ Correct |
+|----------|-----------|
+| `if (Test-Path "a" -or Test-Path "b")` | `if ((Test-Path "a") -or (Test-Path "b"))` |
+| `if (Get-Item $x -and $y -eq 5)` | `if ((Get-Item $x) -and ($y -eq 5))` |
+
+**Rule:** Each cmdlet call MUST be in parentheses when using logical operators.
+
+---
+
+## 2. Unicode/Emoji Restriction
+
+### CRITICAL: No Unicode in Scripts
+
+| Purpose | ❌ Don't Use | ✅ Use |
+|---------|-------------|--------|
+| Success | ✅ ✓ | [OK] [+] |
+| Error | ❌ ✗ 🔴 | [!] [X] |
+| Warning | ⚠️ 🟡 | [*] [WARN] |
+| Info | ℹ️ 🔵 | [i] [INFO] |
+| Progress | ⏳ | [...] |
+
+**Rule:** Use ASCII characters only in PowerShell scripts.
+
+---
+
+## 3. Null Check Patterns
+
+### Always Check Before Access
+
+| ❌ Wrong | ✅ Correct |
+|----------|-----------|
+| `$array.Count -gt 0` | `$array -and $array.Count -gt 0` |
+| `$text.Length` | `if ($text) { $text.Length }` |
+
+---
+
+## 4. String Interpolation
+
+### Complex Expressions
+
+| ❌ Wrong | ✅ Correct |
+|----------|-----------|
+| `"Value: $($obj.prop.sub)"` | Store in variable first |
+
+**Pattern:**
+```
+$value = $obj.prop.sub
+Write-Output "Value: $value"
+```
+
+---
+
+## 5. Error Handling
+
+### ErrorActionPreference
+
+| Value | Use |
+|-------|-----|
+| Stop | Development (fail fast) |
+| Continue | Production scripts |
+| SilentlyContinue | When errors expected |
+
+### Try/Catch Pattern
+
+- Don't return inside try block
+- Use finally for cleanup
+- Return after try/catch
+
+---
+
+## 6. File Paths
+
+### Windows Path Rules
+
+| Pattern | Use |
+|---------|-----|
+| Literal path | `C:\Users\User\file.txt` |
+| Variable path | `Join-Path $env:USERPROFILE "file.txt"` |
+| Relative | `Join-Path $ScriptDir "data"` |
+
+**Rule:** Use Join-Path for cross-platform safety.
+
+---
+
+## 7. Array Operations
+
+### Correct Patterns
+
+| Operation | Syntax |
+|-----------|--------|
+| Empty array | `$array = @()` |
+| Add item | `$array += $item` |
+| ArrayList add | `$list.Add($item) | Out-Null` |
+
+---
+
+## 8. JSON Operations
+
+### CRITICAL: Depth Parameter
+
+| ❌ Wrong | ✅ Correct |
+|----------|-----------|
+| `ConvertTo-Json` | `ConvertTo-Json -Depth 10` |
+
+**Rule:** Always specify `-Depth` for nested objects.
+
+### File Operations
+
+| Operation | Pattern |
+|-----------|---------|
+| Read | `Get-Content "file.json" -Raw | ConvertFrom-Json` |
+| Write | `$data | ConvertTo-Json -Depth 10 | Out-File "file.json" -Encoding UTF8` |
+
+---
+
+## 9. Common Errors
+
+| Error Message | Cause | Fix |
+|---------------|-------|-----|
+| "parameter 'or'" | Missing parentheses | Wrap cmdlets in () |
+| "Unexpected token" | Unicode character | Use ASCII only |
+| "Cannot find property" | Null object | Check null first |
+| "Cannot convert" | Type mismatch | Use .ToString() |
+
+---
+
+## 10. Script Template
+
+```powershell
+# Strict mode
+Set-StrictMode -Version Latest
+$ErrorActionPreference = "Continue"
+
+# Paths
+$ScriptDir = Split-Path -Parent $MyInvocation.MyCommand.Path
+
+# Main
+try {
+    # Logic here
+    Write-Output "[OK] Done"
+    exit 0
+}
+catch {
+    Write-Warning "Error: $_"
+    exit 1
+}
+```
+
+---
+
+> **Remember:** PowerShell has unique syntax rules. Parentheses, ASCII-only, and null checks are non-negotiable.

package/core/skills/project-foundation/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: project-foundation
+description: Protocolo para gerar os arquivos de fundação de qualquer projeto (README, .env.example, SECURITY.md, docs/INDEX.md, ADR-000). Usado por new-project (Phase 2.05) e legacy-project (Phase 0.7). Context-aware para projetos novos vs legados.
+---
+
+# Skill: project-foundation
+
+## Propósito
+
+Garantir que todo projeto tenha a infraestrutura mínima de documentação **antes** de qualquer trabalho de feature ou análise. Um agente que abrir o projeto futuramente precisa de um ponto de entrada claro.
+
+> [!IMPORTANT]
+> Este skill é chamado automaticamente por workflows. Não pule nenhum dos 5 artefatos — todos são necessários para que agentes futuros funcionem corretamente.
+
+---
+
+## Contextos de Uso
+
+| Contexto | Trigger | Comportamento |
+|----------|---------|---------------|
+| `new` | `new-project` Phase 2.05 | Gera todos os arquivos do zero a partir dos templates |
+| `legacy` | `legacy-project` Phase 0.7 | Adapta ao que já existe: README existente é atualizado, `.env.example` é extraído das variáveis detectadas no código |
+
+---
+
+## Protocolo de Execução
+
+### Passo 1: README.md
+
+**Modo `new`:**
+> Gerar do zero usando `readme-template.md`. Preencher stack, comandos de run/test/build e environments.
+
+**Modo `legacy`:**
+> 1. Verificar se `README.md` já existe
+> 2. Se existe: atualizar seções desatualizadas (stack, comandos, envs) sem destruir conteúdo
+> 3. Se não existe: gerar do zero como se fosse modo `new`
+
+**Gate:** README deve ter no mínimo: descrição, stack, como rodar localmente, environments.
+
+---
+
+### Passo 2: .env.example
+
+**Modo `new`:**
+> Gerar do zero usando `env-template.md`. Preencher com as variáveis já conhecidas (DB, auth, ports).
+
+**Modo `legacy`:**
+> 1. Buscar variáveis de ambiente no código (`process.env.*`, `os.environ`, `config(*)`)
+> 2. Buscar `.env`, `.env.local`, `.env.development` (se existirem e não estiverem no .gitignore, ler)
+> 3. Gerar `.env.example` preenchido com as variáveis encontradas (valores = placeholders)
+> 4. Anotar quais são REQUIRED vs OPTIONAL com base no uso
+
+**Gate:** `.env.example` deve cobrir todas as variáveis usadas no código.
+
+---
+
+### Passo 3: SECURITY.md
+
+**Ambos os modos:**
+> Gerar usando `security-template.md`. Preencher:
+> - Versões suportadas (detectar versão atual do projeto)
+> - Email de segurança (perguntar ao usuário se não encontrado no repo)
+> - Stack-specific items (ex: se Python → `pip-audit`; se Node → `npm audit`)
+
+**Modo `legacy`:**
+> Adicionar nota na seção "Security Practices" sobre dívida de segurança conhecida (a ser preenchida após Phase 5.6).
+
+---
+
+### Passo 4: docs/INDEX.md (Document Registry)
+
+**Ambos os modos:**
+> Criar `docs/INDEX.md` usando `docs-index-template.md`.
+
+**Modo `new`:**
+> INDEX começa com entries `pending` para todos os documentos que serão gerados pelo workflow.
+
+**Modo `legacy`:**
+> INDEX começa vazio (status = pending) e é preenchido incrementalmente conforme documentos são criados.
+> Adicionar entry inicial:
+> ```
+> | LEGACY-ANALYSIS | Analysis | docs/LEGACY-PROGRESS.md | in_progress | - | - |
+> ```
+
+**Gate:** `docs/INDEX.md` criado e commitável (não vazio, com pelo menos a entry de foundation).
+
+---
+
+### Passo 5: docs/adr/ADR-000.md
+
+**Modo `new`:**
+> Criar `docs/adr/ADR-000-initial-setup.md` documentando as decisões de stack e arquitetura
+> iniciais. Status: `accepted`.
+
+**Modo `legacy`:**
+> Criar `docs/adr/ADR-000-legacy-analysis.md` documentando a decisão de iniciar engenharia
+> reversa. Preencher template com:
+> - **Context:** Projeto existente sem documentação
+> - **Decision:** Iniciar reverse engineering com `/legacy-project`
+> - **Consequences:** Processo incremental por módulo, análise pode levar múltiplas sessões
+
+---
+
+## Checklist de Conclusão
+
+```
+[ ] README.md gerado/atualizado
+[ ] .env.example gerado (todas as variáveis cobertas)
+[ ] SECURITY.md gerado
+[ ] docs/INDEX.md criado com entries iniciais
+[ ] docs/adr/ADR-000.md criado
+[ ] Skill document-registry carregado para registrar cada doc criado acima no INDEX
+```
+
+> [!CAUTION]
+> **NÃO prosseguir para o próximo workflow step** sem todos os itens marcados.
+> Se `docs/` não existir: criar o diretório antes de gerar os arquivos.

package/core/skills/project-setup/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: project-setup
+description: Project initialization and infrastructure setup. Init commands by stack, test runner config, folder structure, and environment separation. Used before TDD methodology phase.
+---
+
+# Project Setup
+
+> Prepare base infrastructure before writing tests. No tests without a working project.
+
+---
+
+## 🎯 When to Use
+
+| Workflow | Phase | Trigger |
+|----------|-------|---------|
+| `/new-project` | Phase 3.5 | After Breakdown |
+| `/legacy-project` | Verify setup | Ensure test runner exists |
+| `/new-task` | If missing infra | Before adding feature |
+
+> [!CAUTION]
+> Do NOT start TDD (Phase 4) without infrastructure configured.
+> Cannot write tests without an initialized project.
+
+---
+
+## 🆕 New Project (No Existing Code)
+
+### 1. Initialize Project
+
+```bash
+# Web (Next.js)
+npx -y create-next-app@latest ./ --typescript --tailwind --app --src-dir --import-alias "@/*"
+
+# Mobile (React Native)
+npx react-native init {ProjectName} --template react-native-template-typescript
+
+# Package (TypeScript)
+npm init -y && npm install -D typescript tsup vitest
+```
+
+### 2. Configure Test Runner
+
+```bash
+# Next.js / React
+npm install -D vitest @testing-library/react @testing-library/dom jsdom @vitejs/plugin-react
+```
+
+### 3. Create Base Structure
+
+```
+src/
+├── app/           # Routes (Next.js)
+├── components/    # UI components
+├── lib/           # Business logic
+├── tests/         # Tests
+└── types/         # TypeScript types
+```
+
+### 4. Configure vitest.config.ts
+
+```typescript
+import { defineConfig } from 'vitest/config';
+import react from '@vitejs/plugin-react';
+
+export default defineConfig({
+  plugins: [react()],
+  test: {
+    environment: 'jsdom',
+    globals: true,
+  },
+});
+```
+
+### 5. Verify Setup
+
+```bash
+npm test -- --run  # Must run without errors (0 tests ok)
+```
+
+### 6. Configure Environment Separation (MANDATORY)
+
+> Delegate to skill `deployment-procedures` section "Environment Separation".
+> Follow all rules for `.env.local`, `.env.example`, and `.env.production`.
+
+**Quick checklist:**
+
+```markdown
+⚠️ ENVIRONMENT VALIDATION GATE
+
+[ ] `.env.example` exists with generic placeholders
+[ ] `.env.local` exists with DEVELOPMENT credentials
+[ ] `.env.local` does NOT point to production projects
+[ ] `.gitignore` includes `.env.local` and `.env.production`
+[ ] Production variables will be configured ONLY on deploy platform (Vercel)
+```
+
+**If dev projects don't exist, ask the user:**
+
+```markdown
+## 🔐 Environment Separation
+
+For security, I need **DEVELOPMENT** credentials (not production).
+
+| Service | Required Action |
+|---------|----------------|
+| **Supabase** | Create project `{name}-dev` in Supabase dashboard |
+| **Stripe** | Use `test` keys (already available in dashboard) |
+| **Sanity** | Create `development` dataset (Settings → Datasets) |
+
+When you have the dev credentials, let me know to configure `.env.local`.
+```
+
+---
+
+## 🔄 Existing Project (Has Code)
+
+1. Verify test runner exists
+2. If missing → install (step 2 above)
+3. Verify folder structure
+4. **Verify environment separation (step 6 above)**
+5. Proceed to TDD phase
+
+> [!TIP]
+> If project already exists and has tests configured, this phase is automatic (verification only).
+
+---
+
+## 🔴 Exit Gate
+
+```markdown
+[ ] Project initialized (package.json exists)
+[ ] Test runner configured (vitest/jest)
+[ ] Folder structure created
+[ ] `npm test` runs without errors
+[ ] **Environments separated (dev ≠ prod)** ⭐
+[ ] **`.env.local` with DEVELOPMENT credentials only** ⭐
+[ ] **`.env.example` with generic placeholders** ⭐
+```
+
+> After passing this gate, sync setup tasks with tracker.
+> Follow skill `project-tracking-patterns` for sync protocol.