Pergunte se houver Ambiguidade

Quando Usar

Use esta habilidade quando uma solicitação tiver múltiplas interpretações plausíveis ou detalhes importantes (objetivo, escopo, restrições, ambiente ou segurança) estiverem pouco claros.

Quando NÃO Usar

Não use esta habilidade quando a solicitação já estiver clara, ou quando uma leitura rápida de descoberta de baixo risco puder responder aos detalhes faltantes.

Objetivo

Faça o conjunto mínimo de perguntas esclarecedoras necessárias para evitar trabalho incorreto; não comece a implementar até que as perguntas essenciais sejam respondidas (ou o usuário aprove explicitamente o prosseguimento com as suposições declaradas).

Fluxo de Trabalho

1) Decida se a solicitação está subespecificada

Trate uma solicitação como subespecificada se, após explorar como realizar o trabalho, um ou todos os seguintes itens não estiverem claros:

• Definir o objetivo (o que deve mudar vs. permanecer o mesmo)
• Definir "concluído" (critérios de aceitação, exemplos, casos extremos)
• Definir o escopo (quais arquivos/componentes/usuários estão incluídos/excluídos)
• Definir restrições (compatibilidade, desempenho, estilo, dependências, tempo)
• Identificar o ambiente (versões de linguagem/runtime, sistema operacional, executor de build/teste)
• Esclarecer segurança/reversibilidade (migração de dados, implantação/reversão, risco)

Múltiplas interpretações justificam uma pergunta apenas quando elas alteram materialmente o resultado ou o risco; resolva detalhes rotineiros e reversíveis do contexto existente.

2) Faça primeiro as perguntas essenciais (mantenha-as poucas)

Faça de 1 a 5 perguntas na primeira rodada. Prefira perguntas que eliminem ramos inteiros de trabalho.

Facilite a resposta às perguntas:

• Otimize para escaneabilidade (perguntas curtas e numeradas; evite parágrafos)
• Ofereça opções de múltipla escolha quando possível
• Sugira padrões razoáveis quando apropriado (marque-os claramente como a escolha padrão/recomendada; negrito a escolha recomendada na lista, ou se você apresentar opções em um bloco de código, coloque uma linha em negrito "Recomendado" imediatamente acima do bloco e também marque os padrões dentro do bloco)
• Inclua uma resposta rápida (por exemplo, responda defaults para aceitar todas as escolhas recomendadas/padrão)
• Inclua uma opção de "não tenho certeza" de baixo atrito quando útil (por exemplo, "Não tenho certeza - use o padrão")
• Separe "Precisa saber" de "Bom saber" se isso reduzir o atrito
• Estruture as opções para que o usuário possa responder com decisões compactas (por exemplo, 1b 2a 3c); reafirme as opções escolhidas em linguagem clara para confirmar

3) Pause antes de agir

Até que as respostas essenciais cheguem:

• Não execute comandos, edite arquivos ou produza um plano detalhado que dependa de desconhecidos
• Realize um passo de descoberta claramente rotulado e de baixo risco apenas se ele não o comprometer com uma direção (por exemplo, inspecionar a estrutura do repositório, ler arquivos de configuração relevantes)

Se o usuário autorizar explicitamente o prosseguimento com suposições razoáveis:

• Declare as suposições brevemente e continue dentro desse escopo autorizado; não peça a mesma confirmação novamente.
• Mantenha pendentes apenas autorizações consequentes genuinamente ausentes ou entradas indispensáveis, enquanto completa trabalho seguro e independente.

4) Confirme a interpretação e, em seguida, prossiga

Assim que tiver as respostas, reafirme os requisitos em 1 a 3 frases (incluindo restrições chave e como é o sucesso), e então comece o trabalho.

Modelos de Perguntas

• "Antes de começar, preciso: (1) ..., (2) ..., (3) .... Se você não se importa com (2), assumirei ...."
• "Qual destas opções você prefere? A) ... B) ... C) ... (escolha uma)"
• "O que você consideraria 'concluído'? Por exemplo: ..."
• "Alguma restrição que devo seguir (versões, desempenho, estilo, dependências)? Se nenhuma, vou mirar nos padrões existentes do projeto."
• Use perguntas numeradas com opções em letras e um formato de resposta claro

1) Scope?
a) Minimal change (default)
b) Refactor while touching the area
c) Not sure - use default
2) Compatibility target?
a) Current project defaults (default)
b) Also support older versions: <specify>
c) Not sure - use default

Reply with: defaults (or 1a 2a)

Antí-padrões

• Não faça perguntas que você possa responder com uma leitura rápida de descoberta de baixo risco (por exemplo, configurações, padrões existentes, documentação).
• Não faça perguntas abertas se uma opção de múltipla escolha restrita ou sim/não eliminar a ambiguidade mais rapidamente.

Limitações

• Use esta habilidade apenas quando a tarefa corresponder claramente ao escopo descrito acima.
• Não trate a saída como um substituto para validação específica do ambiente, testes ou revisão especializada.
• Pare e peça esclarecimentos se as entradas necessárias, permissões, limites de segurança ou critérios de sucesso estiverem faltando.