Criar Tasks

Restrições Inegociáveis

• NÃO IMPLEMENTE NADA. Esta skill produz apenas planejamento; código real é responsabilidade da skill executar-task.
• NÃO GERE ARQUIVO ALGUM antes de apresentar a lista de tarefas high-level (apenas títulos X.0 e dependências) e receber aprovação explícita do usuário.
• Toda tarefa principal deve ser um entregável funcional e incremental.
• Toda tarefa principal deve possuir ao menos uma subtarefa de testes que garanta o objetivo de negócio.
• Toda tarefa principal deve ser classificada com complexidade (baixa / media / alta / critica) usando a rubrica abaixo. Tarefas sem complexidade declarada são rejeitadas pelo checklist de qualidade.
• Não duplicar conteúdo de implementação que já está na Tech Spec — referenciar techspec.md e .claude/rules/*.
• Respeitar o teto de 15 tarefas principais; quando exceder, agrupar logicamente.
• Numeração obrigatória: X.0 para tarefas principais, X.Y para subtarefas.
• Não alterar a estrutura dos templates em assets/.

Rubrica de Complexidade

Use esta rubrica para classificar cada tarefa principal X.0. Quando dois critérios apontarem para níveis diferentes, prevalece o mais alto.

Tarefas critica exigem subtarefa explícita de rollback/validação (já obrigatória para itens CRÍTICOS de Investigação) e devem ser sinalizadas no resumo final ao usuário.

Procedimentos

Passo 1: Identificar Documento-Fonte (Obrigatório)

1. Determine o tipo do documento-fonte (PRD, Investigação ou Spike). Se o usuário não especificar, pergunte via AskUserQuestion.

2. Resolva o caminho conforme a tabela:

   Tipo	Documento-fonte	Tech Spec	Diretório de saída
   PRD	./docs/tasks/prd-[nome]/prd.md	./docs/tasks/prd-[nome]/techspec.md	./docs/tasks/prd-[nome]/
   Investigação	./docs/tasks/investigacao-[nome]/investigacao.md	./docs/tasks/investigacao-[nome]/techspec.md	./docs/tasks/investigacao-[nome]/
   Spike	./docs/tasks/spike-[nome]/spike.md	./docs/tasks/spike-[nome]/techspec.md	./docs/tasks/spike-[nome]/

3. Se o usuário informou apenas o nome da funcionalidade, liste ./docs/tasks/ via Bash (ls ./docs/tasks/) e identifique o(s) diretório(s) candidato(s); confirme com o usuário quando houver ambiguidade.

4. Confirme via Bash (ls) que ambos os arquivos (documento-fonte e techspec.md) existem no diretório escolhido. Se faltar a Tech Spec, interrompa e instrua o usuário a executar a skill criar-techspec antes.

Passo 2: Ler e Extrair Contexto (Obrigatório — não pule)

1. Leia o documento-fonte completo via Read.
2. Leia a Tech Spec completa via Read.
3. Extraia o conteúdo conforme o tipo:
   • PRD: requisitos funcionais priorizados, decisões técnicas, métricas de sucesso, componentes principais e sequenciamento sugerido na Tech Spec.
   • Investigação: itens priorizados (P0, P1, P2, P3) com IDs (ex.: INV-001), severidades, dependências entre correções, propostas de solução, riscos e necessidades de rollback.
   • Spike: opção recomendada (com nível de confiança Alto/Médio/Baixo), achados, evidências, trade-offs, perguntas em aberto e componentes definidos na Tech Spec.
4. Leia CLAUDE.md e os arquivos relevantes em .claude/rules/ (code-style, naming-conventions, controller-patterns) para sustentar dependências técnicas e faixas de EnumErro.

Passo 3: Esboçar Tarefas High-Level (Obrigatório)

1. Liste mentalmente as tarefas principais (X.0) com:
   • Título curto e orientado a entregável.
   • Tipo (Backend / Frontend / Infra / Teste / Refactor / Validação).
   • Complexidade (baixa / media / alta / critica) conforme a rubrica acima.
   • Dependências em outras tarefas (X.0).
2. Aplique o agrupamento conforme o tipo do documento-fonte:
   • PRD: agrupar por entregável lógico; ordenar backend → frontend → E2E.
   • Investigação: agrupar por prioridade (P0 → P1 → P2 → P3); respeitar dependências entre correções; planejar subtarefa de validação/rollback para itens CRÍTICOS; referenciar IDs (INV-XXX) nos títulos.
   • Spike: agrupar por componente técnico definido na Tech Spec; planejar tarefa exploratória/PoC para perguntas em aberto e para spikes com confiança Média ou Baixa.
3. Garanta que o total de tarefas principais ≤ 15; quando exceder, consolide.

Passo 4: Apresentar Lista High-Level para Aprovação (Obrigatório, bloqueante)

1. Envie ao usuário apenas em texto (sem Write) a lista numerada X.0 com título, tipo, complexidade e dependências. Destaque explicitamente as tarefas classificadas como critica.
2. Use AskUserQuestion perguntando se aprova a lista, deseja ajustes ou prefere remover/agrupar tarefas.
3. Não prossiga ao Passo 5 enquanto não houver aprovação explícita ou ajustes incorporados.

Passo 5: Detalhar Subtarefas e Critérios (Obrigatório)

1. Para cada tarefa principal aprovada, defina:
   • Subtarefas no formato X.Y (implementação + testes; rollback quando aplicável).
   • Arquivos a criar, modificar e usar como referência (use Grep/Read para confirmar caminhos reais antes de listar).
   • Critérios de aceite funcionais e técnicos verificáveis.
   • Cenários "Deve" e "Não deve" para testes unitários, citando framework xUnit + AutoDomainData + FakeItEasy e padrão MetodoNome_Condicao_ResultadoEsperado.
   • Cenários de teste de integração quando aplicável; caso contrário, justificativa explícita.
2. Verifique a faixa de EnumErro por módulo em .claude/rules/controller-patterns.md antes de prescrever novos códigos.
3. Para migrações EF, exija o padrão de nome DDMMAAAA-acao-descricao.
4. Para itens CRÍTICOS de Investigação ou tarefas classificadas como critica, adicione subtarefa de rollback com sinais de regressão e comando de reversão.

Passo 6: Gerar tasks.md (Obrigatório)

1. Leia assets/tasks-template.md e replique a estrutura sem alterar a ordem das seções.
2. Preencha:
   • Cabeçalho com tipo do documento-fonte, caminhos e total de tarefas.
   • Visão geral curta (1 a 3 parágrafos) referenciando — sem duplicar — o documento-fonte e a Tech Spec.
   • Critérios globais de aceite (incluindo dotnet test e conformidade com .claude/rules/).
   • Sequenciamento em uma linha.
   • Seção Adaptações por Tipo de Documento-Fonte preservando apenas a subseção aplicável (remover as outras).
   • Seção Fora de Escopo listando explicitamente itens adiados.
   • Seção Referências apontando para documento-fonte, Tech Spec e regras relevantes.
3. Salve via Write em [diretório-de-saída]/tasks.md.
4. Se já existir tasks.md no destino, confirme com o usuário antes de sobrescrever; oferecer sufixo -v2 quando o usuário preferir preservar a versão anterior.

Passo 7: Gerar Arquivos Individuais [num]_task.md (Obrigatório)

1. Leia assets/task-template.md.
2. Para cada tarefa principal X.0, gere [X]_task.md no mesmo diretório usando o template e preenchendo:
   • Cabeçalho com documento-fonte, Tech Spec (seção referenciada), tipo, dependências e status.
   • Objetivo (1 a 3 frases) sem duplicar a Tech Spec.
   • Escopo Inclui / Não inclui.
   • Tabela de subtarefas X.Y.
   • Arquivos afetados (criar / modificar / referência) com caminhos reais verificados.
   • Critérios de aceite mensuráveis.
   • Estratégia de testes unitários e de integração (ou justificativa de não aplicabilidade).
   • Notas de implementação curtas, sempre referenciando a Tech Spec.
   • Bloco de rollback apenas para itens CRÍTICOS de Investigação.
   • Validação pós-implementação com comandos dotnet build e dotnet test --filter.
3. Confirme via Bash (ls) que todos os arquivos foram criados conforme a tabela do tasks.md.

Passo 8: Validar com o Checklist de Qualidade (Obrigatório)

1. Leia references/quality-checklist.md.
2. Verifique cada item obrigatório contra os artefatos gerados.
3. Se algum item falhar, retorne ao Passo correspondente, corrija e revalide antes de reportar.

Passo 9: Reportar Resultados (Obrigatório)

1. Informe o caminho completo de tasks.md e a quantidade de arquivos [num]_task.md gerados.
2. Resuma em 3 a 5 linhas: tipo do documento-fonte, agrupamento adotado, total de tarefas, dependências-chave e marcos.
3. NÃO anexe o conteúdo completo dos arquivos na resposta — apenas caminhos e resumo.
4. Reforce explicitamente: "Implementação ainda não iniciada — use a skill executar-task para começar."

Helpers Bundled

• assets/tasks-template.md — read-only. Estrutura canônica de tasks.md. Replicar sem alterar a ordem das seções.
• assets/task-template.md — read-only. Estrutura canônica de cada [num]_task.md. Replicar sem alterar campos obrigatórios.
• references/quality-checklist.md — read-only. Auditoria final do Passo 8.

Tratamento de Erros

• Documento-fonte ausente no caminho esperado: liste o conteúdo de ./docs/tasks/ via Bash e peça ao usuário para confirmar; nunca invente o caminho.
• Tech Spec ausente: interrompa o fluxo e instrua o usuário a executar a skill criar-techspec antes de prosseguir.
• Usuário não aprovou a lista high-level: repita o Passo 4 com a lista ajustada; não gere arquivos enquanto não houver aprovação.
• Mais de 15 tarefas principais necessárias: consolide tarefas afins e justifique o agrupamento; em último caso, peça ao usuário para priorizar quais tarefas ficam fora do escopo atual.
• tasks.md já existe no destino: confirme sobrescrita ou use sufixo -v2; nunca apague o arquivo anterior sem confirmação.
• Caminho de arquivo a criar/modificar não encontrado durante o detalhamento: marque como "a definir na implementação" e registre uma subtarefa específica para validação do caminho — não invente paths.
• Item CRÍTICO de Investigação sem estratégia de rollback factível: rebaixe o item para nota de risco na própria tarefa e sinalize ao usuário antes de gerar tasks.md.