scout

/scout — Para onde estou realmente indo e como chego lá?

Você tem um problema ou uma ideia, e o estado honesto é você não sabe como lidar com ele. Não é "qual das três abordagens" — você ainda não consegue enxergar o outro lado bem o suficiente para ter três abordagens. Tudo o mais nesta coleção assume que um destino já existe. Este é o skill que vai e encontra esse destino.

O trabalho é inspecionar o terreno e depois escolher a rota — não partir em direção ao destino e não começar a construir a primeira coisa que parece construtível.

O que isso NÃO é — para que você invoque o skill certo:

• Não é grill-me — isso te entrevista sobre um plano que você já tem, percorrendo uma árvore de decisões em profundidade. Isso é executado antes de um plano existir e vai deliberadamente em amplitude. Quando o scout terminar, grill-me é um próximo passo razoável.
• Não é explain — isso mapeia código que já existe. Isso mapeia trabalho que não existe.
• Não é root-cause — isso é para algo quebrado com um sintoma conhecido. Use isso primeiro se algo está falhando; use scout para a resposta a isso depois, se a correção não for óbvia.
• Não é validate-plan / ship-check — esses julgam um plano e um diff. O scout é executado antes de ambos e produz a coisa que eles julgam.

A porta de restrição — leia primeiro. O modo de falha é fabricar uma jornada. Se a passagem inicial mostrar que você já pode declarar o destino e os passos para ele, diga isso e pare: "isso não precisa de scouting — aqui está o plano, vá." A maioria dos problemas é assim. Cerimônia em um caminho claro é custo puro. Da mesma forma, se você usou este skill em vez do usuário digitar /scout, confirme antes de começar — uma entrevista não solicitada de 20 perguntas é uma surpresa desagradável.

As fases

1. Nomeie o destino — antes de qualquer outra pergunta

Pergunte o que pronto significa e reduza a uma ou duas linhas. Pode ser uma decisão tomada, uma especificação para entregar, uma migração concluída no local, uma funcionalidade funcionando de ponta a ponta. Destinos diferentes produzem rotas completamente diferentes, então isso é resolvido primeiro e nunca assumido.

O destino fixa o escopo — cada pergunta abaixo é medida contra ele. Se o usuário ainda não consegue nomeá-lo, esse é o primeiro item a trabalhar, e nada mais começa até que ele seja nomeado.

2. Explore em amplitude — e resista a responder

Varra o espaço inteiro entre aqui e o destino e colete as perguntas em aberto. Não resolva nenhuma delas ainda. A tentação de responder a primeira pergunta imediatamente é a coisa que esta fase existe para derrotar: a primeira pergunta que você nota raramente é a que decide a forma, e respondê-la cedo significa planejar a coisa errada com muito cuidado.

Vá para a largura, não para a profundidade. O objetivo é trazer à tona a pergunta que você não sabia que existia.

Fatos você consulta; decisões você pergunta. Se algo é verificável — o schema, os chamadores, os dados reais, a documentação da biblioteca, o que o código realmente faz hoje — vá verificar, não gaste uma pergunta nisso. Apenas decisões genuínas vão para o usuário.

3. Classifique em três grupos

Grupo	Teste	O que fazer
Nítido	Você consegue formular a pergunta com precisão agora mesmo	Resolva (fase 4)
Nebuloso	Você sente que há uma pergunta, mas ainda não consegue formulá-la	Uma linha solta, depois deixe-a
Fora do escopo	Está além do destino	Anote-a; ela não volta

O teste nítido/nebuloso é se você consegue formulá-la, não se consegue respondê-la. Uma pergunta com uma resposta difícil ou desconhecida ainda é nítida se você pode formulá-la exatamente — essas são muitas vezes as mais importantes.

Fora do escopo usa um teste diferente — escopo, não nitidez. Algo pode ser perfeitamente nítido e ainda estar fora do escopo porque está além do destino. Descarte-o explicitamente e diga por quê; ele só retorna se o próprio destino se mover, e isso é um novo scout.

Em seguida, ordene as perguntas nítidas por o que desbloqueia mais — a resposta que elimina o maior número de outras perguntas vai primeiro.

4. Resolva-as, uma de cada vez

Faça uma pergunta de cada vez e espere. Dê sua resposta recomendada com cada uma — mas é uma recomendação, e a decisão é do usuário. Nunca responda a uma decisão em nome deles e nunca agrupe perguntas; uma parede de cinco é desconcertante e recebe uma resposta preguiçosa.

Após cada resposta, atualize os grupos:

• Ela tornou a névoa nítida em uma pergunta real e formulável? Promova-a.
• Ela eliminou perguntas que não importam mais? Descarte-as.
• Ela moveu o destino? Diga isso em voz alta e reavalie os outros grupos em relação ao novo destino — tudo foi medido contra a linha antiga.

Não pré-corte névoa em perguntas falsas para parecer produtivo. Névoa é um sinalizador, não uma lista de tarefas.

5. Pare quando a rota estiver clara

Pronto significa: nenhuma pergunta nítida restante, e o que resta de névoa é genuinamente adiável ou fora do escopo. Feche com o destino, as decisões que levaram até lá e o próximo passo concreto.

Então entregue — não construa. Scout produz uma rota, não uma entrega. Vá para o modo de planejamento (ou /validate-plan se um plano surgiu disso), depois implemente. Se você se pegar escrevendo código de produção dentro de um scout, você excedeu o skill.

A única exceção é um descartável — quando uma pergunta genuinamente não pode ser resolvida no papel ("esse modelo de estado parece certo", "como isso deveria ser"), construa a menor coisa grosseira que a responda, olhe para ela, mantenha a resposta e descarte o código.

Cruzando sessões — apenas se realmente precisar

Padrão é uma sessão, sem artefato. A maioria dos scouts cabe, e um arquivo escrito para uma conversa que terminou vinte minutos depois é apenas lixo.

Escale para /handover-save quando — e apenas quando — uma destas condições for verdadeira:

• a sessão está ficando longa o suficiente para você perder o fio da meada,
• o usuário quer parar e retomar depois,
• uma pergunta está bloqueada por algo fora da conversa (resposta de outra pessoa, acesso a provisionamento, dados a serem coletados primeiro).

O documento de handover carrega o destino e os três grupos. Retome com /handover-resume, que ressincroniza o desvio antes de continuar. Abranger várias sessões é uma escotilha de escape aqui, não o design.

Forma da saída

Mostre o mapa quando ele mudar materialmente — depois que o destino for nomeado, depois da exploração em amplitude, e sempre que uma resposta reorganizar os grupos. Não a cada volta.

## Scout: <a ideia, uma linha>

**Destino:** <como é o "pronto" — tudo abaixo é medido contra isso>

**Decidido**
- <pergunta> → <a resposta>

**Em aberto — nítido**
1. <pergunta formulada com precisão>   ← trabalhando nisso agora
2. <...>

**Ainda nebuloso**
- <linha solta> — torna-se nítido assim que <X> for resolvido

**Fora do escopo**
- <o que foi descartado> — <por que está além do destino>

Feche com: destino, as decisões em ordem e o único próximo passo.

Salvaguardas

• Amplitude antes de profundidade. Responder a primeira pergunta antes de ver o espaço inteiro é a falha que este skill existe para prevenir.
• Consulte, não pergunte. Uma pergunta que você poderia ter respondido com um grep desperdiça a vez do usuário e sua paciência.
• Uma pergunta, depois espere. Recomende uma resposta toda vez; nunca decida por eles.
• Nitidez ≠ capacidade de resposta. O teste da névoa é "consigo formulá-la?", não "consigo respondê-la?".
• Névoa não é um backlog. Deixe-a solta. Pré-cortá-la em tarefas inventa trabalho que a próxima resposta pode deletar.
• Fora do escopo é uma decisão de escopo, não um passo. Vai para seu próprio grupo, nunca para a lista de decisões.
• O destino pode se mover — anuncie quando isso acontecer. Re-aim silenciosamente invalida todos os julgamentos feitos antes dele.
• Não construa. Decisões para fora, não entregas. Protótipos descartáveis são a única exceção.
• Nenhum arquivo por padrão. /handover-save apenas quando o trabalho genuinamente excede a sessão.
• Porta de restrição. "Não há névoa aqui — você já sabe como fazer isso" é um resultado real e valioso. Nunca invente perguntas em aberto para justificar a execução do skill.

---

Estruturação de destino-primeiro, a exploração em amplitude, o teste de névoa (formular vs. responder), e a divisão escopo-vs-nitidez adaptados de Matt Pocock's wayfinder (github.com/mattpocock/skills). Seu mapa de issues, mecanismo de subtarefas e regra de uma-tarefa-por-sessão são deliberadamente descartados — esta coleção persiste entre sessões com /handover-save em vez disso.