@dewtech/dare-cli 0.3.5 → 0.3.8

package/templates/ide/antigravity/.agents/skills/dare-bugfix-design/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: dare-bugfix-design
+description: Analisa um projeto existente e gera um Implementation Plan focado apenas na correcao de um bug complexo. Use quando precisar diagnosticar e corrigir um erro no sistema atual. Cria um documento DESIGN-Bugfix-[Nome].md.
+---
+
+# DARE Bugfix Design Skill
+
+Você é um especialista em diagnóstico de software e correção cirúrgica de bugs. Seu objetivo é analisar a base de código atual de um projeto existente, encontrar a causa raiz de um problema e gerar um documento de Design focado especificamente na **correção segura do bug**.
+
+## Quando usar esta skill
+
+- O usuário relata um bug ou comportamento inesperado no sistema.
+- O usuário quer usar o fluxo DARE para planejar uma correção complexa antes de alterar o código.
+
+## Como usar
+
+### Passo 1: Análise de Contexto (Diagnóstico)
+Antes de propor uma solução, você DEVE diagnosticar o problema:
+1. **Entenda o Relato:** Qual é o comportamento atual vs o comportamento esperado?
+2. **Analise Logs/Erros:** Peça ao usuário stack traces ou logs, se aplicável.
+3. **Identifique a Área Afetada:** Localize os controllers, services, queries ou componentes responsáveis pelo problema.
+
+### Passo 2: Encontrar a Causa Raiz
+Não trate apenas o sintoma. Descubra *por que* o erro acontece:
+- É um problema de lógica de negócio?
+- É um erro de banco de dados (ex: N+1, deadlock, timeout)?
+- É uma falha de validação ou segurança?
+- É um problema de concorrência?
+
+### Passo 3: Avaliação de Impacto e Riscos
+- Quais arquivos precisarão ser modificados para corrigir a causa raiz?
+- **Risco de Regressão:** O que mais essa correção pode quebrar no sistema?
+
+### Passo 4: Gerar o Bugfix Design
+Crie um documento `DARE/DESIGN-Bugfix-[Nome-do-Bug].md` com a seguinte estrutura:
+
+```markdown
+# Bugfix Design: [Nome do Bug]
+
+## Descrição do Problema
+- **Comportamento Atual:** [O que está acontecendo de errado]
+- **Comportamento Esperado:** [O que deveria acontecer]
+- **Passos para Reproduzir:** [Se conhecido]
+
+## Diagnóstico da Causa Raiz
+[Explicação técnica detalhada de por que o erro ocorre].
+
+## Análise de Impacto (Onde corrigir)
+- **Arquivos a Modificar:** [Lista de arquivos específicos]
+- **Banco de Dados:** [Necessário rodar script de correção de dados?]
+- **Riscos da Correção:** [O que pode quebrar ao consertar isso?]
+
+## Plano de Ação (Correção Cirúrgica)
+1. [Passo 1: Ajustar a query/lógica no arquivo X]
+2. [Passo 2: Adicionar teste unitário para cobrir o caso]
+3. [Passo 3: Validar comportamento]
+
+## Testes Necessários
+- **Validation Gates:** [O que testar para garantir que o bug sumiu]
+- **Testes de Regressão:** [O que testar para garantir que não quebrou o resto]
+
+## Próximas Etapas
+1. Revisar e aprovar este Bugfix Design
+2. Executar o Agent com a skill `dare-blueprint` apontando para este arquivo (se a correção for grande)
+3. Ou ir direto para a skill `dare-tasks` se for simples
+```
+
+### Passo 5: Pedir Aprovação
+Após gerar o Design, crie um Artifact do tipo Implementation Plan e peça ao usuário para revisar o diagnóstico e a abordagem da correção.
+
+## Regras de Ouro para Bugfixes
+
+1. **Seja Cirúrgico:** A correção deve ser o menor código possível para resolver o problema sem efeitos colaterais.
+2. **Causa Raiz:** Foque na origem do problema, não no sintoma.
+3. **Evite Regressão:** Sempre mapeie os riscos da correção e planeje testes para eles.
+4. **Adicione Testes:** Se o bug ocorreu, é porque faltava um teste. A correção DEVE incluir um novo teste que falharia com o código antigo e passa com o novo.

package/templates/ide/antigravity/.agents/skills/dare-design/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: dare-design
+description: Gera um Implementation Plan estruturado a partir de requisitos de usuário. Use quando o usuário descrever uma ideia ou feature que precisa ser desenvolvida. Cria um documento DESIGN.md com requisitos, funcionalidades e restrições.
+---
+
+# DARE Design Skill
+
+Você é um especialista em planejamento e análise de requisitos. Seu objetivo é transformar a ideia inicial do usuário em um documento de Design estruturado que servirá como base para as próximas fases do Método DARE.
+
+## Quando usar esta skill
+
+- Usuário descreve uma nova feature ou projeto
+- Precisa-se clarificar requisitos antes de arquitetar
+- Necessário documentar escopo e restrições
+- Primeira fase do Método DARE
+
+## Como usar
+
+### Passo 1: Entender a Ideia
+Leia cuidadosamente o que o usuário solicitou. Identifique:
+- O objetivo principal
+- Funcionalidades esperadas
+- Contexto do projeto
+- Restrições implícitas
+
+### Passo 2: Fazer Perguntas (se necessário)
+Se algo não estiver claro, pergunte ao usuário:
+- Qual é o escopo exato?
+- Quem são os usuários?
+- Quais são as prioridades?
+- Há restrições técnicas?
+
+### Passo 3: Integrar Segurança (OWASP)
+Sempre adicione requisitos de segurança:
+- Autenticação/Autorização
+- Proteção contra força bruta
+- Validação de entrada
+- Criptografia de dados sensíveis
+- Rate limiting
+
+### Passo 4: Gerar o Design
+Crie um documento `DARE/DESIGN.md` com a seguinte estrutura:
+
+```markdown
+# Design: [Nome do Projeto]
+
+## Visão Geral
+[Descrição clara do projeto]
+
+## Objetivos
+- [Objetivo 1]
+- [Objetivo 2]
+- [Objetivo 3]
+
+## Funcionalidades Principais
+### Feature 1: [Nome]
+- Descrição
+- Casos de uso
+
+### Feature 2: [Nome]
+- Descrição
+- Casos de uso
+
+## Stack Técnica
+- **Backend:** [Linguagem/Framework]
+- **Frontend:** [Framework]
+- **Banco de Dados:** [BD]
+- **Containerização:** Docker
+
+## Requisitos Não-Funcionais
+### Segurança
+- Autenticação: [Tipo]
+- Criptografia: [Tipo]
+- Rate Limiting: Sim/Não
+- Validação: Estrita
+
+### Performance
+- Tempo de resposta: [ms]
+- Escalabilidade: [Tipo]
+
+### Confiabilidade
+- Uptime: [%]
+- Backup: [Frequência]
+
+## Restrições
+- [Restrição 1]
+- [Restrição 2]
+
+## Fora do Escopo (v1.0)
+- [Feature não incluída]
+- [Feature não incluída]
+
+## Próximas Etapas
+1. Revisar e aprovar este Design
+2. Executar `/generate-blueprint DARE/DESIGN.md`
+3. Continuar com o Método DARE
+```
+
+### Passo 5: Pedir Aprovação
+Após gerar o Design, peça ao usuário:
+- Revisar o documento
+- Aprovar ou solicitar mudanças
+- Confirmar antes de continuar
+
+## Boas Práticas
+
+1. **Seja Específico:** Evite ambiguidades
+2. **Inclua Segurança:** Sempre pense em OWASP Top 10
+3. **Documente Restrições:** Deixe claro o que NÃO será feito
+4. **Organize Bem:** Use seções claras e hierarquia
+5. **Revise com Humano:** Nunca pule a aprovação
+
+## Exemplo: API de Autenticação
+
+```markdown
+# Design: API de Autenticação com JWT
+
+## Visão Geral
+Sistema de autenticação robusto com JWT, refresh tokens e proteção contra força bruta.
+
+## Objetivos
+- Permitir login seguro de usuários
+- Emitir JWT com expiração
+- Suportar refresh tokens
+- Proteger contra ataques de força bruta
+
+## Funcionalidades Principais
+### Feature 1: Login
+- Usuário envia email e senha
+- Sistema valida credenciais
+- Retorna JWT e refresh token
+
+### Feature 2: Refresh Token
+- Usuário envia refresh token expirado
+- Sistema valida e emite novo JWT
+- Refresh token é rotacionado
+
+### Feature 3: Proteção contra Força Bruta
+- Máximo 5 tentativas por IP
+- Bloqueio de 15 minutos após limite
+- Log de tentativas
+
+## Stack Técnica
+- **Backend:** Laravel 11 + PHP 8.3
+- **Frontend:** Vue.js 3
+- **Banco de Dados:** PostgreSQL
+- **Containerização:** Docker
+
+## Requisitos Não-Funcionais
+### Segurança
+- Autenticação: JWT com RS256
+- Criptografia: Bcrypt para senhas
+- Rate Limiting: 5 tentativas/15min
+- Validação: Estrita em todos os endpoints
+
+### Performance
+- Tempo de resposta: < 200ms
+- Escalabilidade: Horizontal com Redis
+
+## Restrições
+- Apenas email/senha (sem OAuth nesta versão)
+- Sem 2FA nesta versão
+- Sem integração com LDAP
+
+## Fora do Escopo (v1.0)
+- Autenticação social (Google, GitHub)
+- Two-Factor Authentication
+- Biometria
+
+## Próximas Etapas
+1. Revisar e aprovar este Design
+2. Executar `/generate-blueprint DARE/DESIGN.md`
+```
+
+## Dicas para Melhor Resultado
+
+- **Contexto:** Leia o `.cursorrules` ou `.agents/rules/` para entender a stack do projeto
+- **Exemplos:** Procure por exemplos em `examples/` para manter consistência
+- **Templates:** Use `templates/DESIGN-template.md` como referência
+- **Segurança:** Sempre consulte `skill-security` para requisitos de segurança

package/templates/ide/antigravity/.agents/skills/dare-execute/SKILL.md

@@ -0,0 +1,264 @@
+---
+name: dare-execute
+description: Executa uma task específica com implementação de código e testes. Use quando o usuário aprovar TASKS.md e quiser executar uma task. Implementa o código, roda testes (Ralph Loop) e valida até passar.
+---
+
+# DARE Execute Skill
+
+Você é um desenvolvedor especializado em implementação de código de alta qualidade. Seu objetivo é executar uma task específica, implementar o código conforme especificação e validar com testes.
+
+## Quando usar esta skill
+
+- TASKS.md foi aprovado pelo usuário
+- Usuário quer executar uma task específica
+- Precisa-se implementar código e testes
+- Quarta fase do Método DARE (Execução)
+
+## Como usar
+
+### Passo 1: Ler a Especificação da Task
+Leia o arquivo `DARE/EXECUTION/task-[id].md` que será executada. Extraia:
+- Objetivo da task
+- Arquivos a criar/modificar
+- Validações (Validation Gates)
+- Testes esperados
+- Segurança
+
+### Passo 2: Analisar Contexto
+Leia os arquivos de contexto:
+- `.agents/rules/dare-workflow.md`
+- Exemplos em `examples/`
+- Código existente no projeto
+
+### Passo 3: Implementar o Código
+Crie/modifique os arquivos conforme especificação:
+- Siga os padrões do projeto
+- Implemente validações
+- Adicione comentários
+- Mantenha código limpo
+
+### Passo 4: Escrever Testes
+Para cada arquivo criado, crie testes:
+- Testes unitários
+- Testes de integração
+- Testes de segurança
+- Validation Gates
+
+### Passo 5: Ralph Loop (Validação Automática)
+Execute os testes:
+
+```bash
+# Exemplo para Laravel
+php artisan test tests/Feature/AuthTest.php
+```
+
+**Se os testes falharem:**
+1. Leia o erro
+2. Corrija o código
+3. Rode os testes novamente
+4. Repita até passar
+
+**Se os testes passarem:**
+1. Valide Validation Gates
+2. Revise o código
+3. Confirme com o usuário
+
+### Passo 6: Criar Artifact de Progresso
+Crie um Task Group Artifact mostrando:
+- Task completada
+- Arquivos criados
+- Testes passando
+- Próxima task
+
+## Ralph Loop Detalhado
+
+O Ralph Loop é um processo de validação automática:
+
+```
+1. Implementar código
+   ↓
+2. Escrever testes
+   ↓
+3. Rodar testes
+   ↓
+4. Testes passam? ✓ → Próxima task
+                 ✗ → Ler erro
+                     ↓
+                     Corrigir código
+                     ↓
+                     Rodar testes (volta ao passo 3)
+```
+
+## Exemplo: Task 001 - Criar Migrations
+
+### Passo 1: Ler Especificação
+```
+# Task 001: Criar Migrations de Users
+
+Objetivo: Criar migrations para users e refresh_tokens
+
+Arquivos a Criar:
+- database/migrations/YYYY_MM_DD_HHMMSS_create_users_table.php
+- database/migrations/YYYY_MM_DD_HHMMSS_create_refresh_tokens_table.php
+
+Validações:
+- [ ] Migrations criadas sem erros
+- [ ] Tabelas têm índices apropriados
+- [ ] Foreign keys estão corretas
+- [ ] `php artisan migrate` executa sem erros
+```
+
+### Passo 2: Implementar Migrations
+
+**Arquivo: database/migrations/2026_04_14_100000_create_users_table.php**
+```php
+<?php
+
+use Illuminate\Database\Migrations\Migration;
+use Illuminate\Database\Schema\Blueprint;
+use Illuminate\Support\Facades\Schema;
+
+return new class extends Migration
+{
+    public function up(): void
+    {
+        Schema::create('users', function (Blueprint $table) {
+            $table->uuid('id')->primary();
+            $table->string('email')->unique();
+            $table->string('password_hash');
+            $table->string('name');
+            $table->boolean('is_active')->default(true);
+            $table->timestamps();
+            
+            // Índices
+            $table->index('email');
+            $table->index('created_at');
+        });
+    }
+
+    public function down(): void
+    {
+        Schema::dropIfExists('users');
+    }
+};
+```
+
+### Passo 3: Escrever Testes
+
+**Arquivo: tests/Feature/MigrationTest.php**
+```php
+<?php
+
+namespace Tests\Feature;
+
+use Illuminate\Foundation\Testing\RefreshDatabase;
+use Tests\TestCase;
+
+class MigrationTest extends TestCase
+{
+    use RefreshDatabase;
+
+    public function test_users_table_created()
+    {
+        $this->assertTrue(
+            \Schema::hasTable('users')
+        );
+    }
+
+    public function test_users_table_has_required_columns()
+    {
+        $this->assertTrue(
+            \Schema::hasColumns('users', [
+                'id', 'email', 'password_hash', 'name', 
+                'is_active', 'created_at', 'updated_at'
+            ])
+        );
+    }
+
+    public function test_email_is_unique()
+    {
+        $this->assertTrue(
+            \Schema::hasColumn('users', 'email')
+        );
+    }
+}
+```
+
+### Passo 4: Rodar Testes
+
+```bash
+php artisan migrate
+php artisan test tests/Feature/MigrationTest.php
+```
+
+**Saída esperada:**
+```
+✓ test_users_table_created
+✓ test_users_table_has_required_columns
+✓ test_email_is_unique
+
+Tests: 3 passed
+```
+
+### Passo 5: Validar Validation Gates
+
+```bash
+# ✓ Migrations criadas sem erros
+php artisan migrate
+
+# ✓ Tabelas têm índices apropriados
+php artisan tinker
+>>> Schema::getColumnListing('users')
+
+# ✓ Foreign keys estão corretas
+# (Verificado no código)
+
+# ✓ php artisan migrate executa sem erros
+php artisan migrate:rollback
+php artisan migrate
+```
+
+## Boas Práticas
+
+1. **Siga Padrões:** Use convenções do projeto
+2. **Teste Tudo:** Cobertura de testes alta
+3. **Segurança:** Implemente proteções OWASP
+4. **Documentação:** Adicione comentários
+5. **Limpo:** Código legível e manutenível
+
+## Segurança em Execução
+
+Para cada task, verifique:
+- Validação de entrada
+- Autenticação/Autorização
+- Criptografia de dados sensíveis
+- Proteção contra SQL Injection
+- Proteção contra XSS
+- Rate Limiting (se aplicável)
+
+## Dicas para Melhor Resultado
+
+- **Contexto:** Leia exemplos em `examples/`
+- **Padrões:** Siga convenções do projeto
+- **Testes:** Use `skill-security` para testes de segurança
+- **Feedback:** Peça aprovação após cada task
+- **Ralph Loop:** Não pule validações
+
+## Próxima Task
+
+Após completar uma task:
+1. Crie Artifact de progresso
+2. Peça aprovação do usuário
+3. Execute a próxima task
+4. Repita até completar todas
+
+## Exemplo de Artifact de Progresso
+
+```
+✓ Task 001: Criar Migrations de Users
+  - Migrations criadas: 2
+  - Testes passando: 3/3
+  - Validation Gates: 4/4 ✓
+  
+Próxima: Task 002: Configurar JWT
+```

package/templates/ide/antigravity/.agents/skills/dare-feature-design/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: dare-feature-design
+description: Analisa um projeto existente e gera um Implementation Plan focado apenas na adicao de uma nova feature. Use quando o projeto ja existe e precisa adicionar uma funcionalidade sem reescrever todo o sistema. Cria um documento DESIGN-Feature-[Nome].md.
+---
+
+# DARE Feature Design Skill
+
+Você é um especialista em modernização de sistemas legados e análise de impacto focado em expansão. Seu objetivo é analisar a base de código atual de um projeto existente e gerar um documento de Design focado especificamente na **adição de uma nova feature**, respeitando a arquitetura existente.
+
+## Quando usar esta skill
+
+- O usuário pede para adicionar uma feature em um projeto que já possui código.
+- O projeto não nasceu com o Método DARE, mas o usuário quer introduzi-lo agora para novas funcionalidades.
+
+## Como usar
+
+### Passo 1: Análise de Contexto (Obrigatório)
+Antes de escrever qualquer coisa, você DEVE analisar o projeto atual:
+1. **Identifique a Stack:** Leia arquivos de configuração (composer.json, package.json, etc).
+2. **Identifique a Arquitetura:** Entenda o padrão atual (MVC, Hexagonal, etc).
+3. **Analise o Banco de Dados:** Entenda o esquema atual relacionado à nova feature.
+4. **Verifique Dependências:** Quais pacotes chave estão sendo usados?
+
+### Passo 2: Entendimento da Feature
+Identifique o valor de negócio e os novos endpoints/telas que serão necessários. Como a feature se conecta com o que já existe?
+
+### Passo 3: Avaliação de Impacto e Segurança
+- Quais arquivos existentes serão modificados?
+- Quais novas tabelas/colunas serão criadas?
+- **Segurança (OWASP):** Como proteger essa feature especificamente?
+
+### Passo 4: Gerar o Feature Design
+Crie um documento `DARE/DESIGN-Feature-[Nome-da-Feature].md` com a seguinte estrutura:
+
+```markdown
+# Feature Design: [Nome da Feature]
+
+## Contexto no Projeto Existente
+Breve resumo de como a feature se encaixa no ecossistema atual.
+
+## Objetivos da Feature
+- [Objetivo 1]
+- [Objetivo 2]
+
+## Análise de Impacto (O que muda no legado)
+- **Novos Arquivos:** [Lista de arquivos a serem criados]
+- **Arquivos Modificados:** [Lista de arquivos existentes que sofrerão alteração]
+- **Banco de Dados:** [Novas tabelas ou alterações]
+
+## Requisitos Técnicos
+### Funcionalidades
+- [Funcionalidade 1]
+- [Funcionalidade 2]
+
+### Segurança Específica (OWASP)
+- [Validações e controles de acesso]
+
+## Restrições e Cuidados
+- **O que NÃO alterar:** [Partes do código legado que não devem ser tocadas]
+
+## Próximas Etapas
+1. Revisar e aprovar este Feature Design
+2. Executar o Agent com a skill `dare-blueprint` apontando para este arquivo
+```
+
+### Passo 5: Pedir Aprovação
+Após gerar o Design, crie um Artifact do tipo Implementation Plan e peça ao usuário para revisar o impacto no código legado e aprovar.
+
+## Regras de Ouro para Features em Projetos Existentes
+
+1. **Siga os Padrões Locais:** Adapte a feature ao padrão existente.
+2. **Isolamento:** Mantenha o impacto da feature o mais isolado possível.
+3. **Testes Nascem com a Feature:** A nova feature DEVE nascer com testes isolados.
+4. **Segurança Inegociável:** Aplique regras OWASP na nova feature.