Disponibilidade de material de apoio

Este texto do catálogo contém as orientações inline abaixo, mas não inclui os seguintes caminhos de suporte. São pré-requisitos externos, não arquivos agrupados:

• <support-root>/references/orchestration-patterns.md

Obtenha o material necessário da fonte upstream declarada ou de uma instalação fornecida pelo usuário dessa fonte. Resolva cada caminho em relação a essa instalação, inspecione seu conteúdo e verifique quaisquer licenças e pré-requisitos de execução aplicáveis. Não execute um comando nem afirme que um procedimento referenciado foi seguido até que seu arquivo necessário exista. Não fabrique os scripts ausentes nem trate um arquivo não relacionado com o mesmo nome como equivalente. Etapas independentes totalmente documentadas aqui podem prosseguir dentro do escopo autorizado do usuário; relate qualquer etapa dependente como indisponível.

Desenvolvimento Guiado por Dúvida

Visão Geral

Uma resposta confiante não é uma resposta correta. Longas sessões acumulam contexto que silenciosamente transforma suposições em "fatos" sem que ninguém perceba. Desenvolvimento guiado por dúvida é a disciplina de materializar um revisor de contexto fresco — enviesado para desprovar, não aprovar — antes que qualquer saída não trivial se estabeleça.

Isso não é /review. /review é um veredito sobre um artefato finalizado. Esta é uma postura em andamento: decisões não triviais são examinadas enquanto a correção de curso ainda é barata.

Quando Usar

Uma decisão é não trivial quando pelo menos uma das seguintes condições é verdadeira:

• Introduz ou modifica lógica de ramificação
• Cruza um limite de módulo ou serviço
• Afirma uma propriedade que o sistema de tipos ou compilador não pode verificar (segurança de thread, idempotência, ordenação, invariantes)
• Sua correção depende de contexto que o leitor futuro não pode ver
• Seu raio de explosão é irreversível (implantação em produção, migração de dados, alteração de API pública)

Aplique a habilidade quando:

• Prestes a tomar uma decisão arquitetural sob incerteza
• Prestes a confirmar código não trivial
• Prestes a afirmar um fato não óbvio ("isso é seguro", "isso escala", "isso corresponde à especificação")
• Trabalhando em código que você não entende completamente

Quando NÃO usar:

• Operações mecânicas (renomear, formatar, mover arquivos)
• Seguindo uma instrução clara e inequívoca do usuário
• Lendo ou resumindo código existente
• Mudanças de uma linha com correção óbvia
• Operações puras de ferramentas (executando testes, listando arquivos)
• O usuário solicitou explicitamente velocidade em vez de verificação

Se você duvida de cada tecla pressionada, você não envia nada. A habilidade se aplica apenas a decisões não triviais, conforme definido acima.

Carregando Restrições

Esta habilidade é projetada para o orquestrador da sessão principal, onde a Etapa 3 (DÚVIDA, detalhada abaixo) pode gerar um revisor de contexto fresco.

• NÃO adicione esta habilidade ao frontmatter skills: de uma persona. Uma persona que segue a Etapa 3 geraria outra persona — o anti-padrão de orquestração explicitamente proibido por references/orchestration-patterns.md ("personas não invocam outras personas").
• Se você se encontrar aplicando esta habilidade de dentro de um contexto de subagente (onde Claude Code impede a geração aninhada de subagentes): o caminho preferido é informar ao usuário que o desenvolvimento guiado por dúvida não pode ser executado aninhado e deixar a sessão principal lidar com isso. Como último recurso, existe um fallback degradado de autoquestionamento — reescreva ARTEFATO + CONTRATO como um novo prompt de autoquestionamento com um separador mental rígido do seu raciocínio anterior e percorra as Etapas 1-5. Isso não é uma revisão de contexto fresco (você carrega seu próprio contexto), então marque o resultado como degradado e prefira a escalada sempre que o usuário for alcançável.

O Processo

Copie esta lista de verificação ao aplicar a habilidade:

Doubt cycle:
- [ ] Step 1: CLAIM — wrote the claim + why-it-matters
- [ ] Step 2: EXTRACT — isolated artifact + contract, stripped reasoning
- [ ] Step 3: DOUBT — invoked fresh-context reviewer with adversarial prompt
- [ ] Step 4: RECONCILE — classified every finding against the artifact text
- [ ] Step 5: STOP — met stop condition (trivial findings, 3 cycles, or user override)

Etapa 1: REIVINDICAR — Apresentar o que se estabelece

Nomeie a decisão em duas ou três linhas:

CLAIM: "The new caching layer is thread-safe under the
        read-heavy workload described in the spec."
WHY THIS MATTERS: a race here corrupts user data and is
                  hard to detect in QA.

Se você não consegue escrever a reivindicação de forma tão compacta, você tem uma impressão, não uma decisão. Apresente-a antes de examiná-la.

Etapa 2: EXTRAIR — Menor unidade revisável

…