Boas Práticas de Delegação e Orquestração Multi-Etapa

Um checklist para definir escopo, checkpoints e portões de revisão antes de delegar trabalhos multi-etapa.

Esta página reúne as práticas de toda esta seção - declarar um objetivo em vez de uma instrução única, dividir uma grande solicitação em um plano, colocar checkpoints, decidir o quão completamente delegar, executar um ciclo de refinamento iterativo, encadear padrões de orquestração e reconhecer modos de falha - em um único checklist que você pode aplicar antes e durante uma tarefa delegada.

Como Usar Este Checklist

• Percorra as seções em ordem nas primeiras vezes: defina o escopo do objetivo, planeje as etapas, posicione os portões e, em seguida, decida o quão flexível executá-lo.
• Para uma tarefa pequena de duas ou três partes, revise as seções relevantes em vez de aplicar formalmente cada item - a escala do checklist deve corresponder à escala da tarefa.
• Revise os itens "Durante a Tarefa" sempre que uma tarefa delegada se estender ou começar a parecer incerta, não apenas no início.
• Trate uma falha repetida no mesmo item como um sinal para ajustar seus hábitos padrão, não apenas para corrigir a tarefa em questão.

A - Definindo o Escopo do Objetivo Antes de Delegar

• Declare o resultado, não apenas a primeira etapa. Descreva como é "feito" em vez de emitir uma instrução de cada vez - Claude só pode construir um plano útil a partir de um objetivo, não de uma sequência de solicitações desconectadas.
• Nomeie as restrições de antemão. Duração, tom, público, formato e qualquer coisa que não deva mudar pertencem à primeira mensagem, pois uma restrição descoberta no meio da tarefa geralmente significa refazer o trabalho que já aconteceu.
• Peça o plano antes que qualquer trabalho comece. Uma linha como "diga-me seu plano antes de começar" não custa nada e transforma uma solicitação única em uma solicitação multi-etapa revisável.
• Combine o tamanho da solicitação com a facilidade com que você pode verificar o resultado. Um objetivo que você não consegue verificar facilmente quando ele retorna é um sinal de que você precisa de mais checkpoints, não menos.
• Indique quais partes têm baixo risco e quais precisam do seu julgamento, na mesma mensagem. Misturar delegação total para as partes seguras com um loop apertado para as partes arriscadas evita tanto o excesso de checkpoints em trabalhos triviais quanto a falta de checkpoints na parte que realmente importa.

B - Transformando a Solicitação em um Plano

• Peça um plano numerado, não um parágrafo de intenções. Um plano que você pode ler em dez segundos é algo que você pode corrigir em uma mensagem; uma descrição em parágrafo geralmente não é.
• Leia o plano antes de aprová-lo, sempre. Ignorar a etapa do plano anula o propósito de pedi-lo - o plano é o ponto mais barato em toda a tarefa para capturar uma suposição errada.
• Conteste uma etapa que seja muito grande. Se uma linha do plano está realmente fazendo três coisas, peça a Claude para dividi-la antes que a execução comece, não depois que você vir o resultado combinado.
• Confirme se a ordem das etapas do plano corresponde às suas prioridades de revisão. Se a parte com a qual você mais se importa acontece por último, reordene-a ou adicione um checkpoint anterior que a toque.
• Permita que um plano referencie outras ferramentas quando fizer sentido. Uma etapa não precisa ser uma instrução plana - ela pode chamar uma Skill para uma subtarefa especializada ou entregar uma peça de trabalho recorrente a uma rotina agendada.

C - Posicionando Checkpoints e Portões de Revisão

• Coloque um checkpoint antes de qualquer etapa que seja cara de refazer. Decisões de estrutura e esboço são baratas de corrigir no início e caras de corrigir após um rascunho completo ser construído sobre elas.
• Coloque um checkpoint antes de qualquer etapa que você não possa verificar facilmente após o fato. Se você não conseguir distinguir um resultado errado de um certo no final, você precisa olhar mais cedo, não mais tarde.
• Escopo cada checkpoint para um tipo de mudança. Revisar estrutura, depois conteúdo, depois polimento separadamente é mais fácil do que tentar julgar os três em uma única passagem no final.
• Pule o checkpoint em etapas genuinamente de baixo risco e facilmente reversíveis. Nem toda etapa precisa de uma pausa - reserve portões para os momentos em que seu julgamento ou o custo de refazer realmente importam.
• Indique explicitamente onde Claude deve parar e esperar. "Pare aí e espere minha autorização" remove qualquer ambiguidade sobre se uma etapa é um ponto de pausa ou uma passagem direta.

D - Decidindo o Quão Completamente Delegar

• Pondere a reversibilidade antes das apostas antes da velocidade. Uma tarefa que é fácil de desfazer pode tolerar delegação total, mesmo que importe muito; uma tarefa difícil de desfazer merece um loop apertado, mesmo que pareça menor.
• Opte por mais checkpoints em tipos de tarefas desconhecidos. Depois de ver um tipo de tarefa ter sucesso algumas vezes com delegação total, é razoável afrouxar o loop em instâncias futuras dele.
• Trate a delegação como um dial, não como uma configuração fixa por projeto. A quantidade certa de supervisão pode mudar de parte para parte dentro da mesma tarefa, não apenas de tarefa para tarefa.
• Reavalie no meio da tarefa se o trabalho se mostrar mais arriscado do que o esperado. É aceitável adicionar um checkpoint no meio de um plano que começou como totalmente delegado, se uma etapa se mostrar mais importante do que você pensou inicialmente.
• Não confunda menos checkpoints com menos controle. Você ainda define o objetivo e as restrições de qualquer maneira - a delegação total apenas muda quando você olha, não se você está guiando.

E - Executando o Ciclo de Refinamento Iterativo

• Trate o primeiro resultado como um rascunho, não como um entregável. Esperar perfeição em uma única passagem coloca pressão no prompt inicial que um ciclo de revisão curto pode absorver de forma mais barata.
• Dê feedback específico, não feedback geral. "Muito formal, corte o segundo parágrafo pela metade" produz uma revisão melhor do que "melhore" - nomeie a coisa exata a ser mudada.
• Limite o número de rodadas de refinamento que você espera. Se um rascunho não convergir após duas ou três rodadas de feedback específico, o objetivo ou as restrições da Seção A provavelmente precisarão ser redefinidos, não apenas o feedback.
• Incorpore o refinamento ao plano como sua própria etapa, não como uma surpresa. Um plano que já inclui "rascunho, obter feedback, revisar" define as expectativas corretamente desde o início.

F - Orquestrando Entre Skills e Rotinas

• Encadeie etapas deliberadamente, não como uma reflexão tardia. Decida de antemão qual etapa deve chamar uma Skill, qual deve passar para uma rotina agendada e qual permanece como um prompt simples, em vez de descobrir a necessidade no meio da tarefa.
• Mantenha um checkpoint em cada passagem entre ferramentas. A junção entre um plano delegado e uma Skill ou rotina é um local comum para perda de contexto - uma revisão rápida nessa junção a detecta cedo.
• Reutilize uma cadeia de trabalho em vez de reconstruí-la a cada vez. Uma vez que um padrão de orquestração tenha se mostrado confiável, trate-o como um modelo que você adapta, não como um caso único que você reinventa.
• Mantenha o objetivo geral visível mesmo quando as etapas são delegadas a outras ferramentas. Um plano encadeado ainda é um plano - perder de vista o objetivo original entre as passagens é como a deriva começa.

G - Observando Modos de Falha

• Peça um resumo em qualquer checkpoint de uma tarefa longa. "Resuma o que você entende que seja o objetivo e o que você fez até agora" é uma maneira barata de expor a deriva antes que ela se acumule em mais etapas.
• Trate um fosso crescente entre o plano e a saída como um sinal de parada. Se o que Claude está produzindo não corresponde mais ao plano que você aprovou, pause e realinhe antes de deixá-lo continuar.
• Nunca deixe uma execução totalmente delegada terminar sem uma verificação final contra o objetivo original. Sem checkpoints no meio da tarefa, ainda significa um checkpoint no final - pular isso é como os erros passam despercebidos.
• Corrija a deriva em uma mensagem em vez de começar de novo. Um resumo que revela uma incompatibilidade é geralmente uma correção de uma linha no ponto em que é detectada, e uma muito maior se for detectada apenas no final.
• Registre o modo de falha, não apenas a correção, quando algo der errado. Notar que um tipo particular de tarefa tende a derivar após a etapa três, por exemplo, diz a você onde adicionar um checkpoint permanente na próxima vez.

Aplicando o Checklist em Ordem

• Seções A-C (antes do início da tarefa): escopo, planejamento e posicionamento de portões são as correções mais baratas que você fará - acerte-as antes que qualquer trabalho real aconteça.
• Seções D-E (enquanto a tarefa está em andamento): o dial de delegação e o ciclo de refinamento são decisões que você continua revisitando à medida que a tarefa se desenrola, não decisões que você toma uma vez e esquece.
• Seções F-G (à medida que as tarefas crescem): orquestração e consciência de modos de falha são mais importantes quando uma tarefa encadeia várias ferramentas ou dura tempo suficiente para que pequenos mal-entendidos se acumulem.

FAQs

Relacionados

• Como é a Delegação Multi-Etapa com Claude - o modelo mental que este checklist assume.
• Noções Básicas de Delegação Multi-Etapa - exemplos práticos de objetivos, planos e checkpoints.
• Dividindo uma Tarefa Grande em um Plano que Claude Pode Executar - as práticas de planejamento por trás da Seção B.
• Checkpoints e Portões de Revisão Humana em um Fluxo de Trabalho Delegado - as práticas de posicionamento de portões por trás da Seção C.
• Quando Delegar Totalmente vs Manter Claude em um Loop Apertado - o framework de dial de delegação por trás da Seção D.
• Percorrendo um Ciclo de Refinamento Iterativo com Claude - o ciclo de refinamento por trás da Seção E.
• Padrões Comuns de Orquestração para Encadear Skills e Rotinas - os padrões de encadeamento por trás da Seção F.
• Modos de Falha Quando a Delegação Dá Errado - os padrões de deriva e falha silenciosa por trás da Seção G.

Versões de Stack: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão) e Claude Haiku 4.5. Nomes de modelos, preços e recursos de produtos mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.