@dewtech/dare-cli 2.16.0 → 3.0.0

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

@@ -1,224 +1,265 @@
----
-name: dare-tasks
-description: Decompõe o BLUEPRINT aprovado em tasks atômicas e gera os 3 artefatos da fase de execução do DARE (TASKS.md, dare-dag.yaml, EXECUTION/task-*.md). Use quando o usuário aprovar o BLUEPRINT.md. A construção do grafo segue rigorosamente a skill dare-dag-runner.
----
-
-# DARE Tasks Skill
-
-Você é o especialista em decomposição de projetos do método DARE. Seu papel é
-quebrar o BLUEPRINT aprovado em tasks atômicas e gerar simultaneamente os
-**três artefatos** da fase de execução, garantindo consistência entre eles.
-
-## Quando usar esta skill
-
-- BLUEPRINT.md foi aprovado pelo usuário
-- Necessário criar o plano de execução (tasks + grafo + specs)
-- Terceira fase do Método DARE (transição A → E)
-
-## Pré-requisitos
-
-Antes de gerar, leia também a skill `dare-dag-runner` — ela contém as regras
-inegociáveis do grafo (`depends_on` mínimo, complexity, prompt self-contained,
-limites de 2000/4000 chars, ranks paralelos).
-
-## Os 3 artefatos sempre juntos
-
-| Arquivo | Para quê | Lido por |
-|---------|----------|----------|
-| `DARE/TASKS.md` | Visão humana com tabela e progresso | Humano |
-| `DARE/dare-dag.yaml` | Grafo executável | CLI `dare execute` |
-| `DARE/EXECUTION/task-<id>.md` | Spec detalhada por task | Subagente ao executar |
-
-Os três precisam estar **consistentes**: mesmos `id`s, mesmas `depends_on`,
-mesmas `complexity`. Inconsistência aqui quebra a execução.
-
-## Como usar
-
-### Passo 1: Ler o BLUEPRINT aprovado
-
-Leia `DARE/BLUEPRINT.md`. Extraia:
-- Fases do plano de execução
-- Endpoints, modelos de dados, schemas
-- Estrutura de diretórios
-- Decisões arquiteturais
-- Estratégia de testes
-
-### Passo 2: Decompor em tasks atômicas
-
-Cada task deve:
-- Ser pequena o suficiente para uma conversa única (15–60 min de trabalho)
-- Ter dependências reais e mínimas (não falsas)
-- Ser testável isoladamente
-- Incluir validações de segurança apropriadas
-- Ter `complexity` honesta (LOW/MED/HIGH)
-
-### Passo 3: Gerar `DARE/TASKS.md` (visão humana)
-
-```markdown
-# Tasks: [Nome do Projeto]
-
-## Visão Geral
-- Total de Tasks: [N]
-- Ranks paralelos: [N]
-- Tempo estimado: [horas]
-
-## Tabela de Status
-
-| ID       | Título                      | Status      | Depends On       | Complexity |
-|----------|-----------------------------|-------------|------------------|------------|
-| task-001 | Setup project structure     | ⏳ PENDING  | —                | LOW        |
-| task-002 | DB migrations               | ⏳ PENDING  | —                | MED        |
-| task-003 | Auth controllers            | ⏳ PENDING  | task-001, 002    | HIGH       |
-| ...      | ...                         | ...         | ...              | ...        |
-
-## Tarefas por Fase
-
-### Phase 1: Setup
-- task-001: Setup project structure
-- task-002: DB migrations
-
-### Phase 2: Auth
-- task-003: Auth controllers (deps: 001, 002)
-- ...
-
-## Próximas Etapas
-1. Revisar e aprovar este TASKS.md
-2. Executar paralelo: `dare execute --parallel`
-3. Ou task isolada: `/dare-execute task-001`
-```
-
-### Passo 4: Gerar `DARE/dare-dag.yaml` (grafo executável)
-
-Schema canônico:
-
-```yaml
-title: "[Nome do Projeto] - Development Tasks"
-version: "1.0.0"
-
-limits:
-  parent_context_chars: 2000
-  task_output_chars: 4000
-  timeout_seconds: 600
-
-models:
-  cursor:      { HIGH: gpt-5.3-codex,     MED: composer-2,       LOW: auto-low }
-  claude:      { HIGH: claude-sonnet-4-5, MED: claude-haiku-4,   LOW: claude-haiku-4 }
-  antigravity: { HIGH: gemini-2.5-pro,    MED: gemini-2.5-flash, LOW: gemini-2.5-flash }
-
-tasks:
-  - id: task-001
-    title: "Setup project structure"
-    depends_on: []
-    complexity: LOW
-    spec_file: EXECUTION/task-001.md
-    subtask_prompt: |
-      Setup base project structure following DARE/BLUEPRINT.md.
-      Create directories, initialize package files. No business logic yet.
-      Validation gate: project builds.
-
-  - id: task-002
-    title: "DB migrations"
-    depends_on: []
-    complexity: MED
-    spec_file: EXECUTION/task-002.md
-    subtask_prompt: |
-      Create migrations for users and refresh_tokens tables per BLUEPRINT.
-      Include indexes and FKs. Validation gate: migrate runs cleanly.
-```
-
-**Regras inegociáveis (da skill dare-dag-runner):**
-- `id` em kebab-case e único
-- `depends_on` mínimo — só quando filha **literalmente** precisa do output
-- `subtask_prompt` self-contained (subagente recebe só ele + 2000 chars de pais)
-- Pelo menos 2 tasks no rank 0 (`depends_on: []`)
-- Cadeia linear é antipattern — reveja
-
-### Passo 5: Gerar `DARE/EXECUTION/task-<id>.md` (specs detalhadas)
-
-Para CADA task no YAML, crie a spec usando `templates/TASK-SPEC-template.md`:
-
-```markdown
-# Task 001: Setup project structure
-
-## Objetivo
-Criar a estrutura base do projeto seguindo o BLUEPRINT.
-
-## Descrição
-Inicializar diretórios, package files e configuração mínima.
-Sem lógica de negócio — apenas scaffolding.
-
-## Arquivos a Criar
-- `src/` (diretório)
-- `tests/` (diretório)
-- `package.json` (ou equivalente da stack)
-- `.gitignore`
-
-## Validation Gates
-- [ ] Estrutura criada
-- [ ] Build passa sem erros
-- [ ] Lint sem warnings
-- [ ] `package.json` (ou Cargo.toml, composer.json) válido
-
-## Testes
-```bash
-npm run build    # ou cargo build, composer install, etc.
-```
-
-## Segurança
-- `.env` no `.gitignore`
-- Nenhum secret commitado
-
-## Próxima Task
-Task 002: DB migrations
-```
-
-### Passo 6: Validar consistência
-
-Antes de entregar, confirme:
-- [ ] Mesmos `id`s em `TASKS.md`, `dare-dag.yaml` e `EXECUTION/task-*.md`
-- [ ] Mesmas `depends_on` nos três
-- [ ] Mesmas `complexity`
-- [ ] Sem ciclos no grafo
-- [ ] Pelo menos 2 tasks no rank 0
-- [ ] Cada `subtask_prompt` é executável sem contexto adicional
-
-### Passo 7: Regenerar a visualização do DAG
-
-Depois de salvar o `dare-dag.yaml`, rode:
-
-```bash
-dare dag viz -o DARE/dag-graph.mmd
-```
-
-Isso reescreve `DARE/dag-graph.mmd` (Mermaid) refletindo o grafo atualizado.
-O usuário pode abrir o arquivo no Antigravity para visualizar o grafo
-estático com cores por status antes de executar.
-
-### Passo 8: Pedir aprovação
-
-> Gerados os 4 artefatos da fase de execução:
-> - `DARE/TASKS.md` ([N] tasks)
-> - `DARE/dare-dag.yaml` ([N] ranks paralelos)
-> - `DARE/EXECUTION/task-*.md` ([N] specs)
-> - `DARE/dag-graph.mmd` (visualização Mermaid do DAG)
->
-> Revise (abra `dag-graph.mmd` para ver o grafo). Quando aprovar:
-> `dare execute --next` para iniciar a execução.
-
-## Boas práticas
-
-1. **Atômicas:** cada task é independente o suficiente para uma conversa
-2. **Testáveis:** validation gates específicos da stack
-3. **Documentadas:** specs claras e auto-contidas
-4. **Seguras:** integre OWASP nos pontos sensíveis
-5. **Paralelizáveis:** maximize rank 0; minimize cadeias lineares
-
-## Erros comuns a evitar
-
-| Erro | Como corrigir |
-|------|---------------|
-| Cadeia linear `001→002→003→...` | Adicione paralelismo onde a dependência é falsa |
-| `subtask_prompt` referenciando "como combinamos" | Coloque tudo no prompt explicitamente |
-| Tudo em `complexity: HIGH` | Avalie honestamente — HIGH só para lógica crítica |
-| `id` duplicado ou com espaços | Use kebab-case e únicos |
-| Inconsistência entre os 3 artefatos | Revise antes de aprovar |
+---
+name: dare-tasks
+description: Decompõe o BLUEPRINT aprovado em tasks atômicas e gera os 3 artefatos da fase de execução do DARE (TASKS.md, dare-dag.yaml, EXECUTION/task-*.md). Use quando o usuário aprovar o BLUEPRINT.md. A construção do grafo segue rigorosamente a skill dare-dag-runner.
+---
+
+# DARE Tasks Skill
+
+Você é o especialista em decomposição de projetos do método DARE. Seu papel é
+quebrar o BLUEPRINT aprovado em tasks atômicas e gerar simultaneamente os
+**três artefatos** da fase de execução, garantindo consistência entre eles.
+
+## Quando usar esta skill
+
+- BLUEPRINT.md foi aprovado pelo usuário
+- Necessário criar o plano de execução (tasks + grafo + specs)
+- Terceira fase do Método DARE (transição A → E)
+
+## Pré-requisitos
+
+Antes de gerar, leia também a skill `dare-dag-runner` — ela contém as regras
+inegociáveis do grafo (`depends_on` mínimo, complexity, prompt self-contained,
+limites de 2000/4000 chars, ranks paralelos).
+
+## Os 3 artefatos sempre juntos
+
+| Arquivo | Para quê | Lido por |
+|---------|----------|----------|
+| `DARE/TASKS.md` | Visão humana com tabela e progresso | Humano |
+| `DARE/dare-dag.yaml` | Grafo executável | CLI `dare execute` |
+| `DARE/EXECUTION/task-<id>.md` | Spec detalhada por task | Subagente ao executar |
+
+Os três precisam estar **consistentes**: mesmos `id`s, mesmas `depends_on`,
+mesmas `complexity`. Inconsistência aqui quebra a execução.
+
+## Como usar
+
+### Passo 1: Ler o BLUEPRINT aprovado
+
+Leia `DARE/BLUEPRINT.md`. Extraia:
+- Fases do plano de execução
+- Endpoints, modelos de dados, schemas
+- Estrutura de diretórios
+- Decisões arquiteturais
+- Estratégia de testes
+
+### Passo 2: Decompor em tasks atômicas
+
+Cada task deve:
+- Ser pequena o suficiente para uma conversa única (15–60 min de trabalho)
+- Ter dependências reais e mínimas (não falsas)
+- Ser testável isoladamente
+- Incluir validações de segurança apropriadas
+- Ter `complexity` honesta (LOW/MED/HIGH)
+
+### Passo 3: Gerar `DARE/TASKS.md` (visão humana)
+
+```markdown
+# Tasks: [Nome do Projeto]
+
+## Visão Geral
+- Total de Tasks: [N]
+- Ranks paralelos: [N]
+- Tempo estimado: [horas]
+
+## Tabela de Status
+
+| ID       | Título                      | Status      | Depends On       | Complexity |
+|----------|-----------------------------|-------------|------------------|------------|
+| task-001 | Setup project structure     | ⏳ PENDING  | —                | LOW        |
+| task-002 | DB migrations               | ⏳ PENDING  | —                | MED        |
+| task-003 | Auth controllers            | ⏳ PENDING  | task-001, 002    | HIGH       |
+| ...      | ...                         | ...         | ...              | ...        |
+
+## Tarefas por Fase
+
+### Phase 1: Setup
+- task-001: Setup project structure
+- task-002: DB migrations
+
+### Phase 2: Auth
+- task-003: Auth controllers (deps: 001, 002)
+- ...
+
+## Próximas Etapas
+1. Revisar e aprovar este TASKS.md
+2. Executar paralelo: `dare execute --parallel`
+3. Ou task isolada: `/dare-execute task-001`
+```
+
+### Passo 4: Gerar `DARE/dare-dag.yaml` (grafo executável)
+
+Schema canônico:
+
+```yaml
+title: "[Nome do Projeto] - Development Tasks"
+version: "1.0.0"
+
+limits:
+  parent_context_chars: 2000
+  task_output_chars: 4000
+  timeout_seconds: 600
+
+models:
+  cursor:      { HIGH: gpt-5.3-codex,     MED: composer-2,       LOW: auto-low }
+  claude:      { HIGH: claude-sonnet-4-5, MED: claude-haiku-4,   LOW: claude-haiku-4 }
+  antigravity: { HIGH: gemini-2.5-pro,    MED: gemini-2.5-flash, LOW: gemini-2.5-flash }
+
+tasks:
+  - id: task-001
+    title: "Setup project structure"
+    depends_on: []
+    complexity: LOW
+    spec_file: EXECUTION/task-001.md
+    subtask_prompt: |
+      Setup base project structure following DARE/BLUEPRINT.md.
+      Create directories, initialize package files. No business logic yet.
+      Validation gate: project builds.
+
+  - id: task-002
+    title: "DB migrations"
+    depends_on: []
+    complexity: MED
+    spec_file: EXECUTION/task-002.md
+    subtask_prompt: |
+      Create migrations for users and refresh_tokens tables per BLUEPRINT.
+      Include indexes and FKs. Validation gate: migrate runs cleanly.
+```
+
+**Regras inegociáveis (da skill dare-dag-runner):**
+- `id` em kebab-case e único
+- `depends_on` mínimo — só quando filha **literalmente** precisa do output
+- `subtask_prompt` self-contained (subagente recebe só ele + 2000 chars de pais)
+- Pelo menos 2 tasks no rank 0 (`depends_on: []`)
+- Cadeia linear é antipattern — reveja
+
+### Passo 5: Gerar `DARE/EXECUTION/task-<id>.md` (specs detalhadas)
+
+Para CADA task no YAML, crie a spec usando `templates/TASK-SPEC-template.md`:
+
+```markdown
+# Task 001: Setup project structure
+
+## Objetivo
+Criar a estrutura base do projeto seguindo o BLUEPRINT.
+
+## Descrição
+Inicializar diretórios, package files e configuração mínima.
+Sem lógica de negócio — apenas scaffolding.
+
+## Arquivos a Criar
+- `src/` (diretório)
+- `tests/` (diretório)
+- `package.json` (ou equivalente da stack)
+- `.gitignore`
+
+## Validation Gates
+- [ ] Estrutura criada
+- [ ] Build passa sem erros
+- [ ] Lint sem warnings
+- [ ] `package.json` (ou Cargo.toml, composer.json) válido
+
+## Testes
+```bash
+npm run build    # ou cargo build, composer install, etc.
+```
+
+## Segurança
+- `.env` no `.gitignore`
+- Nenhum secret commitado
+
+## Próxima Task
+Task 002: DB migrations
+```
+
+### Passo 5.1: ANTI-STUB CONTRACT (inegociável)
+
+> Tasks geradas com `subtask_prompt` ou spec genéricos forçam o agente a inventar — e ele vai produzir mock, stub ou esqueleto. **Não é negociável**. O comando `dare review <task-id>` (v2.17+) detecta isso e marca a task como FAILED.
+
+Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender este contrato:
+
+**O `subtask_prompt` deve ser auto-suficiente**
+
+O subagente recebe **apenas** o `subtask_prompt` + snippets de 2000 chars dos pais. Inclua:
+
+- Caminho exato dos arquivos a criar/modificar
+- Assinaturas exatas das funções/endpoints (`fn name(params: T) -> R`)
+- Schema de request/response com tipos
+- Validações específicas (não "validar input" — `email: regex`, `senha: ≥ 8 chars + maiúscula + dígito`)
+- Edge cases enumerados (input vazio, duplicado, expirado, sem permissão)
+- Lista de testes esperados com nome + comportamento
+
+**A `spec_file` deve ter Definition of Done anti-stub:**
+
+```markdown
+## Definition of Done (ANTI-STUB)
+
+- [ ] Nenhum `TODO`, `FIXME`, `XXX` ou `HACK` em arquivos modificados
+- [ ] Nenhuma função vazia (`fn x() {}`, `def x(): pass`, `function x() {}`)
+- [ ] Nenhum `throw new Error('not implemented')`, `unimplemented!()`, `todo!()`, `NotImplementedError`
+- [ ] Nenhum `return null` / `return undefined` / `return {}` como única statement de função pública
+- [ ] Mocks **somente** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`
+- [ ] Endpoints retornam dados reais (não fixos / hardcoded)
+- [ ] Cada validação produz erro real com status code correto (testado)
+- [ ] Cada edge case tem teste unitário/integração
+```
+
+**Verificação:** o agente vai rodar `dare review <id>` antes de DONE. Falhou → volta pra revisão.
+
+**Sinais de spec rasa:**
+
+- ❌ "Implementar X" — sem assinatura, sem retorno, sem validações
+- ❌ "Tratar erros adequadamente" — quais erros?
+- ❌ "Adicionar validações" — quais regras?
+- ✅ "Implementar `POST /auth/login` retornando `{ token, refresh }` com 200/401/429"
+
+### Passo 6: Validar consistência
+
+Antes de entregar, confirme:
+- [ ] Mesmos `id`s em `TASKS.md`, `dare-dag.yaml` e `EXECUTION/task-*.md`
+- [ ] Mesmas `depends_on` nos três
+- [ ] Mesmas `complexity`
+- [ ] Sem ciclos no grafo
+- [ ] Pelo menos 2 tasks no rank 0
+- [ ] Cada `subtask_prompt` é executável sem contexto adicional
+
+### Passo 7: Regenerar a visualização do DAG
+
+Depois de salvar o `dare-dag.yaml`, rode:
+
+```bash
+dare dag viz -o DARE/dag-graph.mmd
+```
+
+Isso reescreve `DARE/dag-graph.mmd` (Mermaid) refletindo o grafo atualizado.
+O usuário pode abrir o arquivo no Antigravity para visualizar o grafo
+estático com cores por status antes de executar.
+
+### Passo 8: Pedir aprovação
+
+> Gerados os 4 artefatos da fase de execução:
+> - `DARE/TASKS.md` ([N] tasks)
+> - `DARE/dare-dag.yaml` ([N] ranks paralelos)
+> - `DARE/EXECUTION/task-*.md` ([N] specs)
+> - `DARE/dag-graph.mmd` (visualização Mermaid do DAG)
+>
+> Revise (abra `dag-graph.mmd` para ver o grafo). Quando aprovar:
+> `dare execute --next` para iniciar a execução.
+
+## Boas práticas
+
+1. **Atômicas:** cada task é independente o suficiente para uma conversa
+2. **Testáveis:** validation gates específicos da stack
+3. **Documentadas:** specs claras e auto-contidas
+4. **Seguras:** integre OWASP nos pontos sensíveis
+5. **Paralelizáveis:** maximize rank 0; minimize cadeias lineares
+
+## Erros comuns a evitar
+
+| Erro | Como corrigir |
+|------|---------------|
+| Cadeia linear `001→002→003→...` | Adicione paralelismo onde a dependência é falsa |
+| `subtask_prompt` referenciando "como combinamos" | Coloque tudo no prompt explicitamente |
+| Tudo em `complexity: HIGH` | Avalie honestamente — HIGH só para lógica crítica |
+| `id` duplicado ou com espaços | Use kebab-case e únicos |
+| Inconsistência entre os 3 artefatos | Revise antes de aprovar |

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

@@ -0,0 +1,188 @@
+---
+name: dare-telemetry
+description: Rastreamento de tokens e modelos de IA consumidos em cada etapa do Método DARE. Gera DARE/TELEMETRY.md com modelo usado, tokens estimados, tempo e tentativas (Ralph Loop) por comando — para auditoria, monitoramento de uso e otimização de custos.
+---
+
+# DARE Telemetry Skill
+
+Você é um especialista em observabilidade e monitoramento de uso de IA. Seu papel é rastrear consumo de tokens e modelos usados em cada etapa do DARE, mantendo `DARE/TELEMETRY.md` atualizado.
+
+> **Diferença com `dare-quality-telemetry`:**
+> - `dare-telemetry` (esta) — rastreia **uso de IA** (modelos, tokens, tempo) por comando DARE
+> - `dare-quality-telemetry` — agrega **métricas de qualidade** das skills (M-01 a M-04)
+
+## Quando usar
+
+- Ao final de cada comando DARE executado
+- Para gerar relatório periódico de uso de IA
+- Para auditoria de compliance (qual IA foi usada, onde)
+- Para otimização de custos (qual etapa consome mais)
+
+## Modelos rastreáveis
+
+Independente do IDE/agente:
+
+| Modelo | Provider | Características | Melhor para |
+|---|---|---|---|
+| Claude Opus 4.7 | Anthropic | Análise profunda, refactor longo | Design, blueprint, security review |
+| Claude Sonnet 4.5 | Anthropic | Equilíbrio velocidade/qualidade | Execução de tasks |
+| GPT-4 Turbo | OpenAI | Versátil | Tarefas gerais |
+| Gemini 2.0 Flash | Google | Ultra rápido | Tasks simples, processamento em batch |
+| Modelos locais (Ollama) | Self-hosted | Privacidade total | Dados sensíveis |
+
+## Estrutura `DARE/TELEMETRY.md`
+
+```markdown
+# Telemetria do Projeto: [Nome]
+
+## Resumo Executivo
+- **Projeto:** [Nome]
+- **Data de início:** [ISO 8601]
+- **Tokens totais processados:** [Número]
+- **Modelos utilizados:** [Lista]
+- **Tempo total de execução:** [Tempo]
+- **Custo estimado:** $[X]
+
+## Detalhamento por Etapa
+
+### 1. Design (`/dare-design`)
+- **Data/Hora:** [Timestamp]
+- **Modelo:** Claude Opus 4.7
+- **Tokens estimados (in/out):** 7,390 / 1,250
+- **Tempo de execução:** 45 segundos
+- **Comando:** `/dare-design "Criar API de autenticação"`
+- **Resultado:** DESIGN.md gerado, 12 RFs, 8 RNFs, 5 RS
+- **Observações:** [Ajustes manuais necessários, etc.]
+
+### 2. Blueprint (`/dare-blueprint`)
+- **Data/Hora:** [Timestamp]
+- **Modelo:** Claude Opus 4.7
+- **Tokens estimados (in/out):** 21,373 / 4,800
+- **Tempo:** 2 min
+- **Arquivo processado:** DARE/DESIGN.md
+- **Resultado:** BLUEPRINT.md com 8 fases, 25 tabelas, 4 diagramas Mermaid
+
+### 3. Tasks (`/dare-tasks`)
+- **Tokens estimados:** 33,912 / 8,200
+- **Tempo:** 3 min 20 seg
+- **Arquivo processado:** DARE/BLUEPRINT.md
+- **Tasks geradas:** 12
+
+### 4. Execute Tasks (`/dare-execute`)
+
+- **task-001 — Migration de Users**
+  - Modelo: Claude Sonnet 4.5
+  - Tokens: 7,801 / 2,500
+  - Tempo: 1 min 30 seg
+  - Tentativas (Ralph Loop): 1
+  - Status: ✓ Sucesso
+
+- **task-002 — AuthController**
+  - Modelo: Claude Sonnet 4.5
+  - Tokens: 11,357 / 3,200
+  - Tempo: 2 min
+  - Tentativas: 2 (1 falha por typo)
+  - Status: ✓ Sucesso
+
+## Análise
+
+| Etapa | Tokens in/out | % do total | Tempo |
+|---|---|---|---|
+| Design | 7,390 / 1,250 | 5% | 45 seg |
+| Blueprint | 21,373 / 4,800 | 15% | 2 min |
+| Tasks | 33,912 / 8,200 | 24% | 3 min 20 seg |
+| Execute (12 tasks) | 85,234 / 24,000 | 56% | 25 min |
+| **TOTAL** | **147,909 / 38,250** | **100%** | **~31 min** |
+
+## Modelos utilizados
+
+- Claude Opus 4.7: 62,675 tokens (42%) — design + blueprint + tasks
+- Claude Sonnet 4.5: 85,234 tokens (58%) — execução de tasks
+
+## Custo estimado
+
+| Modelo | Tokens in | Tokens out | $/M in | $/M out | Total |
+|---|---|---|---|---|---|
+| Opus 4.7 | 62,675 | 14,250 | $15 | $75 | $2.01 |
+| Sonnet 4.5 | 85,234 | 24,000 | $3 | $15 | $0.62 |
+| **Total** | | | | | **$2.63** |
+```
+
+## Como aplicar
+
+### Passo 1: Após `/dare-design`
+
+Adicione entrada na seção Design com:
+- Timestamp
+- Modelo do agente (perguntar ao usuário se não souber automaticamente)
+- Tokens estimados (in/out) — pegar do output do modelo se disponível
+- Tempo de execução
+- Comando executado
+- Observações qualitativas
+
+### Passo 2: Após `/dare-blueprint`
+
+Idem. Adicione tabelas e diagramas gerados como resultado.
+
+### Passo 3: Após `/dare-tasks`
+
+Inclua número de tasks geradas, complexidade média.
+
+### Passo 4: Após cada `/dare-execute`
+
+Para cada task:
+- Modelo usado
+- Tokens
+- Tempo
+- **Tentativas no Ralph Loop** (importante — se >2, task precisa refino)
+- Status (Sucesso/Falha)
+
+### Passo 5: Recompilar análise + custos
+
+A cada 5 tasks ou release, atualize a seção Análise com totais agregados.
+
+## Capturando informações do agente
+
+Cada IDE expõe diferente:
+
+**Antigravity:**
+- Modelo aparece no header da conversa
+- Tokens estimados em `?ax-debug` ou settings
+
+**Claude Code:**
+- `/cost` mostra tokens da sessão
+- Modelo no rodapé
+
+**Cursor:**
+- Barra de status canto inferior direito
+- Histórico de conversa tem detalhes por resposta
+
+## Otimizações recomendadas
+
+1. **Modelo certo para tarefa certa**
+   - Opus → design/blueprint/security review
+   - Sonnet → execução
+   - Gemini Flash → tasks simples, batch
+2. **Reutilizar contexto** — múltiplas tasks na mesma sessão economiza re-leitura
+3. **Revisar Blueprint antes de Tasks** — evita re-geração
+4. **Agrupar tasks relacionadas** — contexto reaproveitado
+5. **Ralph Loop alto = especificação ruim** — se task precisa >2 tentativas, refine BLUEPRINT.md
+
+## Antipatterns
+
+| AP | Antipattern | Por quê |
+|---|---|---|
+| AP-01 | Não rastrear telemetria | Sem dados para otimizar |
+| AP-02 | Usar Opus para tasks triviais | Desperdício de custo |
+| AP-03 | Ignorar Ralph Loop alto | Specs ruins se acumulam |
+| AP-04 | Não auditar modelo (compliance) | Risco regulatório se houver |
+
+## Dicas
+
+- **Combine** com `dare-quality-telemetry` — esta rastreia uso de IA, aquela rastreia qualidade
+- **Exporte** TELEMETRY.md para dashboard (Grafana, Notion, etc.) periodicamente
+- **Trate custo como métrica** — adicione ao Ralph Loop como gate (>$Y/feature = revisar specs)
+
+---
+
+Esta skill é parte do DARE Method e está sob licença MIT.