grill-me

grill-me

O maior modo de falha no desenvolvimento com agente e o desalinhamento: voce acha que pediu uma coisa, o agente entendeu outra, e isso so aparece no codigo pronto. O grill-me mata o desalinhamento na origem: uma entrevista implacavel que forca entendimento compartilhado ANTES de qualquer linha de codigo. E a Fase 0 do ADP, disparada pelo /adp-spec ou avulsa.

Reescrita da ideia do grill-me do Matt Pocock (mattpocock/skills), adaptada ao ADP com abertura criativa e integracao ao fluxo do protocolo.

SUB-SKILL RECOMENDADA (opcional — sem ela, siga o processo descrito nesta própria skill): superpowers:brainstorming e o motor de descoberta (uma pergunta por vez, propor abordagens, HARD-GATE: nada de implementar sem design aprovado). Esta skill adiciona por cima a POSTURA de grill, a abertura criativa e a saida estruturada do ADP.

Quando usar e quando NAO usar

• Usar: feature nova, escopo grande, requisito ainda vago, mudanca que cruza varias areas.
• Nao usar: mudanca pequena, direta e ja compreendida. Nesse caso, va de plan mode direto (regra spec-driven vs plan mode da aula). Nao force spec no trivial.

Postura: grill, nao brainstorm gentil

A diferenca do brainstorming puro esta na postura. Aqui:

• Uma pergunta por vez. Nunca despeje um questionario. Cada resposta abre a proxima pergunta.
• Nao aceite resposta vaga. "Sei la", "tipo um dashboard", "o de sempre" nao passam: puxe o "por que" ate o requisito ficar concreto e testavel.
• Desafie cada suposicao, inclusive as do próprio usuário. Se um pedido colide com o que ja existe no codebase ou com uma restricao real, aponte antes de seguir.
• Prefira multipla escolha quando der: e mais facil de responder e expoe as opcoes.
• Pare quando afiado, nao antes. Escopo, criterios de sucesso e fronteira (o que fica de fora) precisam estar claros.

O loop do grill

1. Dupla exploracao em paralelo (2 subagentes de uma vez, ANTES de perguntar). Despache no MESMO turno:
   • Terreno interno: UM subagente pra mapear o codebase do ALVO (caminho absoluto): feature-dev:code-explorer quando o projeto tem estrutura de app; fallback para um Explore com Glob/Read quando nao se aplica (ex: site estatico vanilla). NUNCA explore inline com ls/find no thread principal, e nunca repita um comando que falhou. No mesmo passo, cheque reuso interno: memoria da sessao, CLAUDE.md dos projetos e Glob bounded em C:\dev\* — muita "feature nova" ja existe como modulo pronto (ex: um modulo de pagamento seu, pronto em outro repo). Cite arquivos.
   • Radar largo (estado da arte, semeado so pelo prompt inicial): UM subagente com a web-buscador no playbook "Radar estado-da-arte", passada larga: como o mundo resolve isso HOJE — abordagens dominantes e emergentes, stack de referencia (versoes atuais, o que a comunidade adotou/abandonou), templates e repos exemplares, concorrentes lancados, dores relatadas. Cobre o radar tecnico E o de comunidades (Reddit, dev.to, Product Hunt, TabNews, HN, GitHub). Voce entra na entrevista JA sabendo o terreno interno e o estado da arte — as perguntas nascem melhores.
2. Grelhar (informado pelo radar). Perguntas dirigidas, uma por vez: problema real, quem usa, criterios de sucesso, casos de borda, restricoes (stack, prazo, dado sensivel, LGPD). Use os achados como MUNICAO de pergunta, nao como palestra: "a maioria resolve isso com X; teu caso tem motivo pra diferir?", "o produto Y ja faz isso; o que te diferencia?", "a comunidade abandonou Z por causa de W; ainda quer seguir por ai?". Registre as respostas.
3. Abrir opcoes (a criatividade entra aqui). Antes de fixar o caminho, monte 2-4 abordagens (stacks, libs, MCPs, plugins, padroes atuais) com trade-offs, cruzando o radar largo com o que a sua equipe ja tem (skills, MCPs). Se as respostas do grill mudaram a direcao (nicho diferente, restricao nova), dispare uma segunda passada FINA da web-buscador, agora mirada na direcao escolhida — curta e cirurgica, nada de repetir a larga. Nao fixe o caminho sem ter aberto as opcoes.
4. Fundir (achado vira decisao, nunca trivia). Cruze CADA achado relevante do radar com o escopo pedido no prompt E com as respostas do brainstorm, e de a ele um unico destino (tabela na secao Fusao). Achado sem destino = corta. E aqui que o estado da arte vira escopo, e nao curiosidade.
5. Afiar o dominio. Conforme as decisoes cristalizam, registre os termos-chave (glossario leve) e as decisoes importantes com o porque (ADR embrionaria). Isso vira materia-prima do PRD e evita re-discussao. (inspirado no domain-modeling do Matt)
6. Convergir. Proponha a abordagem recomendada com a justificativa + as alternativas como plano B.