Pular para o conteúdo
MÓDULO 3.1

🛠️ Anatomia do SKILL.md do grill-me

Vamos abrir o arquivo e ler cada decisão de design: o frontmatter que aciona, o método que entrevista, a regra que protege o contexto e o loop que melhora o seu sistema.

8
Tópicos
~45
Minutos
Inter.
Nível
Técnico
Tipo
1

📛 Frontmatter: name + description

Todo skill começa por um cabeçalho. No grill-me, esse frontmatter tem dois campos: name e description. O segredo está na description — é ela que ensina o modelo quando carregar o skill.

Novo aqui? Frontmatter é o bloco de metadados no topo de um arquivo Markdown, entre linhas de ---. Um gatilho (ou trigger) é uma situação que deve fazer o skill ser acionado.

SKILL.md · frontmatter (recriação ilustrativa)
---
name: grill-me
description: Interview the user relentlessly about a plan, design,
  or topic, checkpointing every answer to a brainstorm file so
  nothing is lost. Use when the user wants to stress-test a plan,
  get grilled on a design, run a brainstorm or discovery session,
  extract what's in their head into a doc, or says "grill me".
---

🎯 A description é a porta

Repare como a description é cheia de gatilhos concretos: "stress-test a plan", "get grilled", "discovery", "says grill me". Quanto mais situacional, mais certeira a ativação. Description vaga = skill que nunca dispara.

name

O identificador do skill.

description

Os gatilhos de ativação.

Situacional

"Quando" > "o que é".

Porta de entrada

Sem ela, ninguém entra.

2

✍️ A versão original do Matt Pocock

O skill original, criado por Matt Pocock, é desarmadoramente simples: quatro ou cinco frases. Ele prova que um skill não precisa de automação — precisa de instruções certas.

o corpo, em essência (recriação ilustrativa)
Entreviste-me sem dó sobre cada aspecto deste plano até
chegarmos a um entendimento comum. Caminhe por cada galho
da árvore de design, resolvendo as dependências entre
decisões, uma a uma. Para cada pergunta, dê a sua resposta
recomendada. Faça as perguntas uma de cada vez. Se uma
pergunta puder ser respondida explorando o codebase,
explore o codebase em vez de perguntar.

🔍 O que já está aqui

  • • Entrevista relentless até entendimento comum.
  • • Árvore de design + resolver dependências uma a uma.
  • Resposta recomendada por pergunta.
  • • Uma pergunta por vez.
  • Explorar em vez de perguntar quando dá.
Minimalismo

4-5 frases bastam.

Prompt = skill

Sem automação.

Já completo

O método inteiro cabe ali.

Base

O resto são acréscimos.

3

🚫 A regra do checkpoint

Aqui está o acréscimo que define a versão prática: a regra do checkpoint, marcada como não-negociável. Depois de cada resposta, antes da próxima pergunta, o skill faz append ao arquivo.

✓ A regra manda

  • Append estruturado após cada resposta.
  • Só então faz a próxima pergunta.
  • Corrige entradas antigas se algo mudar.

✗ A regra proíbe

  • Juntar várias respostas num write só.
  • Segurar tudo "na cabeça" do modelo.
  • Esperar o usuário pedir pra salvar.

📌 Por que "não-negociável"

Se a qualquer momento o contexto se perde, o arquivo já tem tudo o que foi dito até ali. O checkpoint a cada resposta é o que garante essa promessa — por isso não é "quando der", é sempre.

Não-negociável

Sempre, não às vezes.

Um de cada vez

Nunca em lote.

Corrigir passado

Reconciliar entradas.

Promessa

Nada se perde.

4

📁 Setup: brainstorms/ e o capture file

A regra de ouro do setup: criar o arquivo ANTES da primeira pergunta. Assim, mesmo a primeira resposta já tem onde cair.

Novo aqui? Um slug é uma versão curta e sem espaços de um título, usada em nome de arquivo (ex.: "embalagem de produtos" → packaging).

1

Pega a data

Roda date +%F para nomear o arquivo de forma previsível.

2

Cria a pasta e o arquivo

Cria brainstorms/ se não existir e brainstorms/{data}-{slug}.md com o header.

3

Avisa onde salvou

Diz ao usuário, em uma linha, o caminho do arquivo. Só então faz a Q1.

terminal · recriação ilustrativa
$ date +%F
2026-06-22
# cria: brainstorms/2026-06-22-packaging.md
Criar antes

Antes da Q1.

Pasta previsível

Sempre brainstorms/.

Data + slug

Nome consistente.

Avisar onde

Transparência.

5

🗂️ Estrutura do capture file

O arquivo tem uma forma fixa de quatro blocos. Essa estrutura é o que o torna rastreável e fácil de virar entregável depois.

{topic}-brainstorm.md 1 · Header título · date · goal 2 · Summary key decisions (síntese viva) 3 · Q&A log Asked / Captured nas palavras dele 4 · Open flags item → quem responde
template do capture file (recriação ilustrativa)
# {Topic}: Brainstorm / Discovery Notes
Date: {date} · Goal: {uma linha}

## Summary / key decisions
(síntese contínua, atualizada conforme avança)

## Q&A log
### Q1 — {tópico}
- Asked: {pergunta}
- Captured: {fatos, decisões, nas palavras dele}
- Flags: {item em aberto -> owner}

## Open flags (pending input)
- {item} -> {quem pode responder}
Header

Título, data, goal.

Summary

Síntese viva.

Q&A log

Nas palavras dele.

Open flags

Item → owner.

6

🔁 Simples vs incrementado

Por que "estragar" um skill que já funcionava? Porque em entrevistas longas a janela de contexto enche e o modelo começa a esquecer o que foi dito no início. A versão incrementada troca simplicidade por robustez.

Versão simples (Pocock)

  • Curtíssima, fácil de ler.
  • Ótima para sessões curtas.
  • Em sessão longa, o contexto enche e perde detalhe.

Versão incrementada

  • Checkpoint em disco a cada resposta.
  • Aguenta entrevistas de 1h+ sem perder nada.
  • Mais longa, mais cerimônia.

💡 "Destruí o skill de propósito"

A variação nasceu de uma dor real: na prática, o autor se via pedindo manualmente "salva isso, faz checkpoint" o tempo todo. Trabalhar essa rotina dentro do skill resolveu o problema na origem.

Trade-off

Simplicidade × robustez.

Contexto enche

O motivo do checkpoint.

Robustez

Aguenta sessão longa.

Dor real

Automatizar o repetido.

7

💡 Skill = prompt que você não quer repetir

Talvez a lição mais libertadora desta trilha: um skill não precisa ser automação complexa. Pode ser apenas um prompt que você cansou de digitar toda vez. O grill-me é exatamente isso.

🧭 Como reconhecer um candidato a skill

  • • Você digita as mesmas instruções repetidamente.
  • • Existe um jeito certo de fazer que você sempre explica.
  • • A tarefa tem passos fixos que valem a pena padronizar.

🎯 Dica

Da próxima vez que se pegar colando o mesmo parágrafo de instruções pela terceira vez, pare: isso é um skill esperando para nascer.

Skill ≠ automação

Pode ser só texto.

Reuso

Não redigitar.

O repetível

Capture o que se repete.

Barreira baixa

Qualquer um cria.

8

🔗 Atualizar skills e docs no final

A sessão não termina no recap. O grill-me percebe que existe um guia ou skill relacionado — com nuance que vocês acabaram de discutir e que não está lá — e oferece atualizar ambos. É assim que o output realimenta o seu OS.

1

Detecta a nuance órfã

"Vi que você tem um guia de packaging e um skill de packaging, e tem muita nuance aqui que não está neles."

2

Oferece atualizar

"Quer que eu atualize os dois?" Você responde "sim" e o brainstorm vira melhoria permanente.

3

O sistema fica mais inteligente

Skills e docs ficam mais ricos; o OS "sabe mais" sobre o seu jeito de trabalhar.

Detecta

Nuance que falta.

Oferece

Atualizar skill/doc.

Realimenta o OS

Output → contexto.

Loop fechado

Conversa → melhoria.

🛠️ Resumo do módulo

O frontmatter aciona — a description carrega de gatilhos concretos.
A base é minúscula — 4-5 frases do Matt Pocock já contêm o método.
O checkpoint é não-negociável — append após cada resposta, nunca em lote.
O capture file tem 4 blocos — header, summary, Q&A log, open flags.
O loop fecha no fim — o output atualiza skills e docs do seu OS.

Próxima trilha:

Trilha 4 · Avançado — os prompts que acionam o grill-me, a dificuldade real de responder e o loop grill-me + skill-creator.