Este repo de skills para Claude chegou a 100 mil estrelas (eis o motivo)

Autoria: Rob Shocks · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: This Claude Skills Repo Hit 100K Stars (Here’s Why) · Canal: Rob Shocks · 12:31 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Claude Code, Engenharia de software com IA

Resumo

Addy Osmani publicou seu conjunto de skills para agents, que alcançou 100 mil estrelas no GitHub. O vídeo apresenta a abordagem de Addy, organizada em seis etapas do ciclo de vida do desenvolvimento de software, e compara suas skills às de Matt Pocock e Loren Tan. Rob recomenda escolher skills conforme a complexidade e os riscos do projeto, em vez de instalar tudo. A conclusão é que esses conjuntos servem como exemplos de boas práticas que cada pessoa ou equipe pode adaptar ao próprio workflow.

Pontos-chave

As skills de Addy organizam o trabalho do agent em seis etapas: definir, planejar, construir, verificar, revisar e entregar.
O conjunto inclui 25 skills e quatro personas de revisão: engenheiro staff, engenheiro de testes, auditor de segurança e auditor de performance web.
Tabelas de antirracionalização antecipam desculpas que o agent poderia usar para pular etapas e apresentam respostas a elas.
O modo /build auto executa as tarefas após a aprovação do plano, mas mantém testes, commits separados e interrupção em caso de falha.
Matt Pocock prioriza esclarecer requisitos antes de construir; Loren Tan enfatiza investigação e verificação; Addy cobre o ciclo de vida completo.
O apresentador combina skills diferentes conforme a situação, em vez de usar todos os conjuntos ao mesmo tempo.
O nível de processo deve acompanhar os riscos: mudanças pequenas pedem pouca cerimônia, enquanto trabalho de produção ou irreversível merece revisões mais rigorosas.
Instalar skills em excesso pode aumentar o uso do context window e confundir o agent; mais skills não significam necessariamente um agent mais capaz.
Os conjuntos devem ser tratados como material de estudo: adapte o que funciona e atualize suas próprias skills com as lições aprendidas.

Capítulos

Início	Capítulo	Resumo
00:00	As skills de Addy e o ciclo de desenvolvimento	O vídeo apresenta Addy Osmani e explica como suas skills organizam o trabalho de um agent em seis etapas do ciclo de vida do software.
03:08	O que há dentro das skills	Rob destaca as personas de revisão, as tabelas de antirracionalização e práticas como o desenvolvimento orientado por dúvidas.
06:13	Comparação com Matt Pocock e Loren Tan	O vídeo contrasta o foco de cada conjunto e sugere quando recorrer às skills de cada criador.
08:51	Escolher skills conforme o tamanho do problema	Rob alerta que usar todos os conjuntos em todo projeto é exagerado e propõe ajustar o nível de processo aos riscos e à complexidade.
10:57	Aprender, adaptar e criar suas próprias skills	A conclusão recomenda estudar as práticas por trás dos conjuntos, adaptar o que funciona e aprimorar as próprias skills com a experiência.
12:01	Skills como padrão de trabalho da equipe	Rob encerra defendendo skills próprias para compartilhar padrões de qualidade e convidando o público a comentar suas experiências.

Citações

O que você está recebendo é a mente de um engenheiro experiente comprimida em markdown. — 01:02

A única função é duvidar da afirmação. — 05:10

Mais skills não significam necessariamente um agent mais inteligente. — 09:22

Não trate nenhum desses conjuntos como uma religião. — 11:29

Conceitos e entidades

Addy Osmani (pessoa): Engenheiro conhecido por seu trabalho no Google com experiência de desenvolvimento do Chrome e performance web, que publicou um conjunto de skills para agents.
Matt Pocock (pessoa): Desenvolvedor cujas skills enfatizam esclarecer requisitos e alinhar a pessoa usuária e o agent antes de começar a implementação.
Loren Tan (pessoa): Criadora do conjunto de skills chamado P Stack, apresentado como focado em investigação e verificação.
Claude Code (ferramenta): Produto da Anthropic mencionado no contexto da mudança de Addy Osmani para a empresa.
Anthropic (empresa): Empresa que criou Claude Code e para a qual Addy Osmani teria se transferido.
Neon (empresa): Plataforma apresentada no vídeo com recursos de banco de dados, armazenamento, funções, autenticação e gateway de IA.
Skills de Addy Osmani (repo): Conjunto de 25 skills e quatro personas de revisão que codifica práticas de engenharia de software para agents.
P Stack (repo): Conjunto de skills associado a Loren Tan, descrito como útil para problemas difíceis, investigação, arenas e agents de longa duração.
Desenvolvimento guiado por especificações (conceito): Abordagem que define requisitos e planos antes da implementação e verifica o trabalho ao longo do processo.
Desenvolvimento orientado por dúvidas (conceito): Prática descrita no vídeo em que uma revisão separada questiona decisões importantes durante a construção.
Ciclo de vida do desenvolvimento de software (conceito): Processo de seis etapas apresentado para as skills de Addy: definir, planejar, construir, verificar, revisar e entregar.

Tradução completa (pt-BR)

00:00 Então, Addy é provavelmente um dos engenheiros mais respeitados do Google há bem mais de uma década, e recentemente se mudou para a Anthropic, criadora do Claude Code. E agora ele acabou de disponibilizar em open source todas as suas skills para agents. Então, depois de chegar a 100 mil estrelas, provavelmente é um dos repos de IA mais populares do GitHub neste momento. Se você acompanha o canal, já sabe que analisei o P Stack, do Loren Tan, da Cursor, e também as skills do Matt Pocock. Então, Addy é o terceiro dos três grandes. Agora que temos os três, dá para ver que eles resolvem problemas diferentes.

00:31 Ao final deste vídeo, você vai saber o que Addy está fazendo, quando recorrer a cada pacote e por que acho que não é preciso usar todos eles em todos os seus projetos. Às vezes, podem ser um pouco exagerados. Eu sou Rob, este é o Switch to Mention, e vamos começar vendo como Addy pensa sobre o conjunto de skills dele. Um breve contexto: se você não sabe quem é Addy, ele é uma lenda no mundo do JavaScript. Escreveu Learning JavaScript Design Patterns e liderou o trabalho de experiência para desenvolvedores do Chrome e de desempenho web no Google. Se você já usou o Lighthouse ou leu sobre Core Web Vitals, provavelmente já foi afetado pelo trabalho dele em algum momento. Então,

01:02 Acho que isso é muito relevante porque, quando alguém como Addy escreve: “É assim que você quer que um agent desenvolva software”, vale a pena prestar atenção. O que você está recebendo, na prática, é o cérebro de um engenheiro experiente, comprimido em Markdown. E é isso que adoro nas skills. Antes, a gente lia um monte de livros da O’Reilly sobre boas práticas; agora, basicamente estudamos e examinamos as skills dos melhores profissionais. Então, aqui está a ideia principal. A abordagem de Addy é um ciclo de vida com seis etapas: definir, planejar, construir, verificar, revisar e entregar. E cada etapa vem acompanhada de um comando slash.

01:34 Se você assiste aos meus vídeos há dois anos ou já fez algum tipo de desenvolvimento orientado a especificações com B Mad ou Superpowers, isso vai parecer bem familiar. E esse é justamente o ponto. As skills do Matt têm seu próprio vocabulário: grilling, wayfinder e fog of war. O P Stack tem potato mode e arenas. A abordagem de Addy é a mais tradicional em relação ao ciclo de vida de desenvolvimento de software. Você não precisa aprender uma metáfora: é o ciclo de vida de desenvolvimento de software feito direito com um agent. Então, acho que, entre todas as pilhas, esta se encaixa muito bem em uma equipe de desenvolvimento já existente ou em uma empresa. O spec escreve um PRD adequado,

02:07 que cobre objetivos, estrutura, estilo de código, testes e limites antes de qualquer linha de código. O plan divide isso em tarefas pequenas e atômicas, com critérios de aceitação, e o build implementa uma fatia vertical pequena de cada vez. Você implementa, testa, verifica, faz o commit e, em seguida, testa, revisa e entrega. Tem um modo de que gosto muito, chamado slash build auto. Você aprova o plano uma vez e, depois, ele executa cada tarefa de forma autônoma. Isso evita que você tenha que intervir entre as tarefas, mas não elimina a

02:37 verificação, que é importante você fazer. Então, cada tarefa continua sendo orientada por testes, é registrada em um commit próprio e, se algo falhar, o processo para. Acho que essa é mais ou menos a maneira certa de fazer autonomia. O slash constraints é basicamente outro tipo de entrevista, para avaliar seu nível ou padrão de qualidade; depois, ele registra isso em um arquivo constraints.md. Há também o slash web perf, para desempenho web. Ele faz uma auditoria de desempenho e, considerando quem escreveu isso — Addy Osmani, o rei do desempenho web —, é de se esperar que seja

03:08 bom. E o slash code simplify serve para quando o código funciona, mas ninguém quer mexer nele, e você quer simplificá-lo ou dividi-lo em partes menores. Há muita sobreposição entre o que Lauren aborda e o que Matt Pocock aborda em skills semelhantes. No total, são 25 skills, além de quatro perfis de revisão: um engenheiro de nível staff, um engenheiro de testes, um auditor de segurança e um auditor de desempenho web. Certo, vamos olhar por dentro das skills. Como sempre digo neste canal, os comandos slash não são a parte interessante. São os arquivos das skills. É aqui que

03:39 a gente realmente entra na cabeça de um engenheiro de software. Cada skill tem o que Addy chamaria de uma tabela antirracionalização. É uma lista das desculpas que um agent vai dar para pular uma etapa. Vemos agents fazendo isso o tempo todo. E, ao lado de cada desculpa, há uma resposta explicando por que ele não deve pular a etapa. Assim, ele vai verificar coisas e rastros de raciocínio como: “Isso é simples demais para testar” ou “Testei manualmente”. Se você já trabalhou com agents ou com desenvolvedores juniores, já ouviu todas essas desculpas. Registrar as desculpas de antemão é uma decisão muito inteligente. Aqui vai uma

04:10 dica rápida sobre trabalhar com vários agents, graças aos nossos amigos da Neon. Ao desenvolver código novo com agents, você vai querer ter vários feature branches diferentes, só para garantir que não afete o branch principal de produção. Infelizmente, é um pouco mais complicado do que isso. Temos o branch principal, mas também precisamos de um branch do banco de dados e talvez até de algum armazenamento. Caso contrário, você acaba com um branch de preview, talvez com uma cópia do Postgres, o que está tudo bem, mas aí ele pode acabar enviando o arquivo para o armazenamento errado. E podemos causar uma falha em produção. Tenho usado a Neon

04:40 há anos para as minhas necessidades de banco de dados, por causa do branching superior deles e de muitos outros motivos. Mas talvez você não tenha percebido que agora eles são uma plataforma completa: banco de dados, armazenamento, funções, autenticação e gateway de IA. Por que isso é ótimo, você deve estar se perguntando. Seu agent, usando a CLI, agora pode criar um branch de tudo o que precisa para trabalhar com segurança. Isso inclui o banco de dados, as funções, os buckets, o usuário de autenticação, tudo de que você precisar. Cada agent recebe sua própria cópia instantaneamente. Quem acompanha o Rob Shox pode se cadastrar gratuitamente na Neon pelo link na descrição abaixo. Então, este

05:10 é muito interessante. Chama-se desenvolvimento orientado pela dúvida. Já ouvimos falar de desenvolvimento orientado ao domínio; este é desenvolvimento orientado pela dúvida. Para qualquer decisão não trivial ou importante, ele inicia uma revisão em um contexto novo, cuja única tarefa é questionar a afirmação. Afirmação, extração, questionamento, conciliação, parar. É basicamente uma revisão adversarial durante a construção, não apenas no final. Conforme você começa a ler as outras skills, vai reconhecendo alguns velhos conhecidos e paradigmas. A lei de Hiram na skill de design de API

05:41 diz que alguém acabará dependendo de todo comportamento observável da sua API. E, na skill de testes, a regra da Beyoncé: se você gosta disso, coloque um teste para isso. Não vou cantar. E a cerca de Chesterton, na simplificação de código: não derrube a cerca antes de saber por que ela está ali. Desenvolvimento baseado em trunk, commits pequenos e atômicos, código como passivo. Então, esse é basicamente o cérebro de engenharia de software de Addy Osmani transformado em instruções para agents. Sinceramente, mesmo que você nunca instale isso, só ler as skills já é um curso de engenharia de software melhor do que a maioria.

06:13 Então, como isso se compara aos outros dois? As skills do Matt Pocock basicamente perguntam: estamos de acordo sobre o que vamos construir? Você e o agent estão de acordo? Você está definindo o domínio. A skill mais popular dele seria grill me, em que o agent faz perguntas para você antes de escrever qualquer coisa. Depois, há a ideia de um glossário de linguagem compartilhada, que seria ADORs, ou registros de decisão, e então você tem specs e tickets. Matt ainda segue o SDLC tradicional; só está abordando-o de outra maneira.

06:45 Muitas das skills dele colocam o esforço no início, antes de você começar a programar. E ele já disse abertamente que é contra frameworks. Ele acha que coisas como BDD, Spec It e Superpowers tiram seu controle. Então, as skills dele são deliberadamente pequenas, combináveis, e você pode usá-las onde precisar e modificá-las por conta própria. Minha interpretação do P Stack de Lauren Tan é que ele trata de provar que algo funciona. Lauren deliberadamente não tem skills de planejamento. A frase dela é: o melhor spec é o código. Todo o peso recai mesmo sobre a investigação, a

07:16 verificação e revisão multimodal depois do fato. A compilação ter sido concluída com sucesso não conta como evidência. Precisamos comprovar isso. As skills de Adi são mais voltadas a verificar se seguimos todo o processo. Ele é o único dos três que realmente cobre todo o ciclo de vida do SDLC, até a integração e o deploy contínuos, a observabilidade, a descontinuação e o lançamento. Provavelmente é o mais adequado para equipes e o mais portátil, já que pode ser instalado em cerca de 70 agents diferentes. O que acabei fazendo pessoalmente foi combinar um pouco de todos eles

07:48 e não uso todos ao mesmo tempo. Uso skills diferentes em etapas diferentes. Tenho versões leves, médias e pesadas do runtime das minhas skills. Então, recorro ao Pok Arc quando o problema é nebuloso, quando não tenho certeza do que quero ou quando estou trabalhando em uma base de código com a qual vou conviver por anos e me importo muito com o design. Grill me ainda é a melhor skill para instalar primeiro para isso. Eu recorreria a ela quando você está em uma equipe que entrega para produção e quer um processo previsível que todos reconheçam, ou quando quer todos os critérios de qualidade

08:19 sem precisar criá-los por conta própria. Meu próprio conjunto de skills se encaixa mais nesse tipo de processo, porque trabalho com equipes de desenvolvedores e ensino a eles como aplicar agents. Depois, eu recorreria ao P Stack quando a coisa fica realmente complicada. É um bug que você não consegue reproduzir. Você quer aplicar swarms e arenas a um problema. Há uma migração. Você tem agents de longa duração. Talvez seja uma execução durante a noite e você precise confiar neles quando acordar. E, claro, se você usa Cursor e tem vários modelos, porque as skills dela funcionam muito bem como plugin no Cursor. E você também vai notar que há uma enorme

08:51 sobreposição e que eles pegam emprestado uns dos outros o tempo todo. Não é que estejam realmente pegando emprestado uns dos outros. É só que os engenheiros de software convergem para as mesmas formas de construir software. Então, haverá muita sobreposição. E, de novo, engenharia de software envolve opiniões. Basta escolher a melhor opinião e aplicá-la ao seu próprio workflow. Basicamente, são apenas três perspectivas sobre o mesmo ofício. Então, minha opinião sobre tudo isso é que você realmente não precisa de todas essas skills em cada projeto. Isso é um exagero enorme. Os agents estão ficando muito inteligentes agora, e uma das melhores

09:22 coisas que você pode fazer é revisar seu arquivo agents.md ou suas skills existentes e começar a reduzi-las e removê-las, porque você vai se surpreender com o quanto os modelos são poderosos. Estou pensando que, hoje, as skills têm mais a ver com “é assim que eu gosto de trabalhar” do que necessariamente ensinar algo novo ao agent. Na verdade, arquivos de skill muito longos e um excesso de skills só vão inflar e confundir sua context window. Então, se você só está mudando a cor de um botão, não precisa de um PRD, uma divisão de tarefas, uma revisão de arena em cinco eixos do P Stack nem

09:55 de um auditor de segurança. Você só precisa mudar o botão e dar uma olhada. Então, penso nisso em termos de nível de esforço. A formalidade do processo deve corresponder ao risco do que você está fazendo. Para um pequeno ajuste, simplesmente faça e depois confira você mesmo. Se for algo muito visual ou baseado em protótipo, faça você mesmo, confira rapidamente, atualize a página e siga em frente. Você está iterando com o agent. Para um recurso pequeno, faça uma sessão rápida de Grill me ou de descoberta para alinhar as expectativas e, depois, algum desenvolvimento orientado a testes. Se for um recurso grande ou nebuloso que você está tentando entender, então faça uma especificação e um plano dividido em

10:26 fases e, depois, verifique cada uma entre as etapas. Se for para produção, envolver segurança ou for algo irreversível, é aí que você faz uma revisão completa, desenvolvimento orientado pela dúvida e todo o reforço de segurança que vem junto. Até o próprio Adi diz isso sobre as skills dele. O guia de adoção recomenda uma implementação gradual, priorizando a verificação, em uma base de código existente. Não instale 25 skills e tente executar tudo. Isso é sobrecarga total. E há também um custo prático. Cada skill que você instala é algo que o agent precisa considerar. E você pode acabar

10:57 acionando essas skills automaticamente por acidente, quando não quer. Mais skills não significam necessariamente um agent mais inteligente. Então, acho que a verdadeira lição aqui — e venho dizendo isso há algum tempo — é que aprender essas skills é, na verdade, aprender boas práticas de desenvolvimento de software: desenvolvimento orientado a testes, pequenas entregas verticais, combinar os requisitos antes de construir e registrar por que você tomou uma decisão. Você não remove a cerca até saber por que ela está ali. Não saia removendo nada até saber especificamente por que está ali. E, depois, comprove que funciona com o sistema real. Se você só vê os testes passando, isso

11:29 não significa que seu aplicativo funciona. Você precisa testá-lo de verdade, da maneira adequada. E nada disso é novidade. Não é como se algum desses caras tivesse inventado essas ideias. Matt Pocock dá crédito a The Pragmatic Programmer e a Domain-Driven Design. Andy é basicamente o livro de engenharia do Google. Lauren tem anos de experiência com React e na Meta. A skill ali é apenas uma forma de apresentar essas ideias em um formato que um agent consiga seguir. Então, não trate nenhum desses pacotes como uma religião. Pense neles como um livro da O’Reilly. Você pode instalá-los e lê-los. Aproveite o que funciona e depois crie suas próprias skills com base neles.

12:01 E isso é basicamente codificar a forma como você trabalha. Você compartilha o melhor disso com sua equipe, e eles compartilham de volta. Essa é a sua stack e o seu próprio padrão de qualidade. Basicamente, esse é o harness da sua equipe ou o seu harness pessoal. E ele será feito sob medida para você e vai ajudar a trabalhar muito mais rápido. E toda vez que seu agent fizer alguma besteira, não seja infantil. Não xingue. Simplesmente atualize sua skill com base no que aprendeu. Foi exatamente assim que esses três pacotes foram criados. Então, se quiser se aprofundar na criação da sua própria biblioteca de skills e de workflows de agents, é exatamente isso que fazemos na Switch — para mencionar o curso e a comunidade. O

12:31 link está na descrição abaixo e você pode entrar na lista de espera. Então, quero saber nos comentários quais pacotes de skills vocês estão usando agora. Vocês criaram conjuntos de skills próprios? Fiquem à vontade para compartilhá-los nos comentários. Quero saber o que as pessoas estão realmente criando e usando em produção. Se isso foi útil, inscreva-se, porque esta é uma série. Se você perdeu, o vídeo sobre o P Stack e o vídeo do Matt Pocock estão na tela agora. Assista a esses vídeos em seguida.

Transcrição original

[00:00] So, Addy’s money, he’s probably one of the most respected engineers at Google for well over a decade, and he’s recently just moved to Anthropic, the maker of Claude code. And he’s just gone and open-sourced all his agent skills. So, 100,000 stars later, it’s probably one of the most popular AI repos on GitHub right now. So, if you’ve been following the channel at all, you’ll know I’ve already broken down P Stack from Loren Tan at Cursor, and then also Matt Pocock’s skills. So, Addy is the third of the big three. Now that we’ve got all three, you can see that they’re solving different problems.

[00:31] By the end of this video, you’ll know what Addy’s doing, when to reach for each pack, and why I think you don’t need to run all of these across all of your projects. They can be a bit of overkill sometimes. I’m Rob, this is Switch to Mention, and let’s start with how Addy thinks about his skill set. So, quick context, if you don’t know who Addy is, he’s a bit of a legend in the JavaScript world. He wrote Learning JavaScript Design Patterns, he led the Chrome developer experience and web performance work at Google. If you’ve ever run Lighthouse or read about Core Web Vitals, you’ve probably been affected by his work at some stage. So,

[01:02] I think that’s really relevant because when somebody like Addy writes down, “This is how you want an agent to engineer software,” you want to pay attention. What you’re really getting is a seasoned engineer’s brain compressed into markdown. And that’s what I love about skills. Before we read tons of O’Reilly books on best practices, now we’re basically studying and examining skills from the top performers. So, here’s the big idea. Addy’s approach is a life cycle, six stages: define, plan, build, verify, review, ship. And each stage has a slash command to go with it.

[01:34] If you’ve been watching my videos for the last 2 years, or you’ve done any kind of spec-driven development with B Mad or Superpowers, this will feel very familiar. And that’s kind of the point. Matt’s skills have their own vocabulary, grilling and wayfinder and fog of war. P Stack has potato mode and arenas. Addy’s is the most traditional to the software development life cycle. You don’t have to learn a metaphor, it’s the software development life cycle done properly with an agent. So, I think of all the stacks this can fit in very well with an existing development team or in the enterprise. So, spec writes a proper PRD

[02:07] covering objectives, structure, code style, testing, and boundaries before a line of code. Plan breaks that into small atomic tasks with acceptance criteria, and build implements one thin vertical slice at a time. You implement it, you test it, you verify, you commit it, then you test review and ship. So, there’s one mode that I really like, it’s called slash build auto. So, you approve the plan once and then it runs every task autonomously after that. It removes you kind of having to step in between tasks, but it doesn’t remove the

[02:37] verification, which is important for you to look at. So, every task is still test driven, and it’s committed on its own, and then it stops if something fails. So, I think that’s kind of like the right way to do autonomy. So, slash constraints basically is another style of interview just to test out what your quality level or quality bar is, and then it writes this to a constraints.md file. Then there is a slash web perf for web performance. It does a performance audit, which you know, given who wrote this, Addy Osmany, the the king of web performance, you’d hope this is going to

[03:08] be good. And then slash code simplify is for when the code works, but nobody really wants to touch it, and you want to simplify or break it down. There’s a lot of overlap between what Lauren talks about and also what Matt Pocock talks about in terms of similar skills. So, there’s 25 skills in total plus four reviewer personas. There’s a staff engineer, a test engineer, a security auditor, and a web performance auditor. Okay, so let’s look inside the skills. As always on this channel, the slash commands aren’t the interesting part. The skill files are. Here’s where we

[03:39] really get inside a software engineer’s brain. So, every skill has what Addy would call a anti-rationalization table. It’s a list of the excuses an agent will make to skip past a step. We see agents doing this all the time. And then you’ve got the rebuttal to why it would skip right next to it. So, it’ll test for things and reasoning traces like this is too simple to test or I tested it manually. So, if you’ve worked with agents or you’ve worked with juniors, you’ve heard all of these excuses before. And writing the excuses down in advance is really a smart move. Here’s a

[04:10] quick tip on working with multiple agents, thanks to our friends over at Neon. When you’re developing new code with agents, you’re going to want to have multiple different feature branches just to be sure that you don’t impact the main production branch. Unfortunately, it gets a bit more complicated than that. We have the main branch, but we also need a database branch and maybe even some storage. Otherwise, what you get is a preview branch, maybe it’s got a copy of Postgres and that’s okay, but then it might end up uploading the file to the wrong storage. And we end up with a production break. I’ve been using Neon

[04:40] for years for my database needs just because of their superior branching and a whole lot of other reasons. But what you might not have noticed is now they’re a full platform, database, storage, functions, auth, and AI gateway. Why is that a beautiful thing, you might ask? So, your agent using the CLI can now create a branch of everything it needs to be safe. That includes your database, your functions, your buckets, your auth user, anything that you need. Each agent gets its own copy instantly. Rob Shox viewers can sign up to Neon for free via the link in the description down below. So, this one

[05:10] is really interesting. It’s called [snorts] doubt-driven development. We’ve heard of domain-driven development, this is doubt-driven development. So, for any non-trivial decision or important decision, it spins up a fresh context review and the one job is to doubt the claim. So, claim, extract, doubt, reconcile, stop. It’s basically adversary review during the build, not just at the end. As you start to read through the rest of the skills, you start spotting some old friends and paradigms. Hiram’s law in the API design

[05:41] skill, so every observable behavior of your API will eventually be depended on by somebody. And then the Beyonce rule in the testing skill, if you like that you should put a test on it. I’m not going to sing this. And Chesterton’s fence in code simplification, don’t delete the fence until you know why it’s there. Trunk based development, small atomic commits, code as a liability. So, that’s basically Audia Imani’s software engineering brain turned into agent instructions. Honestly, if you never install this, just reading through the skills is a better software engineering

[06:13] course than most. So, how does this compare to the other two? So, Matt Pocock’s skills basically are asking, do we agree on what we’re building? So, do you and the agent agree? You’re setting up the domain. His most popular skill would be grill me, and that’s basically where the agent interrogates you before it writes anything. Then there’s the idea of a shared language glossary, which would be ADORs, which are decision records, and then you’ve got specs and tickets. Matt still falls in with the traditional SDLC, it’s just he is approaching it in a different way.

[06:45] A lot of his skills put the effort up front before you actually begin to code. And he’s openly said he’s anti-framework. He thinks things like BDD, Spec It, Superpowers take away your control. So, his skills are deliberately small, they’re composable, and you can use them where you need to and hack them yourself. My interpretation of Lauren Tan’s peace talk is really about can you prove it works. Lauren deliberately has no planning skills. Her line is the best spec is the code. All the weight really is on the investigation, the

[07:16] verification, and multimodal review after the fact. The build passed doesn’t count as evidence. We need to prove that out. Adi’s skills then are more around did we follow the whole process. He’s the only one of the three that really covers the full SDLC life cycle right through to continuous integration and deployment, observability, uh deprecation, and shipping. It’s probably the most team friendly and the most portable since it installs into something like 70 different agents. What I’ve ended up with personally is a mix

[07:48] of all of these together and I don’t use them all at the same time. I’ll use different skills at different points. I’ve got light, medium, and heavy versions of my skill runtime. So, reach for Pok Arc when the problem is fuzzy, when you’re not sure what you want, or you’re working on a code base you live with for years and you really care about the design. Grill me is still the single best skill I’d install first to do that. I’d reach for when you’re on a team shipping to production and you want a predictable process everyone recognize, or when you want all the quality gates

[08:19] without designing them yourself. My own skill set falls more in this kind of a process because I’m working with teams of developers and teaching them how to apply agents. Then I’d reach for P Stack when it gets really gnarly. It’s a bug you can’t reproduce. You’re looking to apply swarms and arenas against a problem. There’s a migration. You’ve got long-running agents. Maybe it’s an overnight run and you need to trust them when you wake up. And of course, if you’re running Cursor and you’ve got several models because her skills work really well as a plugin with Cursor. And you’ll also notice that there’s huge

[08:51] overlap and they borrow from each other constantly. It’s not that they’re actually borrowing from each other. It’s just that software engineers converge on how to build software all together at the same time. So, there is going to be a lot of overlap. And again, software engineering is opinionated. You just pick the best opinion and apply it to your own workflow. They’re basically just three angles here all on the same craft. So, my actual opinion on all of this, you really don’t need all of these skills on every single project. That is a massive overkill. Agents are getting super smart now and one of the best

[09:22] things you can do is actually run through your agents.md file or your existing skills and actually start to pair them back and prune them because you’ll be surprised at how powerful the models are. I’m thinking that skills now are more about this is how I like to work as opposed to necessarily teaching the agent anything new. In fact, having really long skill files and an excess of skills is just going to bloat and confuse your context window. So, if you’re just changing a button color, you don’t need a PRD, a task breakdown, a five-axis arena review from P stack, or

[09:55] a security auditor. You just need to change the button and look at it. So, the way I think about it is effort level. Ceremony should match the stakes of what you’re working on. So, a small tweak, just do it and then check it yourself. If it’s very visual or prototype-based, just do it yourself, check it quickly, refresh, and move on. You’re iterating with the agent. If it’s a small feature, a quick uh grill me or discovery session so that you’re aligned, and then some test-driven development. If it’s a big or fuzzy feature you’re trying to figure out, then a spec and a plan broken down into

[10:26] phases, and then you verify each one in between. If it’s production, uh there’s security involved, or anything irreversible, that’s when you bring out the full review, doubt-driven development, and then all the security hardening that comes with it. So, even Adi says this about his own skills. His adoption guide to them is a gradual verification-first rollout on an existing codebase. Don’t install 25 skills and try to run everything. That’s complete overload. And there is a practical cost here, too. Every skill you install is something the agent has to consider. And then you might end up

[10:57] auto-triggering these skills by accident when you don’t want them. More skills doesn’t necessarily mean a smarter agent. So, I guess the real lesson here is, and I’ve kind of been saying this for a while, learning these skills is really learning good software development practice. Test-driven development, small vertical slices, agreeing on requirements before you build, writing down why you made a decision. You’re not deleting the fence until you know why it’s there. Don’t go deleting anything until you know specifically why it’s there. And then proving it works against the real thing. If you just see green light test, that

[11:29] doesn’t mean your app works. You need to actually test it properly. And none of this is new. It’s not like any of these guys invented this. Matt Pocock credits the pragmatic programmer and domain-driven design. Andy is basically Google’s engineering book. Lauren has years of React and meta experience. The skill there is just those ideas in a format that an agent can follow. So, don’t treat any of these packs as a religion. Treat them as kind of like an O’Reilly textbook. You can install them, read them. You steal what works and then build your own skills on top of them.

[12:01] And that’s basically encoding how you work. You’re sharing the best of that with your team and they share back. It’s your stack and it’s your own quality bar. This is basically your own team or your own personal harness. And that’s going to be bespoke to you and help you move a whole lot faster. And every time your agent screws something up, don’t be a child. Don’t swear at it. Just go and update your skill based on new learnings. That’s exactly how all of these three packs were built. So, if you want to go deeper on building your own skills library and agent workflows, that’s exactly what we do with Switch to mention the course and community. The

[12:31] link is in the description below and you can get on the wait list. So, I’d love to know in the comments which skill packs are you running right now? Have you written skill sets of your own? Feel Feel free to share them in the comments. I’d love to know what people are actually building and using in production. If this is useful, subscribe because this is a series. If you missed them, the P stack breakdown and Matt Pocock video are on the screen right now. You should watch those next.