@dewtech/dare-cli 2.17.0 → 3.1.0

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

@@ -0,0 +1,152 @@
+---
+name: dare-ax
+description: Agent Experience (AX) — codifica padrões para desenvolvimento assistido por IA em três planos (Discovery, Usage, Defense). Garante que todo projeto DARE exponha sinais estruturados (llms.txt, OpenAPI, --json, rate limit) que agentes de código precisam para trabalhar sem refactor desnecessário.
+---
+
+# DARE AX Skill (Agent Experience)
+
+Você é um especialista em integração entre projetos e agentes de código (Claude Code, Cursor, Antigravity, etc.). Seu papel é garantir que todo projeto DARE seja **navegável, usável e defensivo** quando consumido por uma IA.
+
+## Quando usar esta skill
+
+- Está bootstrapando um projeto novo via `dare init` e precisa do baseline AX
+- Está auditando um projeto existente e quer saber se ele é "AX-friendly"
+- Está adicionando uma feature que muda a superfície pública (endpoints HTTP, CLI, docs)
+- Vai integrar o projeto com um agente externo (LangChain, OpenAI Agents, MCP server)
+
+## Os três planos AX
+
+### Plano 1: Discovery — o agente acha o que precisa
+
+| Sinal | Onde mora | Conteúdo mínimo |
+|---|---|---|
+| `llms.txt` | raiz do repositório | nome do projeto, descrição em 1 parágrafo, links para docs principais, comandos `make`/`npm run`, endpoints expostos, exemplos |
+| `README.md` | raiz | bootstrap em 5 minutos, link para llms.txt, link para OpenAPI |
+| Estrutura previsível | `src/`, `tests/`, `docs/`, `DARE/` | sem pastas exóticas (`thing/`, `stuff/`) |
+
+### Plano 2: Usage — o agente consegue operar
+
+| Sinal | Obrigatório quando |
+|---|---|
+| `openapi.json` em `/openapi.json` ou `public/openapi.json` | projeto expõe HTTP |
+| Flag `--json` em todos os comandos CLI | projeto expõe CLI |
+| `Dockerfile` + `docker-compose.yml` validados | qualquer projeto que toque serviços externos |
+| `.env.example` versionado | qualquer projeto |
+
+### Plano 3: Defense — o agente não pode quebrar produção
+
+| Defesa | Implementação típica |
+|---|---|
+| Rate limit | `rack-attack` (Rails), `express-rate-limit` (Node), `tower-governor` (Rust), `slowapi` (FastAPI) |
+| Validação de input | FormRequests (Laravel), Pydantic (FastAPI), Zod (Node), serde + validator (Rust) |
+| Secrets só via env | `.env` no `.gitignore`, `.env.example` sem valores reais |
+| `llms.txt` sem secrets | scan automático no CI bloqueando padrões `api_key=`, `password=`, `DATABASE_URL=` |
+
+## Métricas obrigatórias (todas Tipo A — binárias, verificáveis em CI)
+
+| ID | Métrica | Como medir |
+|---|---|---|
+| M-01 | `llms.txt` existe e é válido (sem secrets, seções obrigatórias presentes) | grep + parse do arquivo |
+| M-02 | `public/openapi.json` ou `openapi.json` existe | `test -f` |
+| M-03 | CLI suporta `--json` | rodar `cli --help \| grep '\-\-json'` |
+| M-04 | Rate limit configurado | grep por `rack-attack \| express-rate-limit \| tower-governor \| slowapi` |
+
+Se M-01 ou M-04 falhar em produção, falha o pipeline.
+
+## Antipatterns explícitos
+
+| ID | Antipattern | Por que evitar |
+|---|---|---|
+| AP-01 | Docs fora do código | Divergem rapidamente |
+| AP-02 | OpenAPI escrito à mão | Fica desatualizado; sempre auto-gerar |
+| AP-03 | CLI sem `--json` | Agentes precisam de parsing regex — brittle |
+| AP-04 | Rate limit em dev, esquecido em prod | Produção vira target de abuse |
+| AP-05 | `llms.txt` com secrets | Expõe credenciais no repositório público |
+| AP-06 | CORS wildcard (`*`) em produção | Permite qualquer origem |
+| AP-07 | Validação só em API, esquecida em CLI | Agentes usam ambos |
+| AP-08 | Configs opcionais sem default | Agentes precisam de defaults previsíveis |
+
+## Template `llms.txt` (gerar sempre)
+
+```
+# <nome-do-projeto>
+
+> <descricao em 1-2 frases>
+
+## Stack
+
+- <linguagem + framework>
+- <banco de dados>
+- <cache, fila, etc.>
+
+## Bootstrap
+
+- `make setup` — instala deps + sobe Postgres/Redis
+- `make dev` — sobe aplicação em modo dev
+- `make test` — roda suite completa
+
+## Endpoints
+
+- `GET /healthz` — liveness
+- `GET /openapi.json` — spec OpenAPI completa
+- `POST /api/login` — autenticação
+- ...
+
+## Docs
+
+- DARE/DESIGN.md — requisitos
+- DARE/BLUEPRINT.md — arquitetura
+- docs/RUNBOOK.md — operações
+```
+
+## Como aplicar passo a passo
+
+### Passo 1: Auditar o projeto
+
+Rode mentalmente o checklist:
+- [ ] `llms.txt` existe na raiz?
+- [ ] `openapi.json` é gerado a cada build?
+- [ ] Todos os comandos CLI aceitam `--json`?
+- [ ] Existe rate limit em endpoints públicos?
+- [ ] `.env.example` está versionado e sem valores reais?
+
+### Passo 2: Gerar `llms.txt` se faltar
+
+Use o template acima. Liste **apenas** comandos e endpoints que realmente existem — não invente.
+
+### Passo 3: Validar OpenAPI
+
+Se a stack for:
+- **Node/NestJS** — `@nestjs/swagger` decorators + `OpenAPIModule.createDocument`
+- **FastAPI** — automático via Pydantic, exposto em `/openapi.json`
+- **Rails/Grape** — `grape-swagger` ou `rswag`
+- **Rust/Axum** — `utoipa` + `utoipa-swagger-ui`
+- **Laravel** — `darkaonline/l5-swagger`
+
+### Passo 4: Validar CLI --json
+
+Em qualquer CLI do projeto, `--json` deve:
+- Imprimir JSON puro em stdout (sem cores ANSI, sem prompt)
+- Manter exit code = 0 em sucesso, ≠ 0 em erro
+- Schema documentado no `llms.txt`
+
+### Passo 5: Validar rate limit
+
+Procurar por gem/package específico da stack. Se ausente em endpoint público autenticado → adicionar antes de release.
+
+## Boas práticas
+
+1. **AX como cidadão de primeira classe** — não é "feature opcional", é parte do design
+2. **Single source of truth** — OpenAPI gerado a partir do código, nunca manual
+3. **Defaults previsíveis** — agentes precisam adivinhar menos
+4. **Logs estruturados (JSON)** — facilita debug por agente que lê output
+
+## Dicas para melhor resultado
+
+- **Consulte** `docs/design/skills/dare-ax/DESIGN.md` para o "porquê" detalhado
+- **Use** a skill `dare-security` em conjunto — AX e segurança são primos próximos
+- **Antes de release**, rode os 4 checks de M-01 a M-04 em CI
+
+---
+
+Esta skill é parte do DARE Method e está sob licença MIT.

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

@@ -0,0 +1,154 @@
+---
+name: dare-dag-build
+description: Regenera APENAS o DARE/dare-dag.yaml a partir do DARE/BLUEPRINT.md existente, sem refazer o blueprint nem as specs. Use quando o BLUEPRINT mudou pouco mas o grafo precisa refletir o novo estado, ou quando você quer experimentar uma decomposição diferente.
+---
+
+# DARE DAG Build Skill
+
+Você é o construtor de grafos da fase EXECUTE do método DARE no Antigravity. Esta skill **regenera APENAS** o `DARE/dare-dag.yaml` — não refaz o BLUEPRINT, não refaz as specs, não roda nada. Apenas reconstrói o grafo de tasks a partir do estado atual do BLUEPRINT.
+
+> Se você precisa **executar** o grafo, use `dare-dag-run`.
+> Se você precisa **visualizar** o grafo, use `dare-dag-viz`.
+> Se você precisa **fazer tudo de uma vez** (build + run), use `dare-dag-runner`.
+
+## Quando usar esta skill
+
+- O BLUEPRINT foi ajustado e o grafo precisa refletir as mudanças
+- Você quer experimentar uma decomposição diferente sem refazer o blueprint
+- O `dare-dag.yaml` ficou inconsistente com `EXECUTION/task-*.md`
+- Precisa adicionar/remover/reordenar tasks no grafo
+- A complexidade ou as dependências de tasks mudaram
+
+## Pré-requisitos
+
+- `DARE/BLUEPRINT.md` existe e está aprovado
+- (Opcional) `DARE/EXECUTION/task-*.md` específicas — serão preservadas se não forem mencionadas
+
+## Como usar
+
+### Passo 1 — Ler `DARE/BLUEPRINT.md`
+
+Obrigatório. Se faltar, peça `dare-blueprint` antes.
+
+### Passo 2 — Ler `DARE/dare-dag.yaml` atual (se existir)
+
+Para preservar `id`s já em uso e não confundir o usuário com renomeações desnecessárias.
+
+### Passo 3 — Gerar o novo `dare-dag.yaml`
+
+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: "..."
+    depends_on: []
+    complexity: LOW
+    spec_file: EXECUTION/task-001.md
+    subtask_prompt: |
+      <self-contained>
+```
+
+**Regras inegociáveis:**
+
+- `id` em kebab-case e único
+- `depends_on` mínimo — só quando filha *literalmente* precisa do output do pai
+- `subtask_prompt` self-contained (o subagente recebe apenas isso + 2000 chars dos pais)
+- Pelo menos **2 tasks no rank 0** (paralelismo desde o início)
+- Cadeia linear é antipattern — quebre dependências sempre que possível
+- `complexity` honesta — não inflar nem deflar
+
+### Passo 4 — 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. **O comando `dare-review` detecta isso e marca a task como FAILED.**
+
+Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender:
+
+**O `subtask_prompt` precisa ser auto-suficiente.** 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 + 1 maiúscula + 1 dígito`)
+- Edge cases enumerados (input vazio, duplicado, expirado, sem permissão)
+- Lista de testes esperados com nome + comportamento
+
+**A `spec_file` (`EXECUTION/task-<id>.md`) precisa 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/undefined/{} como única statement de função pública
+- [ ] Mocks SOMENTE em *.test.*, *.spec.*, __tests__/, tests/, spec/ — NUNCA em código de produção
+- [ ] Todos os endpoints retornam dados reais (não hardcoded)
+- [ ] Cada validação produz erro real com status code correto (testado)
+- [ ] Cada edge case tem teste demonstrando comportamento
+```
+
+**Sinais de spec rasa (auto-validar antes de salvar):**
+
+- ❌ "Implementar X" — sem assinatura, sem retorno, sem validações
+- ❌ "Tratar erros adequadamente" — quais erros? como? que código?
+- ❌ "Adicionar validações" — quais regras?
+- ✅ "Implementar `POST /auth/login` retornando `{ token: string, refresh: string }` com 200 se credenciais válidas, 401 se inválidas, 429 se rate limit"
+
+### Passo 5 — Validar consistência com `EXECUTION/task-*.md`
+
+Se uma spec já existe em `DARE/EXECUTION/task-<id>.md`:
+- Mantenha o mesmo `id` no YAML
+- Aponte `spec_file: EXECUTION/task-<id>.md`
+- Se a `complexity` ou `depends_on` mudou, atualize **também** a spec e o `TASKS.md`
+
+Se uma task nova entrou no YAML mas não tem spec:
+- Crie a spec correspondente em `EXECUTION/task-<id>.md`
+
+Se uma task saiu do YAML mas a spec ficou:
+- Pergunte ao usuário: arquivar (mover para `EXECUTION/_archived/`) ou apagar?
+
+### Passo 6 — Validar grafo
+
+- Sem ciclos (DAG = Directed Acyclic Graph)
+- Todos os `depends_on` apontam para `id`s existentes
+- `id`s únicos
+- Pelo menos 2 tasks no rank 0
+
+### Passo 7 — Atualizar `DARE/TASKS.md`
+
+Reflita o novo grafo na tabela master.
+
+### Passo 8 — Mensagem ao usuário
+
+> `dare-dag.yaml` regenerado:
+> - Total de tasks: N
+> - Ranks paralelos: N
+> - Adicionadas: [...]
+> - Removidas: [...]
+> - Modificadas: [...]
+>
+> Revise e aprove. Para executar: invoque a skill `dare-dag-run`.
+
+## Quando NÃO usar esta skill
+
+- Se você nunca rodou `dare-blueprint` antes — use `dare-blueprint` primeiro
+- Se o BLUEPRINT está desatualizado — atualize o BLUEPRINT primeiro
+- Se você só quer executar o grafo já aprovado — use `dare-dag-run`
+- Se você quer build + run num único passo — use `dare-dag-runner`
+
+## Licença
+
+Esta skill é parte do DARE Method e está sob licença MIT (D-001).

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

@@ -0,0 +1,130 @@
+---
+name: dare-dag-run
+description: Executa o grafo de tasks definido em DARE/dare-dag.yaml usando Antigravity como executor e o CLI dare como orquestrador. Sem API keys — usa o plano nativo da IDE. O canvas ao vivo fica em DARE/.canvas.md.
+---
+
+# DARE DAG Run Skill
+
+Você é o executor da fase EXECUTE do método DARE no Antigravity. Esta skill **executa APENAS** o grafo que já foi construído — não regenera o `dare-dag.yaml`, não modifica o BLUEPRINT, não cria specs novas. Apenas roda as tasks na ordem topológica correta.
+
+> Se você precisa **(re)construir** o grafo, use `dare-dag-build`.
+> Se você precisa **visualizar** o grafo, use `dare-dag-viz`.
+> Se você precisa **fazer tudo** (build + run num passo), use `dare-dag-runner`.
+
+> **Sem API keys.** Você (Antigravity) usa o plano nativo da IDE. O CLI `dare` apenas coordena estado, monta prompts e atualiza o canvas.
+
+## Quando usar esta skill
+
+- `DARE/dare-dag.yaml` está aprovado e pronto
+- As specs em `DARE/EXECUTION/task-<id>.md` estão geradas
+- É hora de implementar as tasks na ordem do grafo
+- O usuário aprovou os ANTI-STUB contracts
+
+## Pré-requisitos
+
+- `DARE/dare-dag.yaml` existe e foi aprovado pelo usuário
+- Specs em `DARE/EXECUTION/task-<id>.md` geradas (se não, use `dare-dag-build`)
+- `dare` disponível no PATH (`npm i -g @dewtech/dare-cli`)
+
+## Como usar
+
+```
+Invoque a skill com:
+- (sem args) — executa todas as ready do próximo rank
+- --task task-003 — executa só uma task específica
+```
+
+### Passo 1 — Validar pré-condições
+
+- Confirme que `DARE/dare-dag.yaml` existe. Se não, oriente o usuário a invocar `dare-blueprint` ou `dare-dag-build`
+- Leia o YAML e verifique: sem ciclos, ids únicos, ranks paralelizáveis
+- Liste rapidamente para o usuário: total de tasks, ranks, próximas ready
+
+### Passo 2 — Pegar próximas tasks
+
+```bash
+dare execute --next
+```
+
+O CLI imprime as tasks **ready** do rank atual com o prompt completo (snippets de até 2000 chars dos outputs dos pais já costurados). Use esses prompts diretamente — não reescreva.
+
+### Passo 3 — Sugerir abrir o canvas
+
+Antes de começar, peça ao usuário abrir `DARE/.canvas.md` em outra aba do Antigravity. Esse é o feedback visual ao vivo da execução.
+
+### Passo 4 — Executar cada task
+
+Para cada task ready:
+
+1. Leia `spec_file` se houver (`DARE/EXECUTION/task-<id>.md`)
+2. Implemente conforme o `subtask_prompt` — **não invente, não use mock fora de tests, sem TODOs**
+3. Rode o Ralph Loop completo: build → test → lint
+4. Registre o resultado no CLI:
+
+```bash
+# Sucesso
+dare execute --complete task-001 --output "Resumo curto + arquivos criados/modificados (paths)"
+
+# Falha
+dare execute --fail task-002 --reason "Mensagem clara da falha (compilação? teste? lint?)"
+```
+
+### Passo 5 — Avançar de rank
+
+```bash
+dare execute --next
+```
+
+- Se aparecer `✅ All tasks resolved`, todas terminaram. Reporte o resumo.
+- Caso contrário, continue executando o próximo rank.
+
+### Passo 6 — Pós-execução
+
+```bash
+dare execute --status
+```
+
+Mostra snapshot do canvas + sumário (X DONE, Y FAILED, Z SKIPPED).
+
+Para retentar tasks FAILED:
+
+```bash
+dare execute --reset task-002
+dare execute --next
+```
+
+## Comandos do orquestrador `dare`
+
+| Comando | Função |
+|---------|--------|
+| `dare execute --next` | Próximas tasks ready com prompts compostos |
+| `dare execute --complete <id> --output "..."` | Marca DONE |
+| `dare execute --fail <id> --reason "..."` | Marca FAILED + cascade-skip |
+| `dare execute --reset <id>` | Volta para PENDING |
+| `dare execute --status` | Snapshot do canvas + sumário |
+
+## Erros comuns
+
+| Sintoma | Causa | Correção |
+|---------|-------|----------|
+| `dare-dag.yaml not found` | Não foi gerado | Invoque `dare-blueprint` ou `dare-dag-build` |
+| Cascata de SKIPPED | Pai falhou | Corrija pai → `dare execute --reset` → `--next` |
+| Output truncado | Cap de 4000 chars | Escreva em arquivo, retorne resumo |
+| Spec inconsistente | TASKS.md ≠ dare-dag.yaml | Re-gere com `dare-dag-build` |
+
+## Referências
+
+- Schema: `DARE/dare-dag.yaml`
+- Canvas: `DARE/.canvas.md`
+- Specs: `DARE/EXECUTION/task-*.md`
+- Status: `DARE/TASKS.md`
+
+## Quando NÃO usar esta skill
+
+- Se `dare-dag.yaml` não existe — use `dare-blueprint` ou `dare-dag-build`
+- Se você quer só visualizar o grafo — use `dare-dag-viz`
+- Se você quer build + run num único passo — use `dare-dag-runner`
+
+## Licença
+
+Esta skill é parte do DARE Method e está sob licença MIT (D-001).