feat: adiciona skills bubble-graph e design-lego-project

agents/reversa-bubble-graph/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: reversa-bubble-graph
+description: Gera um mapa visual da arquitetura de um sistema (Bubble Graph em Mermaid) focado em Coesão, Acoplamento e Encapsulamento, complementado por um Diagnóstico de Saúde do Software.
+---
+
+# Skill: Reversa Bubble Graph & Diagnóstico de Saúde
+
+## Propósito
+Atuar como uma extensão analítica de alto nível (compatível com o framework **Reversa**) para mapear a saúde arquitetural de um software. Por meio de análise estática e inspeção de dependências, o agente deve gerar um grafo visual (Bubble Graph) utilizando Mermaid.js e apresentar um diagnóstico técnico focado no acoplamento, modularidade e encapsulamento dos módulos do projeto, de forma retroativa (comparando versões) e progressiva (sugerindo próximos passos).
+
+## Entradas (Inputs)
+- **Árvore de Diretórios e Arquivos (Tree)** do projeto alvo.
+- **Trechos Críticos de Código** ou definições de dependência (`import`, `require`, `include`).
+- **Contexto Opcional:** Versão anterior da arquitetura (para análise retroativa/evolutiva).
+
+## Pipeline de Análise (Workflow)
+1. **Mapeamento de Domínios:** Identificar agrupamentos lógicos de responsabilidade (Core, UI, Dados, Integração, Infraestrutura).
+2. **Medição Heurística de Saúde:**
+   - **Coesão:** O módulo, classe ou arquivo possui responsabilidade única?
+   - **Acoplamento:** Qual o número de conexões (inbound/outbound) do módulo? Existem dependências circulares?
+   - **Encapsulamento:** As regras de negócio estão vazando para a UI ou para o Banco de Dados?
+3. **Modelagem do Bubble Graph (Mermaid):** Construir o diagrama focando nas interfaces dos componentes (ocultando detalhes granulares para manter clareza).
+4. **Relatório de Diagnóstico:** Redigir a "Análise Dinâmica", apontando os "God Objects" (classes gigantes centralizadoras de dependências) e avaliando a evolução arquitetural.
+
+## Estrutura de Saída (Output)
+A skill deve exportar obrigatoriamente um arquivo (ex: `0X_bubble_graph.md`) no diretório `_reversa_sdd/`, contendo a estrutura abaixo:
+
+```markdown
+# 🫧 Bubble Graph & Diagnóstico de Saúde
+
+Este documento apresenta o panorama arquitetural atual do sistema e a saúde de suas dependências.
+
+## Mapa Arquitetural
+
+\`\`\`mermaid
+graph TD
+    %% Hub e Nós Centrais
+    AppCore[Core Application<br>Regras Normativas]:::core
+
+    %% Camadas Lógicas
+    subgraph UI [Camada de Apresentação]
+        Frontend[Views & Componentes]:::ui
+    end
+
+    subgraph Data [Persistência]
+        DB[(Database)]:::data
+        Repos[Repositories]:::data
+    end
+
+    %% Relacionamentos (Carga de Acoplamento)
+    UI --> AppCore
+    AppCore --> Repos
+    Repos --> DB
+
+    %% Paleta de Cores baseada em Domínio/Criticidade
+    classDef core fill:#b87333,stroke:#333,stroke-width:2px,color:#fff;
+    classDef ui fill:#1c2128,stroke:#e3b341,stroke-width:2px,color:#e6edf3;
+    classDef data fill:#2a3140,stroke:#da3633,stroke-width:1px,color:#fff;
+\`\`\`
+
+## 📊 Diagnóstico de Saúde do Software
+
+### 1. Nível de Encapsulamento & Modularidade
+- **Isolamento Positivo:** [Identificar módulos que estão bem delimitados, com fronteiras estritas].
+- **Fissuras Arquiteturais:** [Explicitar locais onde o encapsulamento quebra, ex: DTOs do banco sendo usados diretamente na UI].
+
+### 2. Acoplamento & Pontos de Fricção (God Objects)
+- **Gargalos de Dependência:** [Apontar o nó do Bubble Graph que recebe ou envia mais setas. Avaliar se ele é um "God Object"].
+- **Dependências Cíclicas:** [Descrever eventuais laços fechados de acoplamento entre módulos].
+
+### 3. Análise Retroativa & Vetor de Evolução
+- **Antes vs. Agora:** [Descrever o que melhorou ou piorou em relação à arquitetura anterior. O sistema fragmentou responsabilidades? Diminuiu a carga do nó central?]
+- **Prescrição de Refatoração:** [Listar 2 a 3 metas de engenharia recomendadas para a próxima iteração, baseadas nos princípios SOLID e Clean Architecture].
+```
+
+## Regras Inegociáveis (Guardrails)
+1. **Sintaxe Segura:** O código Mermaid deve ser escrito de forma robusta. É **estritamente proibido** usar caracteres especiais como parênteses `()` ou colchetes `[]` nos identificadores dos nós, devendo usá-los apenas nos rótulos de texto (labels).
+2. **Natureza Analítica:** O diagnóstico NÃO PODE apenas narrar o diagrama. Ele DEVE fornecer um juízo de valor arquitetural, identificando sintomas (ex: "alta fragilidade em `Módulo X` devido a forte acoplamento").
+3. **Escopo Operacional:** O agente não deve alterar o código-fonte base da aplicação ao rodar esta skill. Seu papel é observacional, analítico e de geração de relatórios de Design de Software.

agents/reversa-design-lego-project/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: product-design-lego-blocks
+description: Orchestrates a progressive product design workflow from an initial seed idea (goal, target audience, starting point) to a consolidated project, adding and connecting features as Lego blocks. Use when the user wants to evolve a product concept into a structured, traceable project before coding.
+---
+
+# Purpose
+
+This skill helps you:
+- Start from a **seed idea** (objective, target audience, starting point).
+- Grow the project **progressively**, adding one feature block at a time.
+- Keep every decision **explicitly recorded, connected, and debatable**.
+- Output a **final project blueprint** (components, modules, rules, dependencies) that can be passed to implementation agents.
+
+# When to use
+
+Use this skill when:
+- The user gives a **seed idea** and wants to “grow” the product organically.
+- The user says “add another feature”, “add a module”, “change this part”, or “refactor this block”.
+- The user wants a **retro‑active log** of how the design evolved (what was added, why, and what was removed).
+
+# Inputs you expect
+
+Ask the user for:
+1. **Objective**:  
+   - What problem are we solving?  
+   - What is the main outcome the user wants?
+2. **Target audience**:  
+   - Who is the user of this product?  
+   - Where they are coming from (profile, context, constraints)?
+3. **Starting point**:  
+   - What already exists? (existing code, API, UI, docs, etc.)
+   - Or: “blank slate” if nothing exists yet.
+
+If any of these is missing, ask the user to clarify before proceeding.
+
+# Workflow: “Lego‑Blocks” progressive design
+
+Do this **step by step**, saving each step in a central log (e.g., `design-log.md` or `project-knowledge/`).
+
+1. **Step 1 – Seed framing**
+   - Convert the seed idea into:
+     - A **mission statement** (1–2 sentences).
+     - A **core job‑to‑be‑done** (what the user *really* wants to accomplish).
+   - Output:
+     - A short “Project Seed” document with:
+       - Objective
+       - Target audience
+       - Starting point
+       - Initial constraints (time, tech stack, budget, etc.)
+
+2. **Step 2 – Block inventory**
+   - Propose a **first set of minimal blocks** (features, modules, components) that together cover:
+     - Core user flow.
+     - Minimum viable product (MVP) boundaries.
+   - For each block:
+     - Name
+     - Purpose
+     - Inputs / outputs
+     - Dependencies (if any)
+   - Ask the user:
+     - “Do you want to:
+       - add, remove, or refactor a block?”
+       - “Connect this block to another (create a dependency)?”
+       - “Debate this block’s design (pros/cons, alternatives)?”
+
+3. **Step 3 – Retro‑active logging**
+   - After every interaction:
+     - Append a **log entry** to a central file, e.g.:
+       - Date + version
+       - What changed (which block added/removed/refactored)
+       - Why (user’s reason, constraints, or trade‑off)
+       - What was kept / what was removed
+   - Suggest a **graph‑like structure**:
+     - “Block A → Block B” (dependency)
+     - “Block X was deprecated in favor of Block Y”
+
+4. **Step 4 – Progressive debates**
+   - For each block the user wants to “lock” or “ship”:
+     - Run a mini‑debate:
+       - Pros
+       - Cons
+       - Risks
+       - Alternatives
+     - Record the decision:
+       - “Approved as is”, “Approved with constraints”, or “Rejected / postponed”.
+   - Keep a **decision matrix** (even if simple) to show:
+     - Which blocks are “committed”, “exploratory”, or “blocked”.
+
+5. **Step 5 – Final project blueprint**
+   - When the user says “I’m done designing”, compile:
+     - A **map of all blocks** (like a bubble graph of modules):
+       - Nodes: blocks / modules
+       - Edges: dependencies
+       - Color/status: “implemented”, “design”, “deprecated”
+     - A **health‑style diagnosis**:
+       - Cohesion (how well each block has a single concern)
+       - Coupling (how many other blocks it depends on)
+       - Completeness (what is missing to reach the mission)
+     - A **timeline**:
+       - What can be built now (MVP)
+       - What can be added later (progressive features)
+
+# Output format
+
+Always structure the final output as:
+
+- **1. Project Seed**
+  - Objective
+  - Target audience
+  - Starting point
+- **2. Block map**
+  - List of blocks (name, purpose, status)
+  - Dependency graph (text or structured data)
+- **3. Evolution log**
+  - Chronological list of changes
+  - Key decisions and trade‑offs
+- **4. Health‑style diagnosis**
+  - Cohesion score per block (high/medium/low)
+  - Coupling score per block (high/medium/low)
+  - Overall project “design health” (green/yellow/red)
+
+If the user subsequently wants to **implement**, hand this blueprint to:
+- A **code_architect** skill
+- A **db_designer** skill
+- Or a **feature_to_code** skill (your own encapsulation/análise skills).
+
+# Constraints and guardrails
+
+- Do not invent implementation details too early; keep blocks **abstract** until the user says “lock this design”.
+- If the user wants to change a block that is already “locked”:
+  - Ask: “Is this a refactor or a new variation?”
+  - Track the **old block** explicitly as “deprecated” with a reason.
+- If the user wants to simulate a **retro‑analysis** of the project growth:
+  - Walk through the log and:
+    - Show the “before” vs “after” block set.
+    - Show how cohesion and coupling changed over time (like your bubble‑graph).