| name | clarificar |
| description | Use para uma SABATINA — entrevista implacável que transforma intenção difusa em entendimento compartilhado antes de construir. Caminha pela árvore de decisão UMA pergunta por vez, resolvendo dependências entre escolhas, sempre com uma resposta recomendada; explora o codebase/docs em vez de perguntar quando a resposta já existe. Ideal no gate da spec (AC testáveis / Definition of Ready) e do design (decisão difícil de reverter). Produz um resumo de entendimento que alimenta product.md/design.md/spec.md. Chamada por /nova-feature, /kickoff, /roadmap e /validar, ou acione direto com /clarificar. |
Skill: Clarificar (sabatina de plano/spec)
Entrevista implacável para afiar um plano, uma spec ou um design antes de construir. O alvo é
entendimento compartilhado: nenhuma ambiguidade que vire retrabalho ou SPEC_DEVIATION depois.
Inspirada na técnica de grilling — adaptada ao vocabulário da esteira (AC testáveis, tier,
decisão difícil de reverter → ADR, linguagem ubíqua).
Quando usar isto e não "lotes curtos": o resto da esteira pergunta em lotes (AskUserQuestion)
para escolhas independentes. A sabatina é o oposto e o complemento: para uma árvore de decisão
com dependências, onde a resposta 3 só faz sentido depois das respostas 1 e 2. Use quando a
ambiguidade é profunda e ramificada, não quando são opções ortogonais.
Princípios (o motor)
- Uma pergunta por vez. Faça a pergunta, espere a resposta, e só então a próxima. Várias
perguntas de uma vez confundem e impedem que cada resposta refine a seguinte.
- Caminhe pela árvore. Cada resposta abre/fecha ramos. Resolva dependências em ordem: não
pergunte o "como" antes do "se", nem o detalhe antes da fronteira.
- Sempre proponha uma resposta recomendada. Não interrogue no vácuo — para cada pergunta dê sua
recomendação com o porquê (em
AskUserQuestion, a primeira opção leva "(Recomendado)").
- Explore antes de perguntar. Se a resposta está no codebase, nos docs (
specs/, docs/,
ADRs, glossário) ou num MCP de referência conectado, descubra você mesmo — só pergunte o que
exige decisão humana. (É a Verificação de conhecimento do CLAUDE.md.) Nunca invente: incerteza
explícita > chute confiante.
- Cave até o testável. Uma resposta vaga ("rápido", "seguro", "vários") não fecha o ramo —
refine até virar critério verificável (número, caso concreto, Given/When/Then).
Processo
- Enquadre o alvo. Diga em 1-2 linhas o que está sendo sabatinado (esta feature / este design /
esta prioridade) e o que será considerado "entendido o bastante para seguir".
- Levante os ramos abertos. A partir do material existente, liste mentalmente as decisões em
aberto e as ambiguidades. Priorize as de maior impacto / mais difíceis de reverter.
- Sabatine, um ramo por vez. Para cada ponto: explore primeiro; se restar decisão, pergunte
uma coisa com a recomendação; integre a resposta; deixe-a abrir os próximos ramos. Repita.
- Pare quando a árvore fechar — sem ramos abertos que mudem o que será construído. Não estenda
por esporte; quando o usuário e você concordam no escopo, encerre.
Saída — o entendimento vira artefato
A sabatina não termina em chat: consolide o resultado para alimentar a esteira.
- Resumo de entendimento: decisões fechadas, não-objetivos que surgiram, premissas e riscos.
- Direcione ao destino certo conforme o que foi clarificado:
- virou critério de aceite →
spec.md (Given/When/Then; regra multifatorial → Matriz de decisão);
- virou decisão difícil de reverter → vira ADR (
docs/architecture/adr/);
- virou termo de negócio →
docs/glossary.md / domain.md;
- ficou em aberto de propósito →
docs/STATE.md (com o gatilho para reconsiderar).
- Aponte o próximo passo de quem te chamou (preencher o gate, retomar
/nova-feature, etc.).
