| name | break |
| description | Decompor documento de spec em tasks atômicas ordenadas — protótipo visual sempre antes de comportamento |
| triggers | ["break","/break","decompor spec","quebrar em tasks","criar issues"] |
| globs | ["docs/spec/*.md"] |
/break — Decomposição de Spec em Tasks
Regra de Ouro: Uma task = uma coisa verificável. Protótipo visual antes de comportamento.
Quando Usar
OBRIGATÓRIO após aprovação do /spec. Não executar sem spec aprovada.
Por Que Isso Importa
LLMs perdem qualidade de entrega quando uma task é grande demais. Com contexto lotado, o modelo começa a adivinhar, duplicar código e perder coerência entre arquivos. Decompor em tasks atômicas mantém o contexto focado e verificável.
Além disso, implementar comportamento em uma tela que o usuário ainda não aprovou é desperdício garantido — o chamado "cobertor de pobre": cobre um lado, descobre o outro. Protótipo aprovado antes de lógica elimina esse ciclo de retrabalho.
Regras de Decomposição
- Máximo 5 arquivos por task — se precisar de mais, é sinal de que a task deve ser dividida
- Protótipo sempre primeiro — para cada página, criar task visual antes de qualquer comportamento
- Um comportamento por task — cada task de comportamento implementa uma única ação do usuário
- Dependência explícita — informar se uma task depende de outra antes de poder ser iniciada
- Critério verificável — sem "quando ficar bom"; critério deve ser testável objetivamente
Processo
Step 1: Ler a Spec
cat docs/spec/YYYY-MM-DD-[nome].md
Identificar: páginas/telas, comportamentos por página, regras de negócio, modelos de dados.
Step 2: Gerar Task List
Para cada página listada na spec:
- Criar uma task de protótipo visual (sem lógica)
- Criar uma task por comportamento descrito na spec (após o protótipo)
Ordenar: todos os protótipos antes dos comportamentos dependentes.
Step 3: Formato de Output
Usar o seguinte template para cada task:
## TASK-001: [Página X] — Protótipo Visual
- **Tipo**: `prototype`
- **Página**: [nome da página]
- **FAZER**: Criar tela visual sem lógica (HTML/Blade/Livewire layout)
- **NÃO FAZER**: Nenhuma lógica de backend, sem queries, sem wire:model funcional
- **Arquivos**: [lista máx. 5 arquivos]
- **Critério**: Tela renderiza sem erro 500. Visual aprovado pelo usuário.
- **Depende de**: nenhuma
## TASK-002: [Página X] — Comportamento: [ação do usuário]
- **Tipo**: `behavior`
- **Página**: [nome da página]
- **FAZER**: Implementar [ação específica e única]
- **NÃO FAZER**: [o que não toca nesta task]
- **Arquivos**: [lista máx. 5 arquivos]
- **Critério**: [verificação objetiva e testável]
- **Depende de**: TASK-001
Step 4: Salvar Task List
Salvar em .devorq/state/tasklist/YYYY-MM-DD-[nome].md dentro do projeto alvo.
Exemplo: .devorq/state/tasklist/2026-04-02-autenticacao-oauth.md
Step 5: Apresentar e Aguardar Confirmação
Apresentar a task list completa ao usuário com a pergunta:
Task list gerada e salva em .devorq/state/tasklist/[arquivo].md
Revise a ordem e granularidade:
- Alguma task está grande demais ou pequena demais?
- A ordem faz sentido para o seu fluxo de trabalho?
- Posso iniciar pela TASK-001?
[AGUARDANDO CONFIRMAÇÃO]
PARAR e aguardar confirmação explícita antes de iniciar qualquer task.
Fluxo de Execução por Task
Para cada task aprovada da lista, seguir obrigatoriamente:
/scope-guard → /pre-flight → tdd → /quality-gate → commit
Nunca iniciar a próxima task sem commit da anterior aprovado pelo quality-gate.
Débito que previne: Contexto explodido, código duplicado por falta de visibilidade, comportamento implementado em tela não aprovada
