I’m the only person working on the app I’m building. Product, design, architecture, frontend, backend, QA. Every decision is mine, and I change my mind constantly.
For almost a year I’ve built it with Matt Pocock’s agent skills, which also ship as a Claude Code plugin in Anthropic’s official marketplace. I like the flow. Recently I started experimenting with Poteto, Lauren Tan’s pstack, the skill set behind /poteto-mode. It’s built for Cursor, and it now also ships as an official Claude Code plugin in Cursor’s marketplace. Some parts of it are clearly valuable. As a whole it feels less intuitive to me, and getting it to run in the setup I actually use has been friction.
So I asked agents which parts of Poteto I should take. They said: keep the lifecycle, borrow the discipline before the orchestrator. That’s roughly where I ended up, except I now borrow the orchestrator too, one session at a time. Keep the flow you steer, and pull in whatever makes it better.
Matt: I can see every step
Matt’s flow is a sequence I drive. I grill an idea, prototype what talk can’t settle, turn the result into a spec, split the spec into tickets, implement, review. Several of these skills can only be started by me; the model can’t invoke them on its own. Each phase begins because I decided to begin it.
The grilling step (/grill-with-docs) shows the style well. The agent works through the idea in rounds. Each round asks every question whose prerequisites are already settled, and each question comes with the agent’s recommended answer. I accept, push back, or decide. Then the next round.
When a question can’t be settled in conversation, I build a prototype. The skill calls it “throwaway code that answers a question,” and it means it. One question, one verdict, then the prototype goes away and the decision stays.
Review keeps the same habit of making things explicit. /code-review checks the change on two separate axes: does it follow the repo’s standards, and does it do what the spec asked. Code can pass the first and fail the second.
That’s what I like after a year. I can see where I am, what comes next, and why. Nothing about it has made me want to replace it.
But Matt isn’t only about sequence, and it isn’t only manual. I use /implement-spec all the time. It reads the tickets as a task graph, runs implementer subagents in parallel, and finishes with one review over the integration branch. That’s orchestration too. I start it, though, and only after the spec and tickets are settled.
Poteto: worth more in pieces
Poteto has one entry point. You describe the outcome and how you’ll know it’s done, /poteto-mode matches the task to a playbook, and the playbook calls the other skills. In my Poteto session I noticed I always trigger the parent skill and let it run the rest. Lately I also add /poteto-mode to sessions that follow Matt’s flow, and the output gets better.
Poteto has process too. Its Feature playbook is a full sequence from understanding the code to opening a PR. So this isn’t “Matt has a workflow, Poteto has rules.” Both have both.
What stands out to me in Poteto are the principles. Each one is a small skill with a single rule, applied when its situation comes up. I said in that session that I find them really valuable for keeping the quality of generated code high. Two examples show why.
The first is a reporting rule in /poteto-mode itself. The agent has to name each principle that shaped a decision and the specific choice it changed. That turns a principle from a slogan into something I can check. “Applied Minimize Reader Load” tells me nothing. “Removed a pass-through wrapper” is a claim I can review.
The second is Prove It Works:
Verify every task output by checking the real thing directly. Do not infer from proxies, self-reports, or “it compiles.”
As the only QA on my app, I want that rule in every session, whatever workflow runs it.
Some of Poteto’s skills are worth using on their own, too, and my best example started in Matt’s flow. I let /implement-spec build four specs for my iOS app while I was away. Afterwards I ran Matt’s /retro over the session. One finding: every ticket spent part of its 10 to 30 minutes rediscovering how to drive the simulator. Which test account can sign in, how to seed one with a goal, how to tap inside a sheet. The notes lived in a cache folder outside the repo, so the next run would lose them.
The fix the retro suggested was a Poteto skill, /create-verification-skill. I had an agent run it directly, no /poteto-mode. It wrote a simulator skill into the repo and tested each lesson on the real simulator. One agent had decided taps inside sheets were impossible; they work. simctl can’t grant notification permission, so the skill taps Allow on the system alert. It also found the build for signed-in testing broken on main. Nobody had noticed, because my CI doesn’t build iOS.
Matt’s tool found the gap. Poteto’s tool filled it.
Two systems, different emphasis
So the difference is emphasis, not category. Matt makes the sequence I steer explicit. Poteto makes the execution rules explicit. Both describe process and behavior. Each puts a different half in the foreground, at least for me.
- Who starts each phase. Matt: I do, one command at a time. Poteto: I start once, and the playbook runs the rest.
- Where I check the work. Matt: between phases, before I start the next one. Poteto: mostly in the reply, which names the principle behind each choice.
- Where the rules live. Matt: inside the grill, spec, and review skills. Poteto: in small principle skills any playbook can pull in.
- What travels well. Matt: the flow as a whole. Poteto: its pieces,
/poteto-modeincluded, which I drop into Matt sessions.
Don’t bet on one flow
I don’t trust my own preference too far. A year of Matt means I know it. Poteto feeling less intuitive might say more about my habits than about Poteto.
If your problem is that you forget steps, skip the review, or lose track of what comes next, one entry point that picks the procedure for you might be exactly the fix.
That isn’t my problem. What I want more of is the agent showing its decisions and proving the result on the real app, and Poteto’s pieces give me that. In the sessions since, agents check each changed screen in the simulator and screenshot it.
What I’d avoid is two systems both deciding what happens next. Let one own the order of the work. Everything else can come from anywhere.
The bigger lesson isn’t about Matt or Poteto. Things move too fast to tie yourself to one flow. The model, the provider, the harness, the skill set: any of them can change next month. What lasts is knowing why a skill works, knowing the alternatives, and being able to change your setup without starting over.
Take the skills you find useful, wherever they come from. Just don’t let one flow become the only way you know how to work.