O que Encontre Seus Desconhecidos faz?
Visão Geral
A lacuna entre a descrição da tarefa pelo usuário (seu prompt, contexto, referências) e o trabalho real (o código-fonte, suas restrições, a realidade) é onde os desconhecidos vivem. Quando o agente encontra um desconhecido, ele adivinha a intenção do usuário. O trabalho desta skill é eliminar suposições: ajudar o usuário a descobrir e nomear seus desconhecidos antes, durante e depois da implementação, iterativamente — não como um plano único feito de antemão.
Isto é uma caixa de ferramentas, não um pipeline fixo. Primeiro diagnostique, depois aplique apenas as técnicas que se encaixam. Não execute todas elas em uma tarefa trivial.
Os Quatro Desconhecidos
Classifique o que está faltando antes de escolher uma técnica:
- Conhecidos conhecidos — já declarados no prompt.
- Conhecidos desconhecidos — o usuário sabe que ainda não decidiu isso.
- Desconhecidos conhecidos — muito óbvios para escrever, mas o usuário os reconhece ao vê-los (geralmente gosto visual/UX).
- Desconhecidos desconhecidos — nunca considerados; o usuário não sabe o que não sabe.
Passo 0 — Diagnosticar
Antes de fazer qualquer coisa, decida quais desconhecidos dominam e escolha as técnicas de acordo:
- Domínio desconhecido ou canto desconhecido do código-fonte → Varredura de pontos cegos (desconhecidos desconhecidos).
- Difícil de descrever, "vou saber quando ver" → Protótipo (desconhecidos conhecidos).
- Direção clara, detalhes confusos → Entrevistar o usuário + Rascunhar um plano (conhecidos desconhecidos).
Sempre dê contexto sobre quem é o usuário e o que ele já sabe — isso aprimora cada técnica abaixo.
Passar o Bastão para Outras Skills
Use esta skill como uma camada de descoberta, não como o fluxo de trabalho completo. Depois de nomear os desconhecidos, escolha a menor skill de acompanhamento que resolva a próxima incerteza.
| Desconhecido ou próxima necessidade | Passar para | Usar quando |
|---|---|---|
| O usuário não expressou totalmente a intenção | interview-me | Faça uma pergunta de cada vez até que a necessidade subjacente esteja clara. |
| O plano precisa ser testado sob pressão | grill-me ou grill-with-docs | Teste as suposições; use a variante com docs quando ADRs ou atualizações de glossário devem ser capturadas. |
| Fatos externos estão faltando | research ou source-driven-development | Reúna evidências de fontes primárias antes de decidir. |
| O usuário saberá quando ver | prototype | Mostre opções concretas com dados falsos antes de se comprometer com a implementação. |
| O trabalho precisa de uma especificação formal | spec-driven-development | Converta restrições e decisões descobertas em um PRD/especificação. |
| O trabalho é grande demais para executar diretamente | planning-and-task-breakdown ou writing-plans | Divida a especificação alinhada em fatias ordenadas e verificáveis. |
| Limites de interface são incertos | api-and-interface-design ou design-an-interface | Decida contratos de API, módulo ou tipo. |
| A forma do código-fonte é a incerteza | codebase-design ou improve-codebase-architecture | Encontre o limite de módulo, abstração ou direção de refatoração corretos. |
| O comportamento de UI ou qualidade visual é incerto | frontend-ui-engineering | Transforme protótipos ou preferências escolhidos em trabalho de UI de produção. |
| Um bug está presente, mas a causa não está clara | systematic-debugging ou diagnosing-bugs | Reproduza, isole, levante hipóteses, instrumente e corrija. |
| A implementação abrange tarefas independentes | subagent-driven-development ou dispatching-parallel-agents | Divida o trabalho apenas quando as tarefas não compartilham estado ou dependências sequenciais. |
| O trabalho parece completo | verification-before-completion, requesting-code-review ou code-review | Verifique as evidências, então revise antes de reivindicar conclusão ou mesclar. |
Antes de passar o bastão, resuma:
- O que é conhecido agora.
- O que permanece desconhecido.
- Qual decisão mudaria a implementação.
- Qual artefato deve seguir adiante: protótipo, especificação, plano, notas de implementação ou relatório de aceitação.
Técnicas por Fase
Cada técnica tem um gatilho e um modelo de prompt pronto para enviar. Adapte as partes entre colchetes.
Explorar (encontrar os desconhecidos)
1. Varredura de pontos cegos — primeiro movimento em uma área desconhecida.
Estou adicionando [X] mas mal conheço o módulo [Y] neste código-fonte. Faça uma passagem de pontos cegos — encontre meus "desconhecidos desconhecidos" e explique-os, para que eu possa escrever um prompt melhor para você.
2. Protótipo — quando não pode ser descrito, mostre. Use dados falsos, sem backend.
Antes de tocar no aplicativo real, crie um arquivo HTML que simule [a interface] com dados falsos. Me dê 4 direções de design completamente diferentes para que eu possa ver qual parece certa.
3. Entrevistar o usuário — extraia os pontos confusos restantes.
Me faça uma pergunta de cada vez. Mire em áreas ambíguas e priorize perguntas cuja resposta mudaria a arquitetura.
Planejar (alinhar a intenção)
4. Mostrar uma referência — a melhor referência é o código-fonte, não uma captura de tela.
[caminho / biblioteca] implementa o [comportamento] que eu quero. Leia, depois reimplemente a mesma semântica em [nossa pilha].
5. Rascunhar um plano — traga à tona as decisões com maior probabilidade de mudança primeiro.
Escreva um plano de implementação em HTML, mas coloque as decisões que tenho maior probabilidade de ajustar no topo: mudanças no modelo de dados, novas interfaces de tipo, qualquer coisa visível ao usuário. Coloque refatorações mecânicas por último — confio em você nessas.
Implementar (capturar desconhecidos que surgem no meio do trabalho)
6. Anotações ao longo do caminho — inicie uma nova sessão, alimente a especificação/protótipo, então:
Mantenha um arquivo implementation-notes.md. Se um caso de borda te tirar do plano, escolha a opção conservadora, registre-a em uma seção "Desvios" e continue.
Entregar (alinhar outros, verificar se você entendeu)
7. Explicador de passagem de bastão
Empacote o protótipo, a especificação e as notas de implementação em um documento que eu possa colocar no chat para obter aceitação. Coloque um GIF de demonstração no topo.
8. Teste de aceitação — a regra rígida do autor: passe antes de mesclar.
Quero ter certeza de que entendi esta mudança completamente. Faça um relatório HTML com o contexto da mudança, intuição e o que foi feito — depois um teste no final que eu tenha que passar.
Regras Operacionais
- Sempre que estiver prestes a adivinhar a intenção do usuário, pare e aplique a técnica correspondente.
- Encadeie os artefatos: protótipo → especificação → notas de implementação → relatório de aceitação; cada um é entrada para o próximo, para que uma nova sessão não perca contexto.
- Para uma tarefa pequena,
varredura de pontos cegos + rascunhar plano + teste de aceitaçãojá captura a maior parte do valor. Não exagere.