| name | flow-task-implementation |
| description | Orienta a execução de uma tarefa de PRD — leitura ordenada de fontes, detecção de conflitos, construção de checklist de execução e captura de sinal pré-mudança. Use sempre que um implementer for iniciar uma tarefa nova. Não use para remediação de PR, tarefas sem spec formal, ou refatorações fora de PRD. |
| pipeline_stage | runtime |
| consumed_by | ["implementer"] |
| requires | ["tasks/prd-[slug]/[N]_task.md","tasks/prd-[slug]/prd.md","tasks/prd-[slug]/techspec.md"] |
| produces | [] |
Task Implementation Flow
Define a rotina obrigatória de grounding antes de escrever qualquer código.
Quando aplicar
Use esta skill no início de cada execução de tarefa, após carregar a skill flow-workflow-memory e antes de carregar a skill flow-stack-selector.
Fluxo obrigatório
1. Leitura ordenada das fontes
Leia nesta ordem EXATA:
{prd-dir}/[task]_task.md — spec da tarefa
{prd-dir}/prd.md — contexto de produto
{prd-dir}/techspec.md — decisões técnicas e arquitetura
{prd-dir}/adrs/*.md — ADRs relevantes (se existirem)
{prd-dir}/MEMORY.md — memória compartilhada (já lida via flow-workflow-memory)
{prd-dir}/memory/[task]_task.md — memória da tarefa (já lida via flow-workflow-memory)
- Commits recentes do repositório — para saber o que já foi feito
Não pule etapas. A ordem importa: o task spec define O QUÊ; PRD e techspec definem POR QUÊ e COMO; ADRs definem as restrições arquiteturais; memória traz contexto de execuções anteriores.
2. Detecção de conflitos
Após ler todas as fontes, verifique conflitos entre:
- Task spec vs. TechSpec
- Task spec vs. ADRs
- TechSpec vs. ADRs
- Memória compartilhada vs. qualquer fonte acima
Se houver conflito: PARE. Reporte o conflito ao orchestrator com:
- Fontes que conflitam
- Trecho literal de cada fonte
- Natureza do conflito (ex: "task exige X mas ADR-003 proíbe X")
NÃO prossiga para a implementação tentando adivinhar qual fonte prevalece. Conflitos não resolvidos são a maior fonte de retrabalho — veja registros recorrentes no quality-ledger.
3. Construção do checklist de execução
Extraia do task spec em um checklist numerado:
- Deliverables explícitos
- Critérios de aceitação
- Itens de
Validation, Test Plan ou Testing
- Dependências explícitas de outras tarefas
Imprima o checklist completo ANTES de começar a implementar — ele deve ficar visível para rastreabilidade.
Use o checklist como gate: marque cada item como feito conforme evidência é produzida. NÃO avance para a fase de verificação final até que todos os itens tenham sido endereçados.
4. Captura do sinal pré-mudança
Antes de modificar código, capture o sinal concreto que prova que a tarefa ainda NÃO está completa. Exemplos:
- "Teste
UserPermissionsTest#shouldReturn403WhenScopeInvalid falha com NPE"
- "Endpoint
GET /v1/users/{id}/permissions retorna 500 quando user não existe"
- "Build quebra em
AuthzService por símbolo IdempotencyKey não encontrado"
Se não conseguir reproduzir o sinal diretamente (ex: a tarefa é adicionar funcionalidade nova), capture o sinal mais próximo disponível (ex: "endpoint ainda não existe, curl retorna 404") e declare explicitamente a limitação.
5. Reconciliação do workspace
Antes de começar a editar:
- Rode
git status — trabalho não commitado pode indicar execução anterior incompleta
- Rode
git log --oneline -n 10 — verifique se a tarefa já foi parcialmente implementada
- Consulte
memory/[task]_task.md — se existir seção "Ready for Next Run", comece por ela
6. Escopo e disciplina
- Mantenha escopo estrito ao task spec
- Siga padrões do repositório e APIs reais das dependências
- Registre trabalho out-of-scope relevante como follow-up notes em
memory/[task]_task.md em vez de expandir silenciosamente a tarefa
- Se durante a implementação você descobrir que o task spec está errado, PARE e reporte — não conserte silenciosamente
Tratamento de erros
- Se alguma fonte obrigatória (task, PRD) estiver ausente, pare e reporte o caminho faltando antes de prosseguir
- Se o sinal pré-mudança não pode ser capturado mesmo em forma aproximada, registre essa limitação explícita no
memory/[task]_task.md
- Se a leitura de alguma fonte revelar que a tarefa já foi implementada (ex: commits anteriores cobrem todos os deliverables), reporte ao orchestrator em vez de duplicar trabalho
Checklist rápido
Antes de prosseguir para implementação, confirme: