Nota do autor: neste artigo, você vai aprender do zero a usar duas habilidades essenciais do mattpocock/skills. Primeiro, use /grill-me para esclarecer os requisitos. Depois, use /tdd para escrever o código. Cada etapa vem com critérios de aceitação.
Em uma frase: use /grill-me primeiro para o Agent esclarecer os requisitos e, em seguida, use /tdd para escrever o código, um teste de cada vez.
Em 22 de outubro de 2026, no horário de Pequim, o repositório mattpocock/skills tinha cerca de 300 mil estrelas no GitHub, usa a licença MIT e está na versão mais recente, v1.3.1. O número de estrelas indica popularidade, mas não significa que a ferramenta necessariamente vá funcionar bem no seu projeto. Por isso, este artigo mostra apenas como instalar, usar e verificar se ela está funcionando como deveria, sem exagerar nos resultados.
Um passo a passo prático, para você acompanhar clicando e digitando. Vamos usar como exemplo a pequena tarefa de adicionar a validação de cupons ao fluxo de pedidos, desde a instalação até o primeiro teste passando.
- Objetivo: instalar as habilidades, fazer uma rodada de perguntas sobre os requisitos com /grill-me e, depois, escrever o primeiro teste no ciclo “vermelho → verde” com /tdd
- Tempo estimado: a instalação leva apenas alguns minutos (segundo o autor, “30 segundos”). O tempo para responder às perguntas e escrever o teste depende principalmente da rapidez das suas respostas. Esta é uma estimativa editorial: reserve cerca de 30 minutos a 1 hora para o processo todo.
- Pré-requisitos: já usar algum Agent de programação, como Claude Code, Codex, GitHub Copilot, Gemini CLI ou Cursor, e ter um repositório de código em que possa fazer testes à vontade
- Dificuldade: iniciante. O processo é feito principalmente por meio de interface gráfica e caixas de diálogo; os comandos de terminal são opcionais
Principais pontos de mattpocock/skills: qual é o papel de grill-me e tdd
mattpocock/skills é um conjunto público de habilidades para agentes criado por Matt Pocock. A descrição do repositório é “Skills for Real Engineers” (Habilidades para engenheiros de verdade). No README, o autor diz que essas habilidades são pequenas, combináveis, compatíveis com qualquer modelo e “baseadas em décadas de experiência em engenharia”.
| Ponto | Descrição | Benefício |
|---|---|---|
| /grill-me | Faz perguntas em rodadas, cada uma acompanhada de uma resposta recomendada. Não grava nenhum arquivo e só é acionada quando você a chama manualmente | Alinha os requisitos com o agente antes de começar e revela decisões que você ainda não tinha percebido |
| /tdd | Primeiro lista os limites dos testes (seams) e espera sua confirmação; depois segue o ciclo “vermelho → verde”, com um teste por vez | Cada etapa tem feedback, e os testes ajudam a garantir que a refatoração não quebre o código |
| /setup-matt-pocock-skills | Execute uma vez por repositório para configurar o rastreador de issues, as etiquetas de triagem e o local para guardar a documentação | Ajuda as habilidades de engenharia a saber onde registrar as informações |
| Como instalar | Escolha entre o plugin (atualizado automaticamente) e o skills.sh (arquivos editáveis) | Instalar os dois faz com que cada habilidade apareça duplicada |
Por que usar grill-me e tdd em sequência
O README lista alguns modos comuns de falha, e dois deles correspondem diretamente a essas habilidades. O primeiro é “o agente não fez o que eu queria”, causado por uma falha de comunicação entre você e o agente. A solução é fazer uma rodada de perguntas de esclarecimento (grilling), para que o agente pergunte em detalhes o que você quer fazer. O conteúdo de /grill-me se resume a uma instrução: acionar a habilidade grilling. As regras para fazer as perguntas estão na própria habilidade grilling.
O outro modo de falha é “o código não funciona”. Mesmo quando os requisitos estão alinhados, se o agente não consegue ver o resultado real da execução do código, ele acaba voando às cegas. A abordagem de /tdd é primeiro escrever um teste que falhe e, em seguida, o mínimo de código necessário para fazê-lo passar. Assim, o agente recebe feedback confiável a cada etapa. Em conjunto, as duas habilidades resolvem problemas diferentes: a primeira define “o que fazer”; a segunda verifica “se foi feito certo”.
Como instalar mattpocock/skills e executar grill-me e tdd: primeiros passos em 5 etapas
Etapa 1: instale mattpocock/skills (priorize a interface gráfica)
O projeto oferece instruções oficiais para Claude Code, Codex, GitHub Copilot e Gemini CLI. Para os outros agentes, use o skills.sh. O README deixa claro que essas skills funcionam com qualquer modelo. A documentação oficial também menciona que Auggie, Droid, Goose e outros ainda não foram testados por ninguém; por enquanto, a recomendação é usar o skills.sh.
| Agente que você usa | Método recomendado | Atualização automática? |
|---|---|---|
| GitHub Copilot (VS Code) | Abra a paleta de comandos, execute Chat: Install Plugin From Source e informe https://github.com/mattpocock/skills |
Sim, diariamente |
| Claude Code | Instale mattpocock-skills pelo mercado oficial de plugins claude-plugins-official |
Sim, ativada por padrão |
| Codex | Primeiro, adicione o mercado de plugins mattpocock/skills e, em seguida, instale o plugin |
Sim, na inicialização |
| Copilot CLI | Instale pelo mercado de plugins mattpocock |
Após configurar autoUpdate: true uma vez |
| Gemini CLI | Instale os diretórios engineering e productivity separadamente | Não, é preciso executar os comandos de novo |
| Cursor, OpenCode, Windsurf, Devin, Amp, Pi etc. | skills.sh | Não, é preciso atualizar manualmente |
Para quem usa o VS Code, esse é o caminho mais simples. Pressione Ctrl+Shift+P (ou Cmd+Shift+P no macOS) para abrir a paleta de comandos, digite Chat: Install Plugin From Source e pressione Enter. Depois, cole o endereço do repositório. Se preferir usar o terminal, estes são os comandos de instalação oficiais:
- Claude Code: execute
claude plugin install mattpocock-skills@claude-plugins-official. A atualização automática vem ativada por padrão. - Codex: execute primeiro
codex plugin marketplace add mattpocock/skillse depoiscodex plugin add mattpocock-skills@mattpocock. O plugin é atualizado automaticamente a cada inicialização. - GitHub Copilot CLI: execute primeiro
copilot plugin marketplace add mattpocock/skillse depoiscopilot plugin install mattpocock-skills@mattpocock. - Gemini CLI: execute
gemini skills install https://github.com/mattpocock/skills.git --path skills/engineeringegemini skills install https://github.com/mattpocock/skills.git --path skills/productivity. A atualização não é automática; para atualizar, execute os dois comandos novamente. - Outros agentes (skills.sh): execute
npx skills@latest add mattpocock/skills -a cursor, substituindocursorpelo agente que você usa, como opencode, devin, windsurf, amp ou pi. Se não informar-a, você poderá escolher. Para atualizar, executenpx skills@latest update. Quando surgirem novas skills, executeaddnovamente. - Instalar apenas uma skill: execute
npx skills@latest add mattpocock/skills --skill=<name>, substituindo<name>pelo nome da skill.
No Copilot CLI, também é necessário editar ~/.copilot/settings.json uma única vez e adicionar este trecho de configuração: {"extraKnownMarketplaces": {"mattpocock": {"source": {"source": "github", "repo": "mattpocock/skills"}, "autoUpdate": true}}}. Isso registra o mercado de plugins mattpocock como proveniente do repositório GitHub mattpocock/skills e ativa a atualização automática. A documentação oficial informa que o trecho segue o formato documentado, mas ninguém o testou na prática até agora.
Você precisa escolher entre instalar pelo mercado de plugins ou pelo skills.sh. Os plugins são pacotes somente leitura, atualizados automaticamente. Já o skills.sh copia arquivos editáveis para o seu projeto. Se você instalar pelos dois métodos, terá duas cópias de cada skill. Ao usar o skills.sh, o instalador perguntará quais skills você quer instalar; não deixe de selecionar setup-matt-pocock-skills.
Se quiser instalar apenas uma skill, há duas dependências que precisam ser instaladas juntas. grill-me apenas chama grilling, então é necessário instalar grilling também. Já tdd depende de codebase-design, que fornece o vocabulário de design de código usado para discutir pontos de extensão (seams).
Você saberá que deu certo quando: ao digitar / na caixa de diálogo do Agent, a lista de sugestões mostrar grill-me, tdd e setup-matt-pocock-skills, cada um aparecendo uma única vez.
Etapa 2: execute /setup-matt-pocock-skills na caixa de diálogo
Na primeira vez que usar esse conjunto de habilidades em um repositório, digite /setup-matt-pocock-skills na caixa de diálogo do Agent. Ele fará três perguntas, uma após a outra: qual rastreador de issues você usa (GitHub, GitLab, arquivos locais ou outra opção que você descrever), quais etiquetas usar na triagem de tickets e onde salvar os documentos gerados.
Responda com sinceridade. Se não tiver certeza, escolha arquivos locais — você poderá mudar isso depois. Tecnicamente, /grill-me não depende do repositório, então não é obrigatório fazer essa etapa. Mas é recomendável concluir a configuração antes de usar habilidades de engenharia como /tdd. Você só precisa fazer isso uma vez por repositório.
Você saberá que deu certo quando: o Agent terminar de fazer as três perguntas e avisar que a configuração foi concluída. Você também saberá onde os documentos serão salvos daqui em diante.
Etapa 3: escolha os modelos certos para grill-me e tdd
A documentação oficial destaca que a etapa de perguntas depende mais do modelo do que a maioria das outras habilidades. O grilling depende do conhecimento do próprio modelo sobre “como o sistema pode falhar”, então use o melhor modelo a que você tiver acesso. Na hora de implementar, o modelo precisa principalmente acompanhar o contexto, por isso opções mais econômicas também podem dar conta do recado.
| Etapa | O que o modelo precisa oferecer | O que fazer |
|---|---|---|
| Perguntas com /grill-me | Depende do conhecimento de engenharia do próprio modelo; quanto mais capaz, mais precisas serão as perguntas | Use o melhor modelo que você tiver à disposição, como o Claude Opus 5.5 |
| Implementação com /tdd | Principalmente acompanhar o contexto já estabelecido | Você pode trocar por um modelo mais econômico |
| Como conectar | Troque de modelo por etapa no Claude Code ou no Codex | Use uma chave API da APIYI apiyi.com para acessar vários modelos |
Para configurar uma interface unificada no Claude Code ou no Codex, faça o seguinte:
- Claude Code: primeiro, defina duas variáveis de ambiente:
ANTHROPIC_BASE_URLcomohttps://api.apiyi.com(a interface unificada da APIYI) eANTHROPIC_AUTH_TOKENcomo sua chave API. Depois, executeclaudepara iniciar e use/modelna caixa de diálogo para trocar de modelo. - Codex: abra
~/.codex/config.tomle adicione as duas linhasmodel = "<ID do modelo>"emodel_provider = "apiyi". Em seguida, adicione uma seção[model_providers.apiyi]e, abaixo dela, inclua as três linhasname = "APIYI",base_url = "https://api.apiyi.com/v1"eenv_key = "APIYI_API_KEY". Use o ID do modelo exibido no console.
Os nomes dos campos podem mudar conforme a versão da ferramenta. Consulte a documentação oficial da ferramenta e o docs.apiyi.com para confirmar os detalhes.
🎯 Dica para escolher o modelo: prefira o melhor modelo na etapa de perguntas e use um modelo mais econômico na implementação. Com uma única chave da APIYI apiyi.com, você pode alternar entre modelos no Claude Code e no Codex com facilidade. Vale lembrar que a APIYI resolve apenas a questão da invocação do modelo; ela não substitui as próprias habilidades grill-me, tdd e outras.
Considere esta etapa concluída quando: você conferir o modelo atual na caixa de diálogo (no Claude Code, use /model) e confirmar que a etapa de perguntas está usando o modelo avançado escolhido.
Etapa 4: use /grill-me para esclarecer os requisitos de “validação de cupons”
Abra uma nova conversa. Não continue naquela em que o Agent já preparou um plano e desative o modo de planejamento. Esse modo faz o Agent correr para produzir um plano, mas, nesta etapa, você precisa que ele faça perguntas sem parar. Digite /grill-me Quero adicionar uma validação de cupons ao fluxo de pedidos na caixa de diálogo e pressione Enter.
O grill-me não é acionado automaticamente pelo Agent: ele só entra em ação quando você o digita. Ele transforma os requisitos em uma “árvore de decisões” e, a cada rodada, faz de uma vez todas as perguntas cujas condições prévias já foram definidas. Cada pergunta recebe um número e vem acompanhada de uma resposta recomendada. A formulação também é pensada para que responder yes signifique aceitar a recomendação. Uma rodada de perguntas e respostas seria mais ou menos assim (apenas um exemplo):
❓ Q1 – Qual horário usar para verificar se o cupom expirou: o momento do pedido ou o momento da confirmação do pagamento?
➡️ Recomendação: o momento do pedido, para evitar que o cupom expire enquanto o usuário está pagando.❓ Q2 – O valor mínimo para aplicar o desconto inclui o frete?
➡️ Recomendação: não. Considere apenas o subtotal dos produtos.❓ Q3 – Quantos cupons podem ser usados em um pedido?
➡️ Recomendação: um.
O erro mais comum nessa hora é responder “de acordo” a tudo. Isso só serve para carimbar o plano escrito pelo Agent; você não decide nada de fato. Uma resposta melhor mostra que você está avaliando as opções, por exemplo:
Q1 yes. Q2 não concordo: pelas regras da nossa promoção, o frete está incluído. Q3 não sei, preciso confirmar com a equipe de operações. Por enquanto, considere um cupom.
As perguntas da rodada seguinte vão se basear nessas respostas. Por exemplo: “Se o frete estiver incluído, cupons de frete e cupons de desconto por valor mínimo podem ser combinados?”. Se for preciso consultar informações no repositório, o Agent deve encarregar um subagente de fazer a pesquisa, em vez de perguntar a você. A documentação oficial menciona que é normal chegar a mais de quarenta perguntas ao longo de quatro rodadas.
Você pode considerar a etapa concluída quando:
– As perguntas aparecem em rodadas, cada uma com número e resposta recomendada, que você pode aceitar respondendo yes.
– As perguntas das rodadas seguintes se baseiam claramente nas suas respostas anteriores.
– Você discorda de pelo menos uma recomendação ou diz “não sei” depois de pensar no assunto.
– No fim, o Agent pede que você confirme se chegaram a um consenso. Antes dessa confirmação, ele não começa a trabalhar nem escreve nenhum arquivo.
Etapa 5: escreva código com /tdd, um teste por vez
Continue na mesma sessão, para manter todo o contexto que acabou de ser estabelecido. Se necessário, troque para uma versão mais econômica do modelo e digite /tdd implemente a validação de cupons de acordo com as regras que acabamos de confirmar.
Ele não vai escrever os testes imediatamente. Primeiro, vai listar os limites de interface (seams) que pretende testar e parar para você confirmar. Por exemplo, a opção A é a função pura validateCoupon(coupon, order, now), que cobre a lógica das regras, mas não testa a integração com o processo de finalização do pedido. A opção B é o checkout() do serviço de pedidos: testa essa integração, mas é mais lenta. Se ele só apresentar os nomes, pergunte o que cada seam consegue detectar e o que pode deixar passar. Aqui, vamos confirmar a opção A.
Abaixo está um exemplo do primeiro teste, usando TypeScript + Vitest. É apenas uma demonstração; a habilidade não está limitada a uma linguagem ou framework de testes:
- Arquivo de teste:
coupon.test.ts; importaiteexpectdevitestevalidateCouponde./coupon - Nome do teste: o usuário não pode usar um cupom expirado
- Cupom informado:
{ code: "SAVE10", minSubtotal: 100, expiresAt: new Date("2026-10-01") }, ou seja, válido para compras a partir de 100 yuans e com vencimento em 1º de outubro - Pedido informado:
{ subtotal: 120 }, com subtotal de 120 yuans - Horário atual informado:
new Date("2026-10-22"). O horário é passado como parâmetro, em vez de ser consultado dentro da função. Assim, o resultado é sempre o mesmo, não importa quando o teste seja executado - Resultado esperado:
expect(result).toEqual({ ok: false, reason: "expired" }), ou seja, a validação falha porque o cupom expirou
Execute o teste primeiro. Ele vai falhar porque validateCoupon ainda não existe. Em seguida, o agente escreve apenas o código necessário para fazer esse teste passar — por exemplo, verifica se now >= coupon.expiresAt e retorna que o cupom expirou. Só depois que o teste passar é que ele começa a escrever o próximo, como “rejeitar quando o subtotal não atingir o mínimo”. Observe que o resultado esperado é um valor literal, deduzido das regras, e que o nome do teste descreve o que o usuário pode fazer, não que uma determinada função interna foi chamada.
O fluxo atual do tdd é apenas “vermelho → verde”, sem a etapa de refatoração. Essa etapa foi removida em junho de 2026 porque o agente quase nunca a executava; agora, a refatoração fica por conta de /code-review. A descrição da habilidade ainda menciona red-green-refactor. Isso é um problema conhecido, mas a expressão ainda pode ativar a habilidade. Use mocks apenas para limites do sistema, como APIs externas, horário e números aleatórios; não use mocks para os próprios módulos.
O processo está funcionando quando:
– Antes de criar qualquer arquivo de teste, ele lista os seams e espera sua confirmação
– Só aparece um teste por vez: primeiro falha, depois passa e só então o próximo é escrito. Não há uma leva de testes seguida por uma leva de código
– Se você mudar o nome de uma função interna, os testes continuam passando
Quando usar as skills grill-me, tdd etc. e checklist de solução de problemas
Muita gente trava não por não saber usar as skills, mas por usá-las na situação errada. Você pode salvar a tabela abaixo e consultá-la para escolher a skill certa em cada caso.
| Sua situação | Qual usar | Descrição |
|---|---|---|
| A ideia ainda está vaga e talvez nem tenha a ver com código | /grill-me | Não precisa de repositório nem cria arquivos. Também serve para decisões de negócio e escrita |
| Você está alterando código em um repositório e quer registrar termos e decisões | /grill-with-docs | Usa o mesmo processo de perguntas e atualiza GLOSSARY.md e os ADRs |
| O trabalho é grande demais para caber em uma sessão | /wayfinder | Cria um mapa de tarefas de decisão no rastreador de issues para resolver cada uma por vez |
| Você precisa implementar um comportamento com entradas e saídas bem definidas | /tdd | Indicado para lógica de negócio, contratos de requisição e resposta, conversões de dados e validações |
| Você já tem uma especificação ou issue e quer executar tudo de uma vez | /implement | Conduz o trabalho usando /tdd nos pontos de integração combinados e executa /code-review antes de enviar as alterações |
Se não souber qual escolher, digite /ask-matt. Ele vai recomendar a skill mais adequada para a sua situação. A maioria dos problemas que surgem no uso prático pode ser resolvida consultando a tabela abaixo.
| Problema | Causa comum | Como resolver |
|---|---|---|
| Há perguntas demais — mais de cem | O escopo está grande demais ou o contexto está cheio, o que prejudica a qualidade das perguntas | Peça primeiro ao Agent para dividir o trabalho em partes menores e depois use grill em cada uma |
| A conversa termina rápido e você só responde “concordo” | Suas respostas estão passivas demais | Conteste, aponte quando o escopo estiver se desviando e diga “não sei” quando for o caso |
| Você reescreve a mesma pergunta várias vezes, mas não consegue responder | É uma questão que não dá para resolver só conversando, como a sensação de uso de uma interação | Pare de perguntar e use /prototype para criar um protótipo descartável |
| Você não consegue escolher os limites dos testes | Os pontos de integração candidatos foram apenas listados, sem explicação | Pergunte o que cada ponto consegue detectar, o que deixa passar e quanto tempo leva |
| A implementação foi escrita antes dos testes | É o comportamento padrão do modelo | Acompanhe de perto as etapas críticas e, se perceber isso, peça para voltar à fase “red first” |
| Os testes no navegador entram em um ciclo sem fim | Os testes de ponta a ponta foram escritos antes de o comportamento existir | Especifique em CLAUDE.md que os testes no navegador só devem ser escritos depois que o comportamento estiver funcionando |
| O teste só repete a implementação | Para configurações e código de integração, não há uma resposta de referência independente | Não use tdd para esse tipo de alteração; se quiser, registre a regra em CLAUDE.md |
| Cada skill aparece duas vezes | Você instalou tanto o plugin quanto as skills do skills.sh | Remova uma das instalações |
Perguntas frequentes sobre mattpocock/skills
Q1: Cerca de 300 mil estrelas significam que o resultado é garantido?
Não. O número de estrelas reflete o interesse das pessoas, mas não indica o desempenho real no seu projeto. O autor diz que o material se baseia em décadas de experiência em engenharia, mas, até agora, não há avaliações de terceiros que apresentem dados sobre ganhos de eficiência. A forma mais confiável de avaliar é seguir os critérios de validação de cada etapa deste artigo e testar tudo no seu próprio repositório.
Q2: Só dá para usar em ferramentas como Claude Code e Codex?
Não. A lista oficial inclui apenas as formas de instalação que foram verificadas. Para Agents que não aparecem nela, você pode usar o skills.sh, especificando o Agent com `-a` ou escolhendo-o de forma interativa. O README também informa que essas skills funcionam com qualquer modelo e, no fundo, são instruções escritas em Markdown.
Q3: Depois das perguntas do grill-me, devo abrir uma nova sessão para escrever o código?
Não. O contexto criado durante as perguntas é justamente a parte mais valiosa. A recomendação oficial é continuar na mesma sessão e usar `/to-spec` para gerar a especificação. No exemplo simples deste artigo, seguimos na mesma sessão e passamos direto para `/tdd`.
Q4: Se acho que há perguntas demais em cada rodada, posso fazer uma por vez?
Pode. Basta adicionar `When grilling, ask one question at a time.` ao `CLAUDE.md` global. Mas perguntar por rodada permite ver de uma vez todas as questões que você pode decidir. Vale a pena testar algumas vezes antes de mudar o comportamento.
Q5: Por que a descrição de tdd menciona red-green-refactor se, na prática, não há refatoração?
A etapa de refatoração foi removida de propósito em junho de 2026, mas a descrição ainda não foi atualizada. Esse problema é conhecido e continua em aberto. O fluxo atual é “vermelho → verde”; a refatoração fica por conta de `/code-review`. Separar a implementação da revisão em duas sessões funciona melhor.
Q6: Qual é a maneira mais prática de usar modelos diferentes nas etapas de perguntas e implementação?
Você pode configurar uma interface unificada no Claude Code ou no Codex, seguindo as instruções da etapa 3 deste artigo. Com uma única chave da APIYI em apiyi.com, dá para usar o Claude Opus 5.5 na etapa de perguntas e trocar para um modelo mais econômico na hora de implementar. O serviço só cuida da invocação do modelo; a skill é instalada normalmente.
Q7: Que tipos de alteração não são adequados para tdd?
Configurações, integrações, código de cola, anotações de tipo e operações CRUD que apenas encaminham dados não têm respostas independentes para comparar. Nesses casos, é fácil acabar escrevendo testes que apenas reproduzem a implementação. A documentação oficial reconhece que a skill ainda não ajuda a decidir se vale a pena usar TDD — essa decisão fica por sua conta. Se estiver em dúvida, use um modelo leve na APIYI, em apiyi.com, para pedir ao Agent que liste as entradas e as saídas observáveis da alteração. Se ele não conseguir fazer isso, não use tdd.
Principais aprendizados e resumo de mattpocock/skills
Principais aprendizados
- Pergunte antes de escrever: primeiro alinhe os requisitos com
/grill-me; depois, use/tddpara implementar, um teste por vez. - Escolha apenas uma forma de instalação: instale pelo plugin ou pelo skills.sh, não pelos dois. Caso contrário, cada skill aparecerá duplicada.
- Não deixe passar as dependências: na instalação manual,
grill-meprecisa degrilling, etdd, decodebase-design. - Responda com iniciativa: questione mais e diga “não sei” quando for o caso. Concordar com tudo é o erro mais comum.
- Confirme os limites dos testes primeiro: o
tddlista os limites dos testes e espera sua confirmação antes de seguir com o ciclo vermelho → verde. A refatoração não está incluída. - Escolha o modelo conforme a etapa: use o modelo mais potente para fazer perguntas e um modelo mais simples para implementar. Com a APIYI, basta uma chave API para alternar.
Resumo
O valor de mattpocock/skills não está nas cerca de 300 mil estrelas, mas em transformar duas práticas básicas de engenharia — alinhar os requisitos primeiro e validá-los em etapas pequenas — em skills que podem ser executadas repetidamente. Siga as cinco etapas deste artigo: instale, execute a configuração, escolha um modelo, esclareça os requisitos com /grill-me e escreva, com /tdd, seu primeiro teste que passa de vermelho para verde. Assim, você poderá avaliar se esse método funciona para o seu projeto.
Se quiser usar modelos diferentes na etapa de perguntas e na etapa de implementação, você pode alternar entre eles no Claude Code e no Codex usando uma única chave API pela APIYI apiyi.com. Depois, é só praticar com requisitos reais e manter o hábito de responder com iniciativa.
Referências
- GitHub – mattpocock/skills: página do repositório, com o README e todos os arquivos SKILL.md
- Link:
github.com/mattpocock/skills -
Observação: consulte aqui as formas de instalação, a lista de skills e o histórico de atualizações.
-
AI Hero – documentação de Skills: documentação oficial de skills como
grill-meetdd - Link:
aihero.dev/skills -
Observação: inclui a lista de verificação de aceitação “It’s working if” e perguntas frequentes.
-
skills.sh – mattpocock/skills: opção de instalação genérica para outros agentes
- Link:
skills.sh/mattpocock/skills - Observação: indicado para ferramentas como Cursor, OpenCode e Windsurf; as atualizações precisam ser feitas manualmente.
Autor: equipe técnica da APIYI
Contato técnico: entre em contato conosco pela página inicial do site APIYI apiyi.com. Para mais informações de integração, acesse o centro de documentação em docs.apiyi.com.
