Get Tasks

Visão Geral

get-tasks converte um PRD aprovado em um conjunto executável de tarefas. Cada tarefa é escrita em seu próprio arquivo, dimensionada para caber em uma única sessão focada, ordenada por dependência e acompanhada de critérios de aceitação, etapas de validação, uma lista de bloqueios e um procedimento de rollback.

A razão pela qual isso existe como um skill próprio: um PRD não é um plano. Um PRD declara o que o sistema faz e por quê. Ele não diz nada sobre a ordem do trabalho, o que pode ser construído em paralelo, onde estão as partes arriscadas, ou como provar que uma fatia está concluída. Transformar um PRD diretamente em código produz ou uma mudança heroica de passagem única ou uma ordem arbitrária que quebra no meio.

get-tasks fornece a camada que faltava. Ele lê o PRD, mapeia a verdadeira estrutura de dependência, corta o trabalho em fatias verticais e escreve cada fatia como um artefato independente que um agente (ou um humano) pode pegar sem reler todo o PRD.

Este skill se baseia em três fontes:

Decomposição baseada em dependência e fatias verticais — construir um grafo de dependência, fatiar verticalmente em vez de horizontalmente, dimensionar cada tarefa e colocar pontos de verificação. Isso é o que torna a ordem correta.
Execução orientada por validação — toda tarefa declara como será verificada em vários tipos de validação, não apenas "testes passam", e carrega um procedimento de replanejamento para quando uma etapa falha.
Arestas de bloqueio e tracer bullets — cada tarefa declara explicitamente o que a bloqueia, para que qualquer tarefa cujos bloqueadores estejam concluídos possa começar imediatamente.

A saída é um diretório de arquivos de tarefa: tasks/<nome>/task-01.md, task-02.md e assim por diante, numerados em ordem de dependência, mais tasks/<nome>/plan.md indexando-os. Tarefas bloqueadoras recebem os números baixos.

Escopo deste Skill

get-tasks é deliberadamente abrangente. Ele absorve o que vários skills mais restritos faziam parcialmente cada um, para que um usuário precise apenas de um skill para ir de um PRD aprovado a um plano executável e rastreável. Tudo aqui é relevante para esse único trabalho:

Preocupação	Onde é tratada
Ler o PRD e extrair compromissos	Fase 1
Estrutura de dependência e ordenação	Fase 2
Fatias verticais e tracer bullets	Fase 3
Refatorações amplas (expandir, migrar, contrair)	Fase 3
Especificação por tarefa	Fase 4
Regras de dimensionamento e divisão	Fase 5
Pontos de verificação e portões	Fase 5
Classificação de paralelização	Taxonomia de Paralelização
Resumo do plano legível por humanos, riscos, decisões	Fase 6
Rastreador vs. alvo de arquivo	Alvo da Lista de Tarefas
Aprovação do usuário antes de escrever	Fase 7
Escrever, sincronizar e verificar artefatos	Fase 8
Lidar com falha e replanejamento	Replanejamento Quando uma Tarefa Falha

É longo por design. O comprimento é o ponto: uma decomposição que deixa qualquer um desses implícitos produz tarefas que parecem concluídas e não estão. Se você for tentado a pular para o modelo, leia as Fases 2, 3 e 5 — essas são onde as decomposições realmente falham.

O que este skill não faz: ele não escreve código, não executa as tarefas e não substitui o PRD. Ele converte um documento em um conjunto de documentos.

Quando Usar

Use este skill quando:

Um PRD, especificação ou documento de requisitos existe e o trabalho precisa se tornar tarefas executáveis
O usuário disser "get tasks", "breakdown PRD", "pecah jadi task", "bikin task list" ou "turn this into tasks"
Uma tarefa parece grande demais para começar e precisa ser decomposta
Você precisar estimar escopo, ordenar o trabalho ou encontrar o que pode ser executado em paralelo
Você está prestes a implementar algo que toca mais do que um punhado de arquivos e não existe nenhuma lista de tarefas

Quando NÃO usar:

Ainda não existe um PRD — execute get-prd primeiro, depois volte
A mudança é uma única tarefa por qualquer medida (um arquivo, uma edição óbvia) — apenas faça
Uma decomposição completa de tarefas já existe em tasks/ e você está pronto para implementar — prossiga diretamente para executar as tarefas em sequência

O Processo

get-tasks é executado em nove fases. Cada fase tem uma condição de saída. Não avance além de uma fase cuja condição de saída não foi atendida.

0. Localizar o PRD           -> qual documento é a fonte?
1. Ler e extrair             -> o que o PRD nos compromete a fazer?
2. Grafo de dependência      -> o que depende do quê?
3. Fatias verticais          -> tracer bullets, não camadas horizontais
4. Escrever cada tarefa      -> um arquivo por tarefa, completamente especificada
5. Ordenar, dimensionar, verificar -> sequência, tamanho e portões de verificação
6. Escrever o documento de plano -> o resumo legível por humanos que indexa as tarefas
7. Perguntar ao usuário       -> granularidade, arestas de bloqueio, mesclar ou dividir
8. Escrever e verificar       -> arquivos no disco, todos sincronizados, validadores verdes

Princípios Universais para Decomposição de Tarefas

Ritmo de Linguagem Natural: Apresente a decomposição e os resumos conversacionais no idioma que o usuário fala (indonésio ou inglês), mantendo nomes de arquivo, termos de git e tokens de código padrão (task-01.md, branch, commit, TDD).
Pronto para Execução Autônoma: Cada arquivo de tarefa gerado em tasks/<recurso>/task-*.md deve ser completamente autocontido. Qualquer agente de codificação deve ser capaz de ler apenas aquele único arquivo de tarefa, saber quais arquivos editar, quais testes executar e qual definição de concluído deve ser satisfeita sem adivinhar.
Fatias Verticais sobre Camadas Horizontais: Nunca crie tarefas que são puramente "configurar backend" ou "configurar frontend" isoladamente se elas não puderem ser verificadas de ponta a ponta. Fatia verticalmente (ex.: "Endpoint de SKU com Armazenamento e Consulta com Acionador de UI") para que cada tarefa entregue valor testável.

Planejamento é somente leitura. As Fases 0 a 7 produzem documentos e perguntas, não código. Não crie, edite ou exclua nenhum arquivo fonte durante essas fases. Escrever arquivos de tarefa em tasks/ é a única mudança no sistema de arquivos permitida antes que o usuário aprove. Se você se encontrar corrigindo um bug ou adicionando uma função enquanto decompõe o trabalho, pare: isso pertence à implementação pós-aprovação e pertence a uma tarefa que você ainda não escreveu.

Fase 0: Localizar o PRD

Encontre o documento fonte antes de fazer qualquer outra coisa.

Convenção primeiro. get-prd salva em docs/prd/<nome>.md. Procure lá primeiro.
Depois a pesquisa mais ampla. Se docs/prd/ estiver vazio, procure por um PRD que o usuário nomeie. Aceite um corpo de issue ou um documento de requisitos colado — o skill não está limitado a formato, apenas a extração na Fase 1 assume os nomes das seções do PRD.
Se houver mais de um candidato, não adivinhe. Liste-os e pergunte qual governa este trabalho.
Se nenhum existir, pare e diga. Não invente requisitos. Direcione o usuário para get-prd para uma passagem completa de entrevista a PRD.

Registre o caminho exato a partir do qual você está trabalhando. Cada fase posterior o referencia.

Para uma iniciativa multimódulo onde o PRD é dividido por id do módulo (docs/prd/identity.md, docs/prd/billing.md), confirme qual módulo esta decomposição cobre. Uma decomposição por módulo, na ordem de compilação que o mapa de capacidades declarou.

Condição de saída: um único documento fonte é identificado e seu caminho está registrado.

Fase 1: Ler e Extrair

Leia o PRD por completo. Em seguida, extraia, explicitamente, o material que impulsiona a decomposição:

Seção do PRD	O que você extrai dela
Objetivo	O estado final que toda tarefa atende em última instância
Histórias de Usuário	Os comportamentos observáveis que devem funcionar, critérios de aceitação candidatos
Decisões Técnicas	Módulos, interfaces, mudanças de esquema, contratos — estes definem limites reais entre tarefas
Estrutura do Projeto	Onde os artefatos vão, o que restringe "arquivos provavelmente tocados"
Comandos	Os comandos de verificação concretos que cada tarefa citará
Estratégia de Teste	O que conta como um bom teste aqui e onde os testes pertencem
Limites	Sempre / Pergunte Primeiro / Nunca — Itens "Nunca" se tornam restrições rígidas em cada tarefa
Fora do Escopo	Não-objetivos explícitos; nada aqui se torna uma tarefa
Critérios de Sucesso	O portão final; o último ponto de verificação verifica contra ele

Regras:

Não comece a fatiar ainda. Extração primeiro, decomposição segundo. Fatiar enquanto lê produz tarefas moldadas pela ordem em que você leu o documento.
Converta itens vagos em declarações verificáveis. Se o PRD disser "o dashboard deve ser rápido", o critério de aceitação da tarefa é um número, e se o PRD não deu nenhum número, apresente isso como um bloqueador em vez de escolher um silenciosamente.
Sinalize lacunas. Se uma seção Necessária estiver faltando ou vazia, nomeie-a. Uma Estratégia de Teste ausente significa que o bloco de verificação de cada tarefa será inventado depois; levante isso agora.
Nunca invente requisitos. Se o PRD não diz, não é uma tarefa.

Condição de saída: a tabela de extração está preenchida e qualquer lacuna foi levantada com o usuário.

Fase 2: Mapear o Grafo de Dependência

Antes de escrever uma única tarefa, mapeie o que depende do quê. Esta é a fase que determina a ordem e previne a classe mais cara de erro: construir um consumidor antes de seu produtor existir.

Desenhe o grafo. Concreto, não abstrato:

Esquema do banco de dados
    |
    +-- Modelos e tipos de API
    |       |
    |       +-- Endpoints de API
    |       |       |
    |       |       +-- Cliente de API do frontend
    |       |               |
    |       |               +-- Componentes de UI
    |       |
    |       +-- Lógica de validação
    |
    +-- Dados de seed e migrações

Regras:

As arestas apontam do produtor para o consumidor. Uma seta significa "o alvo precisa da fonte primeiro".
Sem ciclos. Se duas coisas precisarem uma da outra, elas são uma tarefa, ou a interface entre elas deve ser definida primeiro como sua própria tarefa.
Interfaces são limites. Quando duas tarefas se encontram em um contrato (um tipo, uma forma de endpoint, um esquema), defina o contrato na tarefa anterior e consuma-o na posterior. Nunca deixe ambas as tarefas inventá-lo independentemente.
Encontre a fronteira. A fronteira é toda tarefa cujos bloqueadores estão todos concluídos. É o que pode começar agora. Para uma cadeia linear, a fronteira tem uma tarefa de largura; para um projeto amplo, pode haver várias.
Nomeie as oportunidades paralelas e as sequências difíceis. Fatias independentes podem ser executadas em paralelo. Migrações, mudanças de estado compartilhado e qualquer coisa que toque o mesmo contrato devem ser sequenciais.

Condição de saída: um grafo de dependência existe, com uma fronteira clara e sem ciclos.

Fase 3: Fatiar Verticalmente

Corte o trabalho em tracer bullets: caminhos estreitos, mas completos, através de todas as camadas que o recurso precisa.

O fatiamento horizontal é o erro padrão. Parece organizado e não produz nada executável até a última tarefa:

Ruim (horizontal):
Tarefa 1: Construir todo o esquema do banco de dados
Tarefa 2: Construir todos os endpoints de API
Tarefa 3: Construir todos os componentes de UI
Tarefa 4: Conectar tudo

Ao final da Tarefa 3, nada funciona. Ninguém pode demonstrar nada. Uma suposição errada na Tarefa 1 é descoberta na Tarefa 4.

O fatiamento vertical produz software funcional a cada etapa:

Bom (vertical):
Tarefa 1: Um usuário pode criar uma conta   (esquema + API + UI para registro)
Tarefa 2: Um usuário pode fazer login        (esquema de autenticação + API + UI para login)
Tarefa 3: Um usuário pode criar uma tarefa   (esquema de tarefa + API + UI para criação)
Tarefa 4: Um usuário pode ver a lista de tarefas  (consulta + API + UI para visualização de lista)

Regras para uma boa fatia:

Ela corta por todas as camadas que o comportamento precisa — dados, lógica, interface, teste.
Ela é demonstrável ou verificável por si só. Se você não puder descrever como confirmar que funciona, não é uma fatia.
Ela cabe em uma sessão focada — aproximadamente uma janela de contexto nova.
Ela entrega comportamento, não estrutura. "Adicionar a tabela de usuários" não é uma fatia; "um usuário pode se registrar" é.

Refatorações amplas são a exceção. Uma refatoração ampla é uma mudança mecânica (renomear uma coluna, redigitar um símbolo compartilhado) cujo raio de alcance se espalha por toda a base de código, então nenhuma fatia vertical pode ficar verde. Não force isso em um tracer bullet. Sequencie como expandir, migrar, contrair:

Expandir — adicione a nova forma ao lado da antiga para que nada quebre.
Migrar — mova os locais de chamada em lotes dimensionados pelo raio de alcance (por pacote, por diretório), cada lote sua própria tarefa bloqueada pelo expandir, mantendo o build verde lote a lote porque a forma antiga ainda existe.
Contrair — exclua a forma antiga quando nenhum chamador permanecer, em uma tarefa bloqueada por cada lote de migração.

Quando mesmo os lotes não conseguem ficar verdes sozinhos, mantenha a mesma sequência, mas deixe-os compartilhar um branch de integração que todos bloqueiam uma tarefa final de integrar e verificar, onde o verde é prometido.

Condição de saída: cada parte do trabalho pertence a exatamente uma tarefa, e toda tarefa é uma fatia vertical ou uma etapa de refatoração ampla declarada.

Fase 4: Escrever Cada Tarefa

Escreva cada tarefa como seu próprio arquivo. Uma tarefa por arquivo, sempre — nunca um único documento combinado com todas as tarefas dentro.

Caminho de saída: tasks/<nome>/task-NN.md, onde <nome> corresponde ao nome do PRD (então um PRD em docs/prd/billing.md produz tasks/billing/task-01.md). Numere a partir de 01, em ordem de dependência — bloqueadores recebem os números baixos.

Modelo de arquivo de tarefa:

# Tarefa NN: <Título descritivo curto>

**Fonte:** docs/prd/<nome>.md — <seção do PRD que esta tarefa implementa>

**O que construir:** O comportamento de ponta a ponta que esta tarefa faz
funcionar, da perspectiva do usuário. Não uma lista de implementação
camada por camada. Se você não puder descrevê-lo como um comportamento que
um usuário ou chamador pode observar, reformule a tarefa.

## Critérios de aceitação

- [ ] <condição específica e testável>
- [ ] <condição específica e testável>

Cada critério deve ser verificável por alguém que não escreveu a tarefa.
"Funciona corretamente" não é um critério. "Um usuário pode registrar com um
email e senha e é redirecionado ao dashboard" é.

## Verificação

- [ ] Testes passam: <o comando de teste focado do repositório ou novo teste a escrever primeiro>
- [ ] Build sucede: <o comando de build do repositório>
- [ ] Saída corresponde: <padrão esperado ou artefato que deve existir>
- [ ] Sem regressões: <a suíte completa ou o subconjunto relevante>
- [ ] Qualidade e Segurança: <validação de entrada, limites de autenticação, segue padrões>

## Arestas de bloqueio

- **Bloqueado por:** Tarefa <X>, <Y>, <Z>
- **Bloqueia:** Tarefa <A>, <B>, <C>

Nenhuma implementação desta tarefa pode começar até que todas as tarefas
bloqueadoras estejam concluídas. Nenhuma tarefa que esta bloqueia pode
começar até que esta esteja concluída.

## Procedimento de rollback

- **Reverter commit:** `git revert <SHA esperado ou "último commit">`
- **Verificar limpeza:** Os dados gerados por esta tarefa são removidos?
  Os schemas retornam ao estado anterior?
- **Serviços afetados:** <serviço A, B — se aplicável>

Regras para escrever:

Comece escrevendo um modelo. A ordem de escrita segue a ordem de dependência: escreva a tarefa 01 antes da 02.
Um arquivo, uma tarefa. Nenhum arquivo contém mais de uma tarefa. Se você sentir a tentação de separar por cabeçalhos H2, pare e faça arquivos separados.
Cada tarefa é autocontida. A descrição e os critérios devem ser compreensíveis sem referência cruzada a outras tarefas. "Como a Tarefa 4, mas para administradores" não é autocontido.
Os critérios de aceitação devem ser binários. Verde ou vermelho. Nenhum critério dependente de interpretação.
Citar nomes de arquivo quando possível. Em vez de "atualizar o modelo", escreva "adicionar campo is_active a app/models/user.rb".
Nunca escreva a Tarefa 00. A numeração começa em 01; 00 implica uma tarefa introdutória que não faz nada criado.

Condição de saída: cada tarefa tem seu próprio arquivo seguindo o modelo, e todos os arquivos estão em tasks/<nome>/.

Fase 5: Ordenar, Dimensionar e Verificar

Após escrever, valide a estrutura geral:

Ordenação

Os números de tarefa correspondem à ordem topológica do grafo de dependência?
Toda aresta de bloqueio na tarefa posterior corresponde a uma linha "Bloqueia" na tarefa anterior? (Verifique em ambas as direções.)
Se duas tarefas não têm dependência entre si, elas estão no mesmo número? (Elas podem começar em paralelo.)

Dimensionamento

Cada tarefa cabe em uma janela de contexto fresca? Se uma explicação levar mais de 300 palavras para ser lida, a tarefa é muito grande.
Se uma tarefa for muito grande, divida. Se muito pequena, mescle com sua sucessora bloqueada — mas nunca mescle além de uma linha de dependência.
Um bom tamanho de tarefa é "um comportamento, implementado e verificado".

Pontos de verificação

Coloque pontos de verificação nos arquivos de tarefa onde o progresso pode ser validado:

Antes de começar: Todos os bloqueadores estão verdes?
Após a implementação: Testes passam, build passa, saída corresponde.
Após o merge: Sem regressões na suíte completa.
Para a última tarefa: Verifique contra os Critérios de Sucesso do PRD.

Registre qualquer ponto de verificação que o projeto precise. Um ponto de verificação não é um portão de aprovação; é um local onde o agente verifica o progresso antes de prosseguir.

Condição de saída: as tarefas estão ordenadas corretamente, cada uma tem um tamanho apropriado, e todo ponto de verificação necessário é explicitamente marcado.

Taxonomia de Paralelização

Anexe a cada tarefa uma tag de classificação de paralelização. Isso permite que um escalonador execute tarefas independentes simultaneamente:

Tag	Significado	Quando usar
`[P0]`	Nenhuma dependência; pode começar imediatamente	Tarefas cujos bloqueadores estão todos concluídos ou que não têm bloqueadores
`[P1]`	Dependência única; bloqueada por uma tarefa	Tarefas que esperam uma entrada específica
`[P2]`	Dependências múltiplas; bloqueada por várias tarefas	Tarefas no final de uma cadeia ou que exigem vários pré-requisitos
`[PX]`	Dependências de refatoração ampla; bloqueada por tarefas de expansão/migração	A etapa "Contrair" após todas as migrações estarem concluídas
`[PAR]`	Paralelo; pode ser executada simultaneamente com outras tarefas	Tarefas que não compartilham estado, arquivos ou contratos
`[SEQ]`	Sequencial; deve ser executada sozinha na ordem	Migrações, mudanças de esquema, qualquer coisa que exija bloqueio

Inclua a tag na linha de título, ex.:

# Tarefa 01: Criação de Conta de Usuário [P0]

A tag de paralelização informa a um executor se a tarefa está pronta para começar (P0), está esperando (P1, P2, PX) ou pode ser executada em paralelo com outras (PAR) ou deve ser sequencial (SEQ).

Fase 6: Escrever o Plano

Escreva tasks/<nome>/plan.md. Este documento é o índice legível por humanos e o resumo executivo de todas as tarefas:

# Plano: <Nome do Recurso ou Título do PRD>

**Fonte:** docs/prd/<nome>.md

## Resumo

<3-5 frases sobre o plano geral, o que ele entrega e a ordem>)

## Tarefas

| # | Título | Bloqueado por | Classificação de Paralelização |
|---|---|---|---|
| 01 | Criação de Conta de Usuário | — | P0 |
| 02 | Login de Usuário | 01 | P1 |
| 03 | Criação de Tarefa | 01, 02 | P2 |
| 04 | Visualização de Lista de Tarefas | 03 | P1 |

## Fronteira Atual

A fronteira é toda tarefa com `[P0]`. Execute essas tarefas primeiro, em
qualquer ordem.

## Riscos e Decisões

- **Risco:** A Tarefa 03 depende da Tarefa 01 e 02. Se 02 atrasar, 03 não
  pode começar.
- **Decisão:** A interface de autenticação é definida na Tarefa 02; nenhuma
  tarefa posterior a redefine.

## Dependências Externas

- <Apis, bibliotecas ou serviços que várias tarefas precisam>

Condição de saída: plan.md existe e indexa cada arquivo de tarefa com seu número, título e classificação de paralelização.

Fase 7: Perguntar ao Usuário

Antes de escrever qualquer coisa no disco, apresente o plano ao usuário e peça aprovação. Não escreva arquivos sem aprovação.

Apresente:

Um resumo do plano, incluindo o número de tarefas e a ordem
As tarefas da fronteira (P0) que podem começar imediatamente
Quaisquer tarefas que você acredita que podem ser muito grandes ou muito pequenas, com uma recomendação
As arestas de bloqueio — especialmente se o usuário pensou que duas tarefas eram independentes e não são

Pergunte especificamente:

Mesclar: Alguma tarefa deve ser combinada? (Nunca mescle além de uma dependência.)
Dividir: Alguma tarefa parece grande demais? (Se o usuário disser sim, divida e retorne ao plano.)
Pular: Alguma tarefa não precisa ser construída? (Se sim, remova-a e atualize as dependências.)

Não pergunte por tarefa — apenas destaque anômalos.

Condição de saída: o usuário disse "sim", "aprovado", "go" ou uma confirmação explícita equivalente. Não aceite silêncio ou "parece bom" sem uma resposta afirmativa clara.

Fase 8: Escrever e Verificar

Agora escreva os arquivos. Esta fase é mecanizada — nenhuma criatividade, nenhuma decisão. Apenas escreva o que as Fases 4, 5 e 6 especificaram.

Criar o diretório: mkdir -p tasks/<nome>
Escrever cada arquivo de tarefa: do número 01 em diante, escreva o modelo completo preenchido com os detalhes extraídos e as bordas de bloqueio da Fase 4.
Escrever o plano: escreva plan.md do esboço da Fase 6.
Verificar a integridade do arquivo: Cada tarefa bloqueadora tem uma linha "Bloqueia" correspondente na tarefa bloqueada? Cada tarefa bloqueadora tem uma linha "Bloqueia" na tarefa bloqueadora? Cada título corresponde a exatamente uma linha na tabela do plano?
Verificar a classificação de paralelização: Cada tarefa tem uma tag e a tag corresponde às suas arestas de bloqueio (bloqueadores não concluídos = não P0).

Se a verificação falhar, corrija. Se a correção exigir uma mudança na estrutura (por exemplo, uma tarefa esquecida), retorne à Fase 4, corrija, obtenha nova aprovação.

Condição de saída: Todos os arquivos estão no disco, a verificação do arquivo passa, o plano está completo e nenhuma tarefa tem um ponto de verificação faltante.

Alvo da Lista de Tarefas

Por padrão, get-tasks escreve arquivos de tarefa diretamente em tasks/<nome>/task-*.md. Para rastreamento visual, você também pode optar por criar uma issue no GitHub ou um item de quadro por tarefa, mas isso é secundário. O artefato de verdade é o arquivo de tarefa.

Para rastreamento, cada tarefa pode se tornar:

Um TODO comentado no código perto do local de implementação (ex.: // TODO(Tarefa-03): Adicionar validação de campo de email)
Uma issue no GitHub com o modelo de tarefa como corpo
Um cartão do Trello ou item do Linear com o título e lista de verificação de critérios de aceitação

O plano em plan.md é o mestre. Sincronize todos os outros rastreadores a partir do plano, e não o contrário.

Replanejamento Quando uma Tarefa Falha

Uma tarefa falha quando qualquer critério de aceitação ou verificação permanece vermelho após a conclusão pretendida da tarefa. Não ignore.

Avalie o escopo real. O trabalho foi maior do que o esperado? Um critério era inatingível?
Divida a tarefa. Se a tarefa falhou porque era grande demais, divida-a em subtarefas, cada uma com seu próprio critério de aceitação.
Anexe a subtarefa. Anexe as novas tarefas ao plano existente com números de continuação (ex.: task-03a.md, task-03b.md). Não renumere as tarefas existentes.
Atualize os bloqueadores. As novas tarefas herdam os bloqueadores da tarefa pai. A tarefa pai agora bloqueia suas subtarefas.
Mova a fronteira. A fronteira agora inclui quaisquer novas tarefas cujos bloqueadores estejam concluídos.
Obtenha aprovação. Apresente o replano ao usuário.

O replanejamento sempre segue este padrão. Se você vir uma tarefa repetidamente muito grande, você está errando o tamanho na Fase 5; ajuste sua intuição para sessões mais curtas.

Manutenção

Este skill é autocontido em um arquivo. Mantenha o modelo de tarefa e as seções de processo aqui. Se você adicionar uma nova fase, adicione-a à lista numerada na Visão Geral e expanda abaixo.

Se uma fase se tornar muito longa para ser lida em uma sessão, mova detalhes para uma subseção referenciada. Não remova a sequência da fase; a ordem de execução é o que previne erros.

Nota do tradutor técnico: Todo o conteúdo acima foi traduzido para o português, mantendo a formatação markdown original, nomes de comandos, arquivos, caminhos e tokens de código sem tradução, conforme as regras especificadas.

rizqinrr/get-tasks

O que é get-tasks?

Perguntar na sua IA favorita

Documentação