Potato Mode + Claude Code são uma combinação e tanto!

Autoria: AICodeKing · 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: Poteto Mode + Claude Code is SOMETHING ELSE! · Canal: AICodeKing · 06:56 · Assistir no YouTube

Tópicos: Agentes de IA, Claude Code, Engenharia de software com IA, Open source e ecossistemas de software

Resumo

O vídeo apresenta o Pstack, uma coleção open source de skills criada por Potato para ajudar agentes de programação a investigar antes de editar, manter mudanças pequenas e verificar os resultados. A demonstração mostra como adaptar as instruções ao Claude Code e usar comandos para corrigir bugs, entender o código e planejar funcionalidades. Também explica como comparar abordagens com Arena, dividir investigações com Swarm e revisar implementações com Interrogate. O apresentador recomenda verificar o comportamento real do app e considerar o custo de agentes extras e rodadas de revisão.

Pontos-chave

O Pstack orienta Claude Code a reproduzir bugs e confirmar suas causas antes de fazer alterações.
O playbook de correção recomenda remover mudanças quando as evidências contradizem a hipótese inicial.
Os comandos how, why e teach ajudam a rastrear o fluxo do código, entender decisões anteriores e aprender como uma correção funciona.
O comando architect ajuda a esclarecer decisões de design antes da implementação e favorece soluções pequenas.
Arena compara propostas independentes de múltiplos agents para uma mesma tarefa.
Swarm divide investigações em tarefas específicas e reúne as descobertas, incluindo verificações inconclusivas.
Interrogate reúne avaliações independentes, mas não aplica automaticamente todas as sugestões.
O resultado deve ser verificado no app; uma compilação bem-sucedida não garante que a funcionalidade esteja correta.
Agentes extras e rodadas de revisão podem consumir a cota do Claude Code ou o orçamento de API.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação do Pstack e configuração	O vídeo explica como o Pstack ajuda Claude Code a investigar antes de editar e como adaptar suas skills ao projeto.
01:35	Investigar e corrigir bugs	O exemplo de uma busca com resultados fora de ordem mostra como reproduzir a falha, confirmar a causa e verificar a correção.
03:14	Planejar e comparar implementações	O comando architect planeja uma funcionalidade de exportação, enquanto Arena e Swarm ajudam a comparar abordagens e dividir investigações.
04:47	Revisão e verificação da funcionalidade	Interrogate reúne avaliações independentes, e o exemplo ressalta a importância de testar o arquivo exportado no próprio app.
06:25	Custos e recomendações finais	O apresentador recomenda começar com revisões focadas, considerar o custo de uso e avaliar o resultado pelo patch e pelas verificações executadas.

Citações

Reproduza o bug de busca no app em execução, encontre a causa, faça a menor correção e verifique a mesma interação depois. — 01:35

Mostre a falha, explique a causa e mostre a mesma coisa funcionando depois. — 02:08

Uma verificação inacabada não deve se transformar silenciosamente em aprovação. — 04:47

Uma compilação bem-sucedida não diz se o arquivo contém os dados certos. — 05:20

Eu avalio pelo patch e pelas verificações que ele executou. — 06:25

Conceitos e entidades

pstack (repo): Repositório open source de skills para orientar agentes de programação em investigação, implementação e revisão.
Potato (pessoa): Engenheira que trabalha na Cursor e na equipe principal do React, segundo o vídeo.
Claude Code (ferramenta): Agente de programação usado na demonstração para adaptar as skills e trabalhar no projeto.
Potato Mode (conceito): Ponto de entrada principal que aplica os playbooks do Pstack a uma tarefa descrita pelo usuário.
Arena (conceito): Recurso que envia a mesma tarefa a múltiplos agents para comparar propostas independentes.
Swarm (conceito): Recurso que divide o trabalho entre agents com responsabilidades específicas e reúne suas descobertas.
Interrogate (conceito): Recurso de revisão que coleta avaliações independentes e analisa a relevância das descobertas.
Cursor (empresa): Empresa em que Potato trabalha, conforme descrito no vídeo.

Tradução completa (pt-BR)

00:00 [música] >> Oi, bem-vindos a mais um vídeo. Então, [música] você pede ao Claude Code para corrigir um bug. Ele edita vários arquivos, executa os testes e diz que corrigiu. Você abre o app e o mesmo bug continua lá, ou pede um botão de exportação e, de alguma forma, acaba com um novo framework para manter. P stack é uma coleção de skills que faz o Claude investigar antes de editar, manter a correção pequena e verificar se aquilo que você pediu realmente funciona. Ela também oferece maneiras de comparar designs, dividir investigações e pedir a outro agent que revise o resultado.

00:33 Ela vem de Potato, que trabalha na Cursor e na equipe principal do React. Essas são as skills que ela usa no próprio fluxo de trabalho de engenharia, e são open source sob a licença MIT. Foram criadas para a Cursor, mas você pode adaptar as instruções para o Claude Code ou outro agent de programação com skills ou regras personalizadas. Vamos nos concentrar no Claude Code, então vamos direto ao assunto. Para configurar, abra o Claude Code no seu projeto e passe a ele o repo de P stack, vinculado abaixo. Peça que adapte as skills ao seu projeto, preserve as instruções existentes e use as ferramentas e os modelos

01:04 disponíveis, além de verificar se tudo funciona. Peça que informe se precisar de mais alguma coisa. Deixe o Claude cuidar das alterações de compatibilidade. Depois de verificar a configuração, seu principal ponto de entrada é {slash} potato-mode. Dê a tarefa e uma descrição clara de como seria um resultado funcional. Os playbooks orientam o Claude ao longo das etapas. Aqui vai um exemplo. Você tem uma caixa de pesquisa e, quando digita rápido, às vezes os resultados voltam para uma pesquisa anterior. Eu diria: {slash} potato-mode, reproduza o bug de pesquisa no app em execução, encontre a causa, faça a menor correção possível e verifique a mesma interação

01:35 depois. Deixe as alterações prontas para revisão. O playbook de correção de bugs instrui o Claude a reproduzir a falha antes de escolher uma correção. Neste exemplo, ele deve observar as requisições e verificar qual resposta atualiza a página. Talvez uma requisição mais antiga termine atrasada e substitua os resultados mais recentes. Isso é algo que o Claude precisa confirmar. Se as evidências apontarem para outra coisa, ele precisa seguir essa pista. E gosto muito deste detalhe. Se o Claude tentar algo e as evidências refutarem sua teoria, o playbook manda remover as alterações feitas com base nela. Caso contrário, uma sessão de depuração pode deixar você com

02:08 cinco soluções provisórias e sem saber qual delas ajudou. Depois de encontrar a causa, capture um teste que falhe, se houver uma maneira simples de fazer isso, e então corrija o problema. Por fim, repita a interação original. Faça aquela requisição mais antiga terminar atrasada e verifique se a pesquisa mais recente ainda prevalece. É isso que eu gostaria de ver antes de aceitar o patch. Mostre a falha, explique a causa e mostre a mesma coisa funcionando depois. Às vezes, porém, você precisa que o Claude entenda o código antes mesmo de saber o que mudar. É aí que entram how, why e teach. Com {slash} how, você poderia perguntar: “Como os filtros de pesquisa passam deste formulário para a consulta ao banco de dados?” O Claude rastreia o

02:42 código e explica o fluxo. É útil quando você abre um projeto e não faz ideia de onde as coisas estão. {slash} why investiga os motivos por trás do código usando o histórico e as evidências a que consegue acessar. Digamos que haja um limite de tentativas que pareça arbitrário. Pergunte por que ele foi adicionado antes de pedir ao Claude para removê-lo. Pode haver um motivo que não seja óbvio só olhando para a função. Depois, use {slash} teach quando quiser entender a resposta por conta própria. Depois da correção da pesquisa, peça ao Claude que explique como as requisições ficaram fora de ordem e por que essa alteração impede isso. Gosto dessa abordagem para aprender enquanto desenvolvo. Você pode fazer perguntas de acompanhamento até entender o código que vai manter. Agora,

03:14 vamos adicionar aquele botão de exportação. Use {slash} architect e diga: “Projete um recurso de exportação que baixe os resultados filtrados no momento.” Mostre como a página, a API e o código de exportação se encaixam antes de implementar. Isso faz o Claude pensar nas decisões desde o início. Quais filtros se aplicam? Qual pode ser o volume de dados retornado? Podemos reutilizar a consulta existente? Você quer essas respostas antes que ele tenha escrito metade do recurso. Os princípios de P stack também o incentivam a manter a solução pequena. Para um painel simples, talvez baste reutilizar o que você já desenvolveu. Não quero um

03:46 novo sistema de tarefas, a menos que a exportação realmente precise de um. Se houver uma decisão de design que valha a pena comparar, use Arena. Arena envia a mesma tarefa para vários agents e pede que produzam opções independentes. O agent líder as compara, obtém outra avaliação, escolhe uma como base e incorpora ideias úteis das outras tentativas. Depois, verifica o resultado combinado. Para a exportação, você poderia comparar retornar o arquivo diretamente com prepará-lo em uma tarefa em segundo plano. Dê às duas tentativas os mesmos requisitos e veja como lidam com o volume de dados esperado, a complexidade e a

04:17 experiência do usuário. Isso é útil quando a primeira ideia do Claude parece plausível, mas você gostaria de ver outra abordagem antes de se comprometer com ela. Swarm ajuda quando o trabalho pode ser dividido. Um agent poderia rastrear os filtros do backend, outro poderia inspecionar o estado dos filtros na página e um terceiro poderia verificar os testes existentes. Cada um recebe uma tarefa específica, e o agent líder reúne as descobertas. Você pode fazer o mesmo entre pacotes em um repo maior. Você recebe um relatório com os problemas encontrados e as partes que os agents não conseguiram verificar. Esse último ponto é importante. Uma

04:47 verificação não concluída não deve virar silenciosamente uma aprovação. Depois que o Claude criar a exportação, use /interrogate para revisá-la. Peça aos revisores que verifiquem se ela respeita os filtros selecionados e trata as falhas corretamente. Interrogate obtém revisões independentes e depois avalia as descobertas. Quais problemas poderiam comprometer o recurso? Quais sugestões valem a pena considerar? Quais críticas estão erradas ou não levam o contexto em conta? Gosto que ele peça ao agent líder para tomar essas decisões. Revisões feitas por IA podem gerar muito trabalho extra se você tratar toda sugestão como um

05:20 requisito. Essa skill fornece um parecer de revisão sem aplicar automaticamente todas as alterações propostas. Use os modelos disponíveis na sua configuração do Claude Code para essas funções. Outro revisor pode perceber algo que passou despercebido para quem escreveu o código, mas você ainda precisa verificar o recurso de verdade. Para nossa exportação, aplique um filtro, baixe o arquivo e confira as linhas e as colunas. Uma compilação bem-sucedida não diz se o arquivo contém os dados corretos. Você não precisa usar tudo isso para cada pequena alteração. Um bug simples talvez exija apenas reproduzi-lo, fazer uma correção pontual e verificar no app. Para trabalhos mais longos,

05:52 dê ao Claude uma condição de conclusão que ele possa verificar continuamente. Se você estiver migrando uma API, isso poderia significar que todos os pontos que a utilizam passaram a usar a nova versão, que a API antiga foi removida e que os testes relevantes passaram. Peça que mantenha um registro de decisões e deixe um ponto de verificação caso o trabalho precise continuar em outra sessão. Assim, você terá algo específico para revisar quando voltar. Mas há uma troca em termos de custo. Os arquivos das skills são open source, mas agents adicionais e rodadas de revisão ainda consomem sua cota do Claude Code ou o orçamento da API. Se estiver controlando o uso, comece com uma implementação e uma revisão focada. Deixe as comparações maiores para

06:25 decisões em que outra tentativa possa ajudar. Na minha opinião, Pstack vale a pena se você vive lembrando o Claude de reproduzir os bugs e verificar o app antes de dizer que terminou. Ter essas expectativas registradas nas skills oferece algo que você pode reutilizar e ajustar. Dê a ele uma tarefa que você conheça bem e veja o que ele retorna. Eu avalio pelo patch e pelas verificações que executou. O repo está vinculado abaixo, caso queira adaptá-lo para o Claude Code ou para o agent de programação de sua preferência. No geral, é bem legal. Enfim, contem nos comentários o que acharam. >> [música] >> Se você gostou deste vídeo, considere

06:56 fazer uma doação pela opção Super Thanks ou tornar-se membro clicando no botão de participação. Além disso, dê um joinha neste vídeo [música] e inscreva-se no meu canal. Vejo vocês no próximo. Até lá, tchau. >> [música] [música]

Transcrição original

[00:00] [music] >> Hi, welcome to another video. So, [music] you ask Claude code to fix a bug. It edits a bunch of files, runs the tests, and says it’s fixed. You open the app, same bug, or you ask for an export button, and somehow you’ve got a new framework to maintain. P stack is a collection of skills that pushes Claude to investigate before editing, keep the fix small, and check that the thing you asked for actually works. It also gives you ways to compare designs, split up investigations, and get another agent to review the result.

[00:33] It comes from Potato, who works at Cursor and on the React core team. These are the skills she uses in her own engineering workflow, and they’re open source under the MIT license. They were built for Cursor, but you can adapt the instructions for Claude code or another coding agent with skills or custom rules. We’re focusing on Claude code here, so let’s get right into it. For setup, open Claude code in your project and give it the P stack repo linked below. Ask it to adapt the skills for your project, preserve your existing instructions, use the tools and models

[01:04] available, and check that everything works. Have it tell you if anything else is needed. Let Claude handle the compatibility changes. Once it’s checked the setup, your main entry point is {slash} potato-mode. Give it the task and a clear description of what a working result looks like. The playbooks guide it through the steps. Here’s an example. You’ve got a search box, and when you type quickly, the results sometimes jump back to an older search. I’d say {slash} potato-mode, reproduce the search bug in the running app, find the cause, make the smallest fix, and verify the same interaction

[01:35] afterward. Leave the changes ready for review. The bug fix playbook tells Claude to reproduce the failure before choosing a fix. In this example, it should watch the requests and check which response updates the page. Maybe an older request finishes late and overwrites the newer results. That’s something Claude needs to confirm. If the evidence points elsewhere, it needs to follow it. And I really like this detail. If Claude tries something and the evidence disproves its theory, the playbook tells it to remove the changes based on that theory. Otherwise, a debugging session can leave you with

[02:08] five workarounds and no idea which one helped. Once it finds the cause, capture a failing test if there’s a cheap way to do it, then make the fix. Finally, repeat the original interaction. Make that older request finish late and check that the newest search still wins. That’s what I’d want to see before accepting the patch. Show me the failure, explain the cause, and show me the same thing working afterward. Now, sometimes you need Claude to understand the code before you even know what to change. That’s where how, why, and teach come in. With {slash} how, you could ask, “How do search filters get from this form into the database query?” Claude traces the

[02:42] code and explains the flow. Useful when you’ve opened a project and have no idea where anything lives. {slash} why digs into the reasons behind the code using the history and evidence it can access. Say there’s a retry limit that looks arbitrary. Ask why it was added before telling Claude to remove it. There may be a reason that isn’t obvious from the function itself. Then use {slash} teach when you want to understand the answer yourself. After the search fix, ask Claude to explain how the requests got out of order and why this change prevents it. I like that for learning while building. You can ask follow-up questions until you understand the code you’re going to maintain. Now,

[03:14] let’s add that export button. Use {slash} architect and say, “Design an export feature that downloads the currently filtered results.” Show how the page, API, and export code fit together before implementing it. This gets Claude to work through the decisions early. Which filters apply? How much data could this return? Can we reuse the existing query? You want those answers before it has written half the feature. Piece stacks principles also push it to keep the solution small. For a simple dashboard, reusing what you’ve already built might be enough. I don’t want a

[03:46] new job system unless the export actually needs one. If there’s a design choice worth comparing, use Arena. Arena sends the same task to multiple agents and has them produce independent candidates. The lead compares them, gets another judgment, picks a base, and brings over useful ideas from the other attempts. Then it checks the combined result. For the export, you could compare returning the file directly with preparing it in a background job. Give both attempts the same requirements and see how they handle the expected data size, complexity, and user

[04:17] experience. This is useful when Claude’s first idea sounds plausible, but you’d like to see another approach before committing to it. Swarm helps when the work can be split up. One agent could trace the back-end filters, another could inspect the filter state on the page, and a third could check the existing tests. Each gets a specific job, and the lead brings their findings together. You can do the same across packages in a larger repo. You get one report with the issues found and any parts the agents couldn’t verify. That last bit matters. An

[04:47] unfinished check shouldn’t quietly turn into a pass. Once Claude has built the export, use /interrogate to review it. Ask the reviewers to check whether it respects the selected filters and handles failures properly. Interrogate gets independent reviews, then assesses the findings. Which issues could break the feature? Which suggestions are worth considering? Which complaints are wrong or missing context? I like that it asks the lead agent to make those calls. AI reviews can generate a lot of extra work if you treat every suggestion as a

[05:20] requirement. This skill gives you a review verdict without automatically applying every proposed change. Use the models available in your Claude code setup for those roles. Another reviewer can catch something the author missed, but you still need to check the actual feature. For our export, apply a filter, download the file, and inspect the rows and columns. A successful build doesn’t tell you whether the file contains the right data. You don’t need all of them for every little edit. A small bug might only need reproduction, a focused fix, and a check in the app. For longer work,

[05:52] give Claude a finished condition it can keep checking. If you’re migrating an API, that could mean every caller uses the new version, the old API is removed, and the relevant tests pass. Ask it to keep a decision log and leave a checkpoint if the work needs another session. That gives you something specific to review when you come back. There is a cost trade-off, though. The skill files are open source, but extra agents and review rounds still use your Claude code allowance or API budget. If you’re watching your usage, start with one implementation and one focused review. Save the bigger comparisons for

[06:25] decisions where another attempt could help. My take is that Pstack is worth trying if you keep reminding Claude to reproduce bugs and check the app before saying it’s done. Having those expectations written into the skills gives you something you can reuse and adjust. Give it a task you understand well, and look at what comes back. I judge it by the patch and the checks it ran. The repository is linked below if you want to adapt it for Claude code or the coding agent you prefer. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. >> [music] >> If you like this video, consider

[06:56] donating through the Super Thanks option or becoming a member by clicking the join button. Also, give this video [music] a thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye. >> [music] [music]