| 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 ids 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:
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 únicodepends_on mínimo — só quando filha literalmente precisa do output do paisubtask_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:
## 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 ids existentes
ids ú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).
