Poteto Mode + Claude Code is SOMETHING ELSE!

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Poteto Mode + Claude Code is SOMETHING ELSE! · Channel: AICodeKing · 06:56 · Watch on YouTube

Topics: AI agents, Claude Code, Software engineering with AI, Open source and software ecosystems

Summary

The video presents Pstack, an open-source collection of skills that encourages Claude Code to investigate before editing, keep changes focused, and verify that requested work actually functions. It demonstrates setting up the skills and using them to reproduce and fix a bug, understand existing code, and plan an export feature. The video also explains how Arena, Swarm, and Interrogate can support comparisons, parallel investigation, and review. It recommends choosing skills to fit the task, checking the result yourself, and considering the extra usage cost of agents and review rounds.

Key points

Pstack skills can be adapted for Claude Code while preserving a project’s existing instructions.
The potato-mode playbook asks Claude to reproduce a bug, confirm its cause, make a small fix, and repeat the original interaction to verify it.
If evidence disproves a debugging theory, the playbook says to remove changes based on that theory.
The how, why, and teach commands help trace code, investigate the reasons behind it, and explain concepts to the user.
Architect helps work through design decisions before implementation and encourages small solutions.
Arena compares independent approaches to the same task, while Swarm splits investigations among agents.
Interrogate gathers independent reviews and assesses their findings without automatically applying every suggestion.
A successful build is not enough: verify the feature itself, such as checking the contents of an exported file.
For longer tasks, define completion conditions and keep a decision log or checkpoint.
Extra agents and review rounds use Claude Code allowance or API budget, so reserve larger comparisons for consequential decisions.

Chapters

Start	Chapter	Summary
00:00	What Pstack is and how to set it up	The video introduces Pstack’s workflow principles and explains how to adapt its open-source skills for Claude Code.
01:35	Reproduce and verify a bug fix	A search-results bug example shows how to confirm the cause, discard disproven theories, and test the same interaction after fixing it.
03:14	Plan and compare an export feature	Architect helps plan a filtered-results export before coding, and Arena compares independent implementation approaches.
04:47	Parallel investigation and independent review	Swarm divides research among agents, while Interrogate assesses reviewers’ findings; the user still needs to test the exported data.
06:25	Practical recommendations and trade-offs	The video recommends trying Pstack on a task you understand, judging the patch and checks, and accounting for the cost of additional agents.

Quotes

investigate before editing, keep the fix small, and check that the thing you asked for actually works. — 00:00

Show me the failure, explain the cause, and show me the same thing working afterward. — 02:08

An unfinished check shouldn’t quietly turn into a pass. — 04:47

A successful build doesn’t tell you whether the file contains the right data. — 05:20

Concepts and entities

pstack, Potato, Claude Code, Potato Mode, Arena, Swarm, Interrogate, Cursor

Full transcript (original language)

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]