Já queimei mais hora revisando plano ruim gerado por IA do que eu gostaria de admitir. Você conhece o padrão — fala pro seu agente de código "constrói X pra mim", ele cospe um doc de brainstorming de 2.000 palavras, você lê até o fim, metade está errada, você corrige, ele regenera, e agora você queimou 40 minutos antes de uma única linha de código sair.
Mês passado tropecei numa dupla de ferramentas que virou esse processo do avesso. Cinco linhas de código pra primeira ferramenta. Um único comando de CLI pra segunda. Juntas, elas cortaram meu overhead de planejamento em uns 70% — e o código que sai do outro lado está mais perto do que eu queria já na primeira passada.
Deixa eu te mostrar.
O problema de verdade do vibe coding
Uma coisa que me incomoda em como a maioria fala de IA pra código: o gargalo não é geração de código. Esses modelos escrevem código o dia inteiro. O gargalo é que o código que eles escrevem não é o que você tinha na cabeça.
E geralmente a culpa é sua, não deles.
Você tem uma visão difusa na cabeça. Dá um prompt vago pro agente. O agente preenche as lacunas com as suposições dele. Você recebe o output e pensa "não, não era isso". Repete o ciclo.
A solução padrão é uma fase de brainstorming ou planejamento — pedir pro agente rascunhar uma proposta, você revisa, itera, revisa de novo. Ferramentas tipo superpowers embutem isso no workflow.
O problema? Essas fases de planejamento são pesadas. Outputs longos. Iterações lentas. E você está gastando energia cognitiva séria avaliando se a proposta do agente está certa — o que é quase tão difícil quanto construir a coisa você mesmo.
E se o agente não propusesse nada? E se ele só... te perguntasse?
Grill-Me: 5 linhas que mudaram como começo cada tarefa
Grill-me é uma skill do Claude Code criada pelo Matt Pocock. A coisa toda tem poucas frases. Sem framework. Sem arquivo de config. Sem dependências. Só uma instrução de prompt que fala pro agente te entrevistar sobre seus requisitos antes de tocar em qualquer código.
A ideia por trás é simples demais: antes do agente escrever qualquer coisa, ele te interroga. Não com formulário, não com checklist — com conversa. Ele passa por cada decisão de design, uma bifurcação por vez, e não para até vocês dois estarem na mesma página. O prompt original do Matt Pocock fala pro agente sugerir a própria resposta pra cada pergunta, e ir fuçar no seu codebase sempre que conseguir achar a resposta lá em vez de te incomodar.
É isso. Um punhado de frases. E é meio brilhante.
Como é na prática:
Micro-decisões, não macro-revisões. Em vez de despejar um plano de 30 parágrafos no seu colo, o agente traz uma pergunta por vez. "Usamos singleton aqui ou dependency injection?" Você responde, ele segue. Seu cérebro fica em modo julgamento rápido, nunca muda pro modo "ler e avaliar parede de texto".
O agente pensa, você guia. Cada pergunta vem com uma recomendação. "Eu sugeriria PostgreSQL pra isso — beleza?" Você não está olhando pra um prompt em branco tentando articular sua visão do zero. Está reagindo a uma proposta concreta. É outro tipo de esforço mental, completamente diferente.
Consciente do codebase, não ignorante dele. Se a resposta já existe em algum lugar do seu repo — uma convenção de nomenclatura, um padrão de config, uma abstração existente — o agente acha e segue. Já vi resolver três ou quatro perguntas em sequência sem me perguntar nada, só lendo meu código. Esse é tempo que não precisei gastar.
Drop-in, não lock-in. É um arquivo de skill simples. Sem dependência de framework. Sem estrutura de projeto obrigatória. Você invoca quando quer, ignora quando não quer. Já usei dentro do Claude Code, Codex e Cursor sem mudar nada no resto do setup.
A comunidade do r/vibecoding no Reddit gerou discussão equivalente a 13k+ upvotes. O takeaway que volta sempre: brainstorming tradicional coloca o agente no volante e você na cadeira de passageiro revisor, o que é mentalmente esgotador. Grill-me inverte os papéis — você é o decisor, o agente é o entrevistador. Bem mais leve pro cérebro.
Trellis: mantendo o agente nos trilhos
Fazer as perguntas certas é metade da batalha. A outra metade é não perder o fio durante a execução.
Se você já teve um agente de código começando forte e depois saindo de lado numa sessão longa — esquecendo restrições, contradizendo decisões anteriores, corrompendo aos poucos o próprio contexto — você conhece o problema. Tarefas de agente de longa duração precisam de guardrails, ou a qualidade degrada a cada minuto que passa.
Trellis é um framework de CLI da Mindfold que adiciona planejamento estruturado em cima de qualquer agente de código que você já use. Pensa nele como o project manager sentado entre seus requisitos e a execução do seu agente.
A parte que mais me importa é governança de contexto. Numa sessão longa de agente, o entendimento do modelo sobre o que ele deve estar fazendo apodrece aos poucos. Restrições iniciais são esquecidas. Decisões são contraditas. O Trellis resolve isso mantendo uma árvore estruturada de tarefas que o agente referencia durante toda a execução — uma fonte persistente de verdade que não degrada com o tamanho da conversa.
Cada tarefa na árvore vem com objetivo explícito e critério de aceitação. Não "constrói o sistema de auth" mas "implementa rotação de JWT refresh token com expiração de 7 dias, retornando 401 em tokens expirados e 403 em tokens inválidos". O agente sabe como é "feito" antes de escrever a primeira linha.
E ele se dá bem com outros. Um trellis init gera planos pro Claude Code, Codex e Cursor ao mesmo tempo. Você não está escolhendo lado — está adicionando estrutura em cima da ferramenta que você já usa.
O workflow completo: como eu uso de verdade
A teoria soa bem. Aqui é como fica numa terça à tarde quando tenho uma feature pra entregar.
Começo falando pro agente me grillar. Descrevo a feature em duas ou três frases — deliberadamente vago, porque é o ponto. O agente imediatamente começa a sondar. "Estamos construindo isso como serviço standalone ou módulo dentro do app existente?" "Qual o modelo de auth — herdamos do pai ou isso precisa do próprio?" "Achei um padrão similar em /src/services/billing.ts — sigo essa convenção?" Cada pergunta leva 5-10 segundos pra responder. A interrogação inteira roda em uns 10 minutos. No fim, o agente tem uma imagem mais clara do que eu quero que qualquer spec doc que eu já tenha escrito.
Aí mudo pro Trellis. Rodo trellis init na raiz do projeto e alimento ele com o consenso da sessão de grill-me. O Trellis transforma isso numa árvore de tarefas — não um outline vago "fase 1, fase 2", mas tarefas concretas com objetivos e critério de aceitação. "Cria a migration de banco pra nova tabela subscriptions. Colunas: id, user_id, plan_type, started_at, expires_at. Adiciona índice em user_id." Esse nível de especificidade.
Com o plano travado, deixo o agente executar. Se estou confiante nos requisitos (o que normalmente estou depois de uma boa sessão de grill-me), ligo dangerously-skip-permissions e deixo rodar sem supervisão. Já tive sessões de 40 minutos seguidos — o agente passando pela árvore de tarefas, escrevendo código, rodando os testes, corrigindo falhas, indo pra próxima tarefa. Vou fazer um café. Talvez dois cafés.
O entregável no fim normalmente é 85-90% do que preciso. Uns ajustes, não uma demolição. Compara com o fluxo antigo onde o primeiro output do agente era talvez 50% certo e eu gastaria mais uma hora em ping-pong de revisão.
Por que isso parece tão diferente de planejamento de agente
Quero ser específico sobre a mecânica aqui, porque a diferença não é só "é mais rápido". É outro tipo de atividade mental, totalmente.
Quando eu usava planejamento estilo brainstorming, o loop era: o agente produz um documento longo → leio com atenção → descubro quais partes estão erradas → explico as correções → o agente revisa → releio a revisão. A cada passo, estou fazendo trabalho de avaliação. "A arquitetura está certa? Ele entendeu a restrição que mencionei? Esse edge case está coberto?" Isso é pensamento difícil. Cansa. E leva 30-40 minutos pra uma feature complexa.
O loop do grill-me é: o agente pergunta "fazemos X ou Y?" → digo "X" → próxima pergunta. Às vezes digo "na real, nenhum dos dois — preciso disso aqui" e dou um redirect de uma frase. Mas na maior parte do tempo, a sugestão do agente está perto o bastante e eu só confirmo.
Caiu a ficha uma semana depois de por que isso parece bem mais leve. É a diferença entre escrever uma redação e fazer uma prova de múltipla escolha. Os dois cobrem o mesmo material. Um é geração criativa do zero. O outro é reconhecimento e seleção. Meu cérebro consegue fazer o segundo por uma hora sem cansar.
Instalação
As duas ferramentas levam menos de dois minutos pra montar.
Grill-me — se você está no Claude Code com um gerenciador de skills:
npx skills@latest add mattpocock/skills --yesAviso rápido: a instalação por sub-path (npx skills@latest add mattpocock/skills/grill-me) não funciona. Precisa instalar o repo inteiro. O instalador configura automaticamente pro Claude Code, Codex, Cursor e Gemini CLI.
Trellis — exige Node.js. Instalação global, depois init por projeto:
npm install -g @mindfoldhq/trellis@beta
cd your-project
trellis init --claude --codex
Uma nota sobre dangerously-skip-permissions
Essa flag faz exatamente o que parece — deixa o agente pular todos os prompts de permissão e executar livremente. Leitura de arquivo, escrita, comandos de shell, tudo. Sem confirmação humana no loop.
A vantagem é óbvia: fluxo ininterrupto. O agente consegue mastigar uma tarefa complexa por 30 minutos direto sem esperar você clicar "permitir".
O risco também é óbvio: o agente pode fazer algo que você não esperava.
Minha regra de bolso: quanto mais claros seus requisitos, mais seguro é pular permissões. Se você fez uma sessão minuciosa de grill-me e seu plano do Trellis tem critério de aceitação apertado, o agente tem pouquíssimo espaço pra sair da linha. Num projeto novinho que você não entende bem? Não usa esse modo. Começa supervisionado.
Pra quem isso vale a pena
Seja honesto sobre se você precisa desse nível de estrutura.
Se suas tarefas de agente de código são curtas e auto-contidas — "escreve uma função de sort", "adiciona um loading spinner" — você não precisa de fase de interrogação de requisitos. Só faz o prompt e vai. Grill-me adiciona valor quando a tarefa é complexa o bastante pra um prompt vago levar a output errado. Features multi-arquivo, decisões arquiteturais, qualquer coisa onde "constrói X" tem mais de uma interpretação razoável.
Se você já roda sessões longas de agente e nota degradação de qualidade conforme a conversa cresce — esse é o sweet spot do Trellis. A gestão de contexto sozinha vale a instalação.
E se você é o tipo de dev que pula entre Claude Code, Codex e Cursor dependendo da tarefa — as duas ferramentas são agnósticas de plataforma. Configura uma vez, usa em todas.
Uma limitação real: são ferramentas de CLI pra devs. Se você precisa de gestão de projeto visual ou não está confortável no terminal, esse não é seu workflow.
Status do projeto
Grill-me está maduro. O Matt Pocock publicou walkthroughs em vídeo, a comunidade testou em batalha por milhares de sessões, e funciona de forma confiável em várias plataformas de agente.
Trellis ainda está em beta. O conceito central — decomposição de tarefa mais governança de contexto mais output multi-plataforma — é o mais forte que vi nessa categoria. Mas espera algumas arestas. Se você não está pronto pra software em beta, dá pra usar grill-me sozinho pra fase de requisitos e cuidar da execução com qualquer ferramenta que você já está confortável.
De qualquer jeito, as cinco linhas que formam o grill-me me salvaram mais tempo que ferramentas com dez mil linhas de código. Às vezes a menor intervenção no momento certo é tudo que você precisa.
Testa grill-me no seu próximo projeto. Passa 10 minutos respondendo perguntas em vez de 40 minutos revisando proposta. Vai ficar se perguntando por que algum dia fez do outro jeito.
