@dewtech/dare-cli 3.2.0 → 3.4.0

package/templates/ide/cursor/.cursor/rules/skill-dag-build.mdc

@@ -1,173 +1,173 @@
----
-description: Regenera APENAS o DARE/dare-dag.yaml a partir do BLUEPRINT.md já existente — sem refazer o blueprint nem as specs. Use quando o BLUEPRINT mudou pouco mas o grafo precisa refletir o novo estado, ou para experimentar uma decomposição diferente.
-globs: DARE/BLUEPRINT.md,DARE/dare-dag.yaml,DARE/EXECUTION/**
-alwaysApply: false
----
-
-# Skill: DAG Build — Regerar o grafo
-
-Esta skill regenera **apenas** o `DARE/dare-dag.yaml` a partir do BLUEPRINT
-existente. Não refaz o blueprint, não refaz specs, não executa nada.
-
-> Para **executar** o grafo, use a skill `skill-dag-runner` (rule) ou o
-> comando `/run-dag`.
-> Para **visualizar** o grafo, use o comando `/dag-viz`.
-> Para **build + run num único passo**, use `skill-dag-runner` que cobre
-> ambos.
-
-## Quando usar
-
-- O BLUEPRINT foi ajustado e o grafo precisa refletir
-- 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
-
-## Procedimento
-
-### 1. Ler `DARE/BLUEPRINT.md`
-
-Obrigatório. Se faltar, peça ao usuário rodar `/generate-blueprint` antes.
-
-### 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.
-
-### 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
-- 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
-
-### 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
-`/review-task` (ou `dare review <id>`) detecta isso e marca a task como
-FAILED.
-
-Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender este contrato:
-
-**O `subtask_prompt` precisa 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
-- Schema de request/response com tipos
-- Validações específicas (não "validar input" — `email: regex /^.../`)
-- Edge cases enumerados
-- Lista de testes esperados com nome + comportamento
-
-**A `spec_file` 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
-- [ ] 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/
-- [ ] 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, refresh }` com 200 se válido, 401 se inválido, 429 se rate limit"
-
-### 5. Validar consistência com `EXECUTION/task-*.md`
-
-Se uma spec 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?
-
-### 6. Validar grafo
-
-- Sem ciclos
-- Todos os `depends_on` apontam para `id`s existentes
-- `id`s únicos
-- Pelo menos 2 tasks no rank 0
-
-### 7. Atualizar `DARE/TASKS.md`
-
-Reflita o novo grafo na tabela master.
-
-### 8. Mensagem ao usuário
-
-> `dare-dag.yaml` regenerado:
-> - Total de tasks: N
-> - Ranks paralelos: N
-> - Adicionadas: [...]
-> - Removidas: [...]
-> - Modificadas: [...]
->
-> Revise e aprove. Para executar: `/run-dag`.
-
-## Quando NÃO usar
-
-- Se você nunca rodou `/generate-blueprint` antes — use ele primeiro
-- Se o BLUEPRINT está desatualizado — atualize o BLUEPRINT primeiro
-- Se você só quer executar o grafo já aprovado — use `skill-dag-runner` ou `/run-dag`
-- Se você quer build + run num único passo — `skill-dag-runner` cobre
-
-## Referências
-
-- Schema: `DARE/dare-dag.yaml`
-- Specs: `DARE/EXECUTION/task-*.md`
-- Status: `DARE/TASKS.md`
-
----
-
-## Licença
-
-Esta skill é parte do DARE Method e está sob licença MIT (D-001).
+---
+description: Regenera APENAS o DARE/dare-dag.yaml a partir do BLUEPRINT.md já existente — sem refazer o blueprint nem as specs. Use quando o BLUEPRINT mudou pouco mas o grafo precisa refletir o novo estado, ou para experimentar uma decomposição diferente.
+globs: DARE/BLUEPRINT.md,DARE/dare-dag.yaml,DARE/EXECUTION/**
+alwaysApply: false
+---
+
+# Skill: DAG Build — Regerar o grafo
+
+Esta skill regenera **apenas** o `DARE/dare-dag.yaml` a partir do BLUEPRINT
+existente. Não refaz o blueprint, não refaz specs, não executa nada.
+
+> Para **executar** o grafo, use a skill `skill-dag-runner` (rule) ou o
+> comando `/run-dag`.
+> Para **visualizar** o grafo, use o comando `/dag-viz`.
+> Para **build + run num único passo**, use `skill-dag-runner` que cobre
+> ambos.
+
+## Quando usar
+
+- O BLUEPRINT foi ajustado e o grafo precisa refletir
+- 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
+
+## Procedimento
+
+### 1. Ler `DARE/BLUEPRINT.md`
+
+Obrigatório. Se faltar, peça ao usuário rodar `/generate-blueprint` antes.
+
+### 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.
+
+### 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
+- 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
+
+### 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
+`/review-task` (ou `dare review <id>`) detecta isso e marca a task como
+FAILED.
+
+Cada `subtask_prompt` e `EXECUTION/task-<id>.md` deve atender este contrato:
+
+**O `subtask_prompt` precisa 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
+- Schema de request/response com tipos
+- Validações específicas (não "validar input" — `email: regex /^.../`)
+- Edge cases enumerados
+- Lista de testes esperados com nome + comportamento
+
+**A `spec_file` 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
+- [ ] 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/
+- [ ] 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, refresh }` com 200 se válido, 401 se inválido, 429 se rate limit"
+
+### 5. Validar consistência com `EXECUTION/task-*.md`
+
+Se uma spec 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?
+
+### 6. Validar grafo
+
+- Sem ciclos
+- Todos os `depends_on` apontam para `id`s existentes
+- `id`s únicos
+- Pelo menos 2 tasks no rank 0
+
+### 7. Atualizar `DARE/TASKS.md`
+
+Reflita o novo grafo na tabela master.
+
+### 8. Mensagem ao usuário
+
+> `dare-dag.yaml` regenerado:
+> - Total de tasks: N
+> - Ranks paralelos: N
+> - Adicionadas: [...]
+> - Removidas: [...]
+> - Modificadas: [...]
+>
+> Revise e aprove. Para executar: `/run-dag`.
+
+## Quando NÃO usar
+
+- Se você nunca rodou `/generate-blueprint` antes — use ele primeiro
+- Se o BLUEPRINT está desatualizado — atualize o BLUEPRINT primeiro
+- Se você só quer executar o grafo já aprovado — use `skill-dag-runner` ou `/run-dag`
+- Se você quer build + run num único passo — `skill-dag-runner` cobre
+
+## Referências
+
+- Schema: `DARE/dare-dag.yaml`
+- Specs: `DARE/EXECUTION/task-*.md`
+- Status: `DARE/TASKS.md`
+
+---
+
+## Licença
+
+Esta skill é parte do DARE Method e está sob licença MIT (D-001).

package/templates/ide/cursor/.cursor/rules/skill-dag-run.mdc

@@ -1,134 +1,134 @@
----
-description: Executa o grafo de tasks definido em DARE/dare-dag.yaml usando Cursor 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.
-globs: DARE/dare-dag.yaml,DARE/EXECUTION/**,DARE/.canvas.md
-alwaysApply: false
----
-
-# Skill: DAG Run — Executar o grafo
-
-Esta skill **executa** 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.
-
-> Para **(re)construir** o grafo, use `skill-dag-build`.
-> Para **visualizar** o grafo, use o comando `/dag-viz`.
-> Para **build + run num único passo**, use `skill-dag-runner`.
-
-> **Sem API keys.** Você (Cursor) usa o plano nativo da IDE. O CLI `dare`
-> apenas coordena estado, monta prompts e atualiza o canvas.
-
-## Quando usar
-
-- `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 `skill-dag-build`)
-- `dare` disponível no PATH (`npm i -g @dewtech/dare-cli`)
-
-## Procedimento
-
-### 1. Validar pré-condições
-
-- Confirme que `DARE/dare-dag.yaml` existe. Se não, oriente
-  `/generate-blueprint` ou `skill-dag-build`
-- Leia o YAML e verifique: sem ciclos, ids únicos, ranks paralelizáveis
-- Liste para o usuário: total de tasks, ranks, próximas ready
-
-### 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.
-
-### 3. Sugerir abrir o canvas
-
-Antes de começar, peça ao usuário abrir `DARE/.canvas.md` em outra aba do
-Cursor. Esse é o feedback visual ao vivo da execução.
-
-### 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 + paths dos arquivos criados/modificados"
-
-# Falha
-dare execute --fail task-002 --reason "Mensagem clara da falha"
-```
-
-### 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.
-
-### 6. Pós-execução
-
-```bash
-dare execute --status
-```
-
-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 + sumário |
-
-## Erros comuns
-
-| Sintoma | Causa | Correção |
-|---------|-------|----------|
-| `dare-dag.yaml not found` | Não foi gerado | `/generate-blueprint` ou `skill-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 `skill-dag-build` |
-
-## Quando NÃO usar
-
-- Se `dare-dag.yaml` não existe — use `/generate-blueprint` ou `skill-dag-build`
-- Se você quer só visualizar — use `/dag-viz`
-- Se você quer build + run num único passo — `skill-dag-runner`
-
-## Referências
-
-- Schema: `DARE/dare-dag.yaml`
-- Canvas: `DARE/.canvas.md`
-- Specs: `DARE/EXECUTION/task-*.md`
-- Status: `DARE/TASKS.md`
-
----
-
-## Licença
-
-Esta skill é parte do DARE Method e está sob licença MIT (D-001).
+---
+description: Executa o grafo de tasks definido em DARE/dare-dag.yaml usando Cursor 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.
+globs: DARE/dare-dag.yaml,DARE/EXECUTION/**,DARE/.canvas.md
+alwaysApply: false
+---
+
+# Skill: DAG Run — Executar o grafo
+
+Esta skill **executa** 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.
+
+> Para **(re)construir** o grafo, use `skill-dag-build`.
+> Para **visualizar** o grafo, use o comando `/dag-viz`.
+> Para **build + run num único passo**, use `skill-dag-runner`.
+
+> **Sem API keys.** Você (Cursor) usa o plano nativo da IDE. O CLI `dare`
+> apenas coordena estado, monta prompts e atualiza o canvas.
+
+## Quando usar
+
+- `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 `skill-dag-build`)
+- `dare` disponível no PATH (`npm i -g @dewtech/dare-cli`)
+
+## Procedimento
+
+### 1. Validar pré-condições
+
+- Confirme que `DARE/dare-dag.yaml` existe. Se não, oriente
+  `/generate-blueprint` ou `skill-dag-build`
+- Leia o YAML e verifique: sem ciclos, ids únicos, ranks paralelizáveis
+- Liste para o usuário: total de tasks, ranks, próximas ready
+
+### 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.
+
+### 3. Sugerir abrir o canvas
+
+Antes de começar, peça ao usuário abrir `DARE/.canvas.md` em outra aba do
+Cursor. Esse é o feedback visual ao vivo da execução.
+
+### 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 + paths dos arquivos criados/modificados"
+
+# Falha
+dare execute --fail task-002 --reason "Mensagem clara da falha"
+```
+
+### 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.
+
+### 6. Pós-execução
+
+```bash
+dare execute --status
+```
+
+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 + sumário |
+
+## Erros comuns
+
+| Sintoma | Causa | Correção |
+|---------|-------|----------|
+| `dare-dag.yaml not found` | Não foi gerado | `/generate-blueprint` ou `skill-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 `skill-dag-build` |
+
+## Quando NÃO usar
+
+- Se `dare-dag.yaml` não existe — use `/generate-blueprint` ou `skill-dag-build`
+- Se você quer só visualizar — use `/dag-viz`
+- Se você quer build + run num único passo — `skill-dag-runner`
+
+## Referências
+
+- Schema: `DARE/dare-dag.yaml`
+- Canvas: `DARE/.canvas.md`
+- Specs: `DARE/EXECUTION/task-*.md`
+- Status: `DARE/TASKS.md`
+
+---
+
+## Licença
+
+Esta skill é parte do DARE Method e está sob licença MIT (D-001).