ganbatte-os 0.2.1

package/skills/make-code-triage/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: make-code-triage
+description: >
+  Classifica codigo do Figma Make em categorias (UI pura, data fetching, mock data, API calls, types)
+  e produz plano de triagem com destino de cada bloco na arquitetura do projeto.
+  Use apos figma-make-analyzer ou quando receber codigo Make bruto para integrar.
+argument-hint: "[path do inventario JSON do figma-make-analyzer OU path direto do codigo Make]"
+allowedTools: [Read, Glob, Grep, Write, Edit]
+use-when:
+  - apos figma-make-analyzer produzir inventario JSON
+  - receber codigo Make bruto e precisar classificar antes de implementar
+  - iniciar triagem BE/FE de importacao Figma Make
+  - cenarios Full Build, Incremental, Dual Source ou Maintenance
+do-not-use-for:
+  - analisar output Make (use figma-make-analyzer primeiro)
+  - implementar componentes (use frontend-dev ou design-to-code)
+  - revisar codigo existente (use senior-review)
+metadata:
+  category: document-asset
+---
+
+# Make Code Triage
+
+## Overview
+
+Recebe inventario do `figma-make-analyzer` (ou path direto de codigo Make) e classifica cada bloco em categorias da arquitetura Next.js + Supabase. Produz plano de triagem com destino exato de cada bloco, facilitando a importacao organizada.
+
+**Announce at start:** "Estou usando make-code-triage para classificar o codigo Make por camada arquitetural."
+
+## Classification categories
+
+| Categoria | Destino | Criterio |
+|-----------|---------|----------|
+| **UI pura** | `components/` ou `app/*/page.tsx` | Renderiza JSX, sem data fetching, sem side effects |
+| **Data fetching** | `hooks/` ou `services/` | Chama API, fetch, useEffect com request, SWR/React Query |
+| **Mock data** | `app/api/*/seed/route.ts` | Dados hardcoded, arrays de objetos, constantes de exemplo |
+| **API call** | `services/` ou `lib/api/` | HTTP client, Supabase client, RPC calls |
+| **Types** | `types/` ou `domain.ts` | Interfaces, types, enums, Zod schemas |
+| **Style tokens** | `globals.css` ou `tailwind.config.ts` | CSS variables, cores, espacamentos, tipografia |
+| **Mixed** | Requer split | Componente que mistura UI + data — precisa ser separado |
+
+## Procedure
+
+### Step 1: Load inventory
+1. Se input e JSON do figma-make-analyzer → carregar diretamente
+2. Se input e path de diretorio → rodar scan basico (glob + parse)
+3. Validar que ha componentes para classificar
+
+### Step 2: Classify each component
+Para cada componente no inventario:
+1. Analisar corpo do componente (JSX, hooks, imports)
+2. Detectar presenca de data fetching (fetch, useEffect, useSWR, supabase.from)
+3. Detectar mock data (arrays const com dados de exemplo)
+4. Detectar chamadas API (HTTP client, service imports)
+5. Classificar em uma das categorias acima
+6. Se **Mixed**: marcar para split e indicar quais partes sao UI vs data
+
+### Step 3: Map destinations
+Para cada componente classificado:
+1. Determinar path de destino na arquitetura do projeto
+2. Seguir service layer: `Component → Hook → Service → Supabase`
+3. Componentes nunca chamam APIs diretamente (R4)
+4. Mock data vai para seed routes (R3)
+
+### Step 4: Generate triage plan
+Produzir plano em Markdown:
+
+```markdown
+# Triage Plan: [Source]
+
+## Summary
+- Total components: N
+- UI pura: N
+- Data fetching: N (→ hooks/services)
+- Mock data: N (→ seed routes)
+- API calls: N (→ service layer)
+- Types: N (→ domain.ts)
+- Mixed (requer split): N
+
+## Import Order (by wave)
+
+### Wave 1: Types + Tokens
+| Component | Category | Destination |
+|-----------|----------|-------------|
+| ... | types | types/domain.ts |
+
+### Wave 2: Services + Hooks
+| Component | Category | Destination |
+|-----------|----------|-------------|
+| ... | data-fetching | hooks/useX.ts |
+
+### Wave 3: UI Components
+| Component | Category | Destination |
+|-----------|----------|-------------|
+| ... | ui-pure | components/X.tsx |
+
+### Wave 4: Pages
+| Component | Category | Destination |
+|-----------|----------|-------------|
+| ... | ui-pure (page) | app/X/page.tsx |
+
+## Components Requiring Split
+| Component | UI Part | Data Part | Action |
+|-----------|---------|-----------|--------|
+| ... | → components/ | → hooks/ | Separar UI de data fetching |
+
+## Seed Routes Needed
+| Route | Mock Data Source | Endpoint |
+|-------|-----------------|----------|
+| ... | ComponentX mock array | app/api/X/seed/route.ts |
+```
+
+### Step 5: Save plan
+Salvar em `docs/plans/NN-triage-[source].md` seguindo `rules/project-docs-convention.md`.
+
+## Definition of Done
+
+- [ ] Todos os componentes do inventario classificados
+- [ ] Nenhum componente Mixed sem plano de split
+- [ ] Import order organizado por waves (types → services → UI → pages)
+- [ ] Seed routes identificadas para todos os mock data
+- [ ] Service layer respeitada (nenhum componente chama API diretamente)
+- [ ] Plano salvo em `docs/plans/`
+
+## When to Use
+- Use according to the triggers described in the description/use-when list.
+
+## Do not use
+- Fora do escopo descrito; prefira a skill apropriada.
+
+## Related artifacts
+- `skills/figma-make-analyzer/SKILL.md` — produz inventario de input
+- `skills/frontend-dev/SKILL.md` — implementa componentes apos triagem
+- `skills/component-dedup/SKILL.md` — deduplica antes de implementar
+- `rules/project-docs-convention.md` — onde salvar o triage plan

package/skills/make-version-diff/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: make-version-diff
+description: >
+  Compara duas versoes de output do Figma Make (nova vs projeto existente) e produz plano
+  de atualizacao com componentes adicionados, alterados e removidos.
+  Use no cenario Maintenance quando nova versao do Make chega.
+argument-hint: "[path da versao nova do Make] [path do projeto existente]"
+allowedTools: [Read, Glob, Grep, Bash, Write, Edit]
+use-when:
+  - nova versao do Figma Make chega e precisa atualizar projeto
+  - cenario Maintenance (comparar versao atual vs nova)
+  - identificar breaking changes entre versoes do Make
+do-not-use-for:
+  - primeira importacao do Make (use figma-make-analyzer modo full)
+  - comparar Figma Design vs Figma Make (use figma-divergence-detector)
+  - implementar mudancas (use frontend-dev apos o diff)
+metadata:
+  category: workflow-automation
+---
+
+# Make Version Diff
+
+## Overview
+
+Workflow que compara duas versoes de output do Figma Make para produzir um plano de atualizacao estruturado. Usa `figma-make-analyzer` em modo diff e encadeia com `diff-review-visual` e `wave-execution` para implementacao.
+
+**Announce at start:** "Estou usando make-version-diff para comparar versoes do Figma Make."
+
+## Composition chain
+
+```
+figma-make-analyzer (versao nova) → figma-make-analyzer (diff vs projeto) →
+diff-review-visual diff → make-code-triage → wave-execution
+```
+
+## Procedure
+
+### Step 1: Analyze new version
+1. Rodar `figma-make-analyzer` em modo `full` no diretorio da nova versao
+2. Produzir `figma-make-inventory-new.json`
+
+### Step 2: Diff against project
+1. Rodar `figma-make-analyzer` em modo `diff` comparando novo vs existente
+2. Produzir `figma-make-diff.json` com:
+   - Componentes adicionados (novos no Make)
+   - Componentes alterados (props mudaram, estrutura mudou)
+   - Componentes removidos (existiam antes, nao mais)
+   - Breaking changes (tipos alterados, props removidos)
+
+### Step 3: Visual diff report
+1. Usar `/diff-review-visual diff` para gerar report visual HTML
+2. Highlights: before/after panels para componentes alterados
+3. Lista de breaking changes com impacto estimado
+
+### Step 4: Triage changes
+1. Usar `make-code-triage` para classificar mudancas por camada
+2. Priorizar: breaking changes primeiro, depois adicionais, depois cosmeticos
+
+### Step 5: Generate update plan
+Produzir plano em `docs/plans/NN-make-update-[date].md` com waves:
+- Wave 1: Types + breaking changes
+- Wave 2: Componentes alterados
+- Wave 3: Componentes novos
+- Wave 4: Stories atualizadas
+
+### Step 6: Execute via waves (optional)
+Se usuario aprovar: executar plano via `/wave-execution`
+
+## Definition of Done
+
+- [ ] Inventario da versao nova gerado
+- [ ] Diff report com added/modified/removed/breaking
+- [ ] Visual diff HTML gerado
+- [ ] Update plan salvo em `docs/plans/`
+- [ ] Progress sidecar criado
+
+## When to Use
+- Use according to the triggers described in the description/use-when list.
+
+## Do not use
+- Fora do escopo descrito; prefira a skill apropriada.
+
+## Related artifacts
+- `skills/figma-make-analyzer/SKILL.md` — analise de versoes individuais
+- `skills/make-code-triage/SKILL.md` — triagem de mudancas
+- `skills/diff-review-visual/SKILL.md` — report visual de diff
+- `skills/wave-execution/SKILL.md` — execucao do plano de update

package/skills/plan-to-tasks/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: plan-to-tasks
+description: Parse a plan, ADR, PRD, or spec document and generate actionable task files in ./.G-OS/tasks/ using the project task template. Use when given a planning document and asked to break it into tasks.
+argument-hint: "<path-to-plan-file-or-description>"
+use-when:
+  - receber um plano, PRD, ADR ou spec e precisar gerar tasks executaveis
+  - iniciar sprint a partir de documento de planejamento ja aprovado
+  - quebrar entrega grande em tarefas independentes com DoD mensuravel
+  - coordenar dependencias entre camadas tecnicas (back, front, DB, testes)
+do-not-use-for:
+  - criar plano do zero sem documento de entrada (use brainstorming ou project-brief)
+  - estimar esforco sem contexto de codebase (use qa ou senior-review)
+metadata:
+  category: workflow-automation
+---
+
+You are operating as a **Tasks Writer** for the G-OS project, following the G-OS Agent-Driven Agile methodology.
+
+## Input
+$ARGUMENTS
+
+## Procedure
+
+### Phase 1 — Read & understand the input
+1. If `$ARGUMENTS` is a file path, read that file. If it's a description, work from the description.
+2. Read `./.G-OS/agents/tasks-writer.system.md` to internalize the DoD for tasks.
+3. Read `./.G-OS/templates/taskTemplate.md` to get the exact format.
+4. Read `./.G-OS/tasks/README.md` (if it exists) to understand the current task naming convention.
+
+### Phase 2 — Decompose into tasks
+Analyze the plan and extract:
+- **Distinct deliverables** → one task per deliverable (not per sub-step)
+- **Technical layers**: DB migrations, API routes, frontend components, tests — each may be a separate task if non-trivial
+- **Dependencies**: task A must complete before task B
+- **Priority**: P0 (blocking/critical), P1 (important), P2 (nice-to-have)
+
+Rules:
+- Each task must be **independently deliverable** (can be reviewed in isolation)
+- Maximum task size: **1 day** estimate. Split larger work.
+- Every task needs a **measurable DoD** — no "improve X" without a metric
+
+### Phase 3 — Generate task files
+
+For each task, create a file following the project docs convention:
+
+**Primary location (per-project):** `docs/tasks/NN-name/TASK-NN-desc.md`
+Where `NN` matches the plan prefix and tasks use zero-padded sequence (01, 02, ...).
+
+**Fallback (framework tasks):** `./.G-OS/tasks/TASK-<YYYYMM>-<seq>.md`
+Use only if `docs/tasks/` does not exist or for framework-internal tasks.
+
+Use this template (from `./.G-OS/templates/taskTemplate.md`):
+
+```markdown
+---
+id: TASK-<YYYYMM>-<seq>
+title: <imperative action verb + what>
+area: <security|backend|ui-ux|routers|migrations|tests|general>
+labels: [agent:<slug>, type:<refactor|bug|feature|chore>]
+priority: <P0|P1|P2>
+estimate: "<2h|4h|1d>"
+assignees: []
+due: null
+links: []
+---
+
+## Contexto
+<why this task exists — link to the source plan/ADR/PRD>
+
+## Objetivo
+<expected result in 1-2 sentences>
+
+## Plano de execução
+- [ ] Step 1
+- [ ] Step 2
+- [ ] Step 3
+
+## Critérios de aceitação (DoD)
+- [ ] Tests/CI green
+- [ ] No regressions
+- [ ] <measurable metric: e.g., coverage ≥70% | endpoint returns <200ms | UI renders correctly on mobile>
+
+## Riscos & Rollback
+- <risk>
+- Rollback plan: <git tag/migration revert command>
+```
+
+### Phase 4 — Output a summary
+
+After creating all task files, output:
+
+```
+## Tasks created from: <source plan name>
+
+| Task ID | Title | Priority | Estimate | Agent |
+|---------|-------|----------|----------|-------|
+| TASK-YYYYMM-001 | ... | P0 | 4h | backend |
+| TASK-YYYYMM-002 | ... | P1 | 1d | fe |
+...
+
+## Dependency order
+1. TASK-001 (migrations) → 2. TASK-002 (backend routes) → 3. TASK-003 (frontend)
+
+## Next step
+Run `/tdd TASK-YYYYMM-001` to start test-driven implementation of the first task.
+```
+
+## Model guidance
+
+| Scope | Recommended model |
+|-------|-------------------|
+| Decompose a small, clear spec into 3-5 tasks | `sonnet` (default) |
+| Large PRD/ADR with ambiguity, many dependencies, prioritization | `opus` |
+
+> Plan decomposition always requires at least `sonnet` — Haiku misses dependencies and produces vague DoDs.
+
+## Agent slugs reference
+- `backend` — Fastify routes, Supabase, SQLite, migrations
+- `fe` — React components, hooks, pages
+- `tests` — Vitest tests, coverage
+- `security` — Auth, permissions, RLS
+- `devops` — CI/CD, deployments
+- `uiuxPlanner` — UX improvements, accessibility
+- `debugger` — Bug investigation
+- `general` — Documentation, config, chores
+
+## When to Use
+- Use according to the triggers described in the description/use-when list.
+
+## Do not use
+- Fora do escopo descrito; prefira a skill apropriada.
+
+## Instructions
+1) Siga o passo-a-passo principal da skill.
+2) Valide saa com checklists desta skill ou do workflow.
+3) Registre decises relevantes se aplic5vel.