The three things that made Pi.dev useful for me: skills, memory, and browser automation
In my last post, I wrote about how I run Pi.dev safely.
If you already know why you are here and just want the copy/paste setup prompts, jump to three ways to set this up.
The short version: do not run a coding agent with terminal access on your daily personal machine unless you really understand the risk. Use a container, VM, VPS, or dedicated machine. Then add the tools you actually use: GitHub, Vercel, Supabase, ConsentKeys, browser automation, and whatever else belongs in your workflow.
That gets Pi installed.
It does not make Pi useful.
For me, Pi only started feeling genuinely useful after I added three things: skills, memory, and browser automation.
If you are a non-technical founder, creator, or wannabe builder trying to turn ideas into working software, this is the part I would pay attention to. The model matters. The workflow around the model matters more.
skills stop Pi from winging it
A Pi skill is basically a reusable instruction pack.
Instead of telling the agent the same thing over and over, you give it a skill that says:
- when to use this workflow
- what steps to follow
- what mistakes to avoid
- what “done” means
Agents are very good at sounding confident while quietly skipping steps.
Without skills, you might say:
Build me a landing page for this idea.
And the agent may immediately start editing files.
With the right skills, the agent should slow down first:
Who is this for? What action should the page drive? What already exists in the repo? What is the simplest version worth shipping?
That pause saves a lot of cleanup.
memory stops Pi from starting cold
Every builder who uses agents runs into this: you explain the context once, have a useful session, then the next session starts like none of it happened.
What did we already decide?
Why did we choose this stack?
What did we try last time?
Which idea was highest priority?
What was broken?
What should we not reopen?
If Pi cannot answer those questions, it is not really working with you yet. It is just helping in the current tab.
I use a local memory system called MemPalace. It gives my Pi sessions a searchable long-term memory across prior sessions, product notes, decisions, and project history.
The tool matters less than the habit: Pi should search memory before it re-decides things you already figured out.
browser automation makes Pi useful outside the codebase
The third piece is browser automation.
For me, that usually means agent-browser. It is not bundled with Pi; you install it separately, then Pi can use it. It lets Pi open sites, navigate pages, click buttons, fill forms, inspect output, take snapshots, and report what happened.
That changes Pi from “an agent that edits files” into “an agent that can test real workflows.”
A lot of builder work does not end at the codebase.
You need to know:
- did the landing page actually load?
- does the signup flow work?
- can someone click the CTA?
- does the checkout page open?
- does the deployed app behave differently from local?
- what does a non-technical user see?
A lot of agent work fails because the code looks right but the browser tells a different story.
Skills give Pi process. Memory gives Pi continuity. Browser automation gives it eyes and hands.
the seven skills I would start with
My setup has more skills than this, but I would not tell a new builder to learn all of them.
Start with these seven.
1. using-superpowers
This is the meta-skill.
It tells Pi to check whether a skill applies before acting. That sounds small, but it changes the whole feel of the agent.
Without it, Pi behaves like a smart freelancer improvising from your prompt.
With it, Pi behaves more like someone who has a process.
Use it when you want Pi to stop jumping straight into implementation.
2. workspace-orientation
This tells Pi to understand where it is before touching anything.
For my machine, that means reading the right workspace instructions, checking whether we are in a product repo, an idea folder, a blog, or a private area, and following the rules for that workspace.
For your setup, it might mean:
- read the README
- read AGENTS.md, CLAUDE.md, GEMINI.md, or INSTRUCTIONS.md if they exist
- inspect package files
- check recent git history
- understand what the project is before changing it
This is boring. Boring is good.
A lot of agent mistakes come from acting before orientation.
3. mempalace
This is my memory bridge.
The skill itself is simple. It tells Pi how and when to search my long-term memory.
For example:
- run a wake-up summary at the start of a session
- search memory before answering questions about past decisions
- search memory before resuming old projects
- search memory before recommending a tool we may have already evaluated
- re-index memory after major work
This is one of the most important parts of my setup.
People talk about “AI memory” like it is magic. In practice, the useful version is much more boring: a searchable record of what happened, plus a habit of checking it before making new decisions.
4. brainstorming
This skill stops “I have an idea” from becoming instant code.
It forces a short design conversation first:
- What are we making?
- Who is it for?
- What problem does it solve?
- What is the smallest useful version?
- What should we not build yet?
For non-technical builders, this is huge.
The danger is not that Pi cannot build. The danger is that Pi can build the wrong thing very quickly.
5. writing-plans
Once the idea is clear, this skill turns it into ordered work.
A good plan makes agent work less mysterious. Instead of “go build the app,” you get phases, files, checks, and stopping points.
That matters because you need to stay in control even if you are not writing the code yourself.
You should be able to ask:
- What are we doing first?
- What can wait?
- How will we know it worked?
- What should I review before the next step?
If Pi cannot explain the plan, it probably should not be changing the project yet.
6. systematic-debugging
When something breaks, agents love to guess.
They will patch one file, rerun something, patch another file, and sometimes make the problem worse.
Systematic debugging forces evidence first.
What changed?
What error do we actually see?
Can we reproduce it?
What is the smallest test that proves the bug exists?
What did we rule out?
This skill is especially useful for non-technical builders because it gives you a way to manage the agent without pretending you know the codebase.
You can say:
Use systematic debugging. Do not guess. Show me the evidence before changing code.
That one sentence can save hours.
7. verification-before-completion
This is the skill that stops fake “done.”
Agents are very comfortable saying:
Fixed.
But fixed according to what?
Did tests run?
Did the build pass?
Did the page load?
Did the deployment work?
Did the checkout actually complete?
Verification-before-completion makes Pi prove the work before claiming success.
For a non-technical builder, this is not optional. You need receipts.
what I leave out at first
I use other skills too, but I would not start a new builder with all of them.
Design polish skills, parallel-agent skills, code review skills, PWA skills, and research skills can all be useful later.
But if you are just starting, too many skills become another thing to manage.
Start with workflow and memory.
Then add more when you feel the pain.
three ways to set this up
There is not one perfect setup. Here are three reasonable paths.
option 1: easy mode for beginners
This is the most packaged path.
I do not personally run this exact combination every day, so I am not presenting it as my tested stack. But if you are starting fresh, these look like the closest Pi-native packages to the workflow I use.
Copy and paste this into Pi:
Set up a beginner-friendly Pi workflow for me.
Install:
pi install npm:pi-supergsd
pi install npm:pi-hermes-memory
Also install browser automation:
npm install -g agent-browser
agent-browser install
On Linux, use this instead if browser dependencies are missing:
agent-browser install --with-deps
Then restart Pi or run /reload.
After that, verify I have:
- workflow skills for brainstorming, planning, debugging, and verification
- persistent memory
- session search
- agent-browser installed and working
- a habit of searching memory before making recommendations
Show me what was installed and how to use it.
Why these two?
pi-supergsd packages a curated Pi version of Superpowers-style workflow skills. pi-hermes-memory appears to provide persistent memory, session search, secret scanning, and background learning.
Promising, but not my exact stack.
option 2: copy the pattern
If you already have notes, docs, transcripts, or a memory system, copy the pattern instead of copying my tools.
Paste this into Pi:
Help me recreate Kris Constable’s Pi workflow pattern.
I need three layers:
1. Workflow discipline:
- use skills before acting
- brainstorm before building
- write plans before implementation
- debug from evidence
- verify before claiming done
2. Long-term memory:
- searchable past sessions
- decisions
- project context
- things tried before
- user preferences
3. Browser automation:
- install agent-browser if it is missing
- verify Pi can use it to open a page, inspect content, and report what happened
Create or configure Pi skills that enforce those habits.
Especially create a memory skill that tells Pi:
- load a wake-up summary at session start
- search memory before answering history or project-decision questions
- search memory before recommending changes to existing projects
- update memory after major work
This is probably the most important version.
The package is not the point. The habit is.
option 3: get close to my setup
This is closest to how I work.
Paste this into Pi:
Help me set up Pi close to Kris Constable’s workflow.
Install Superpowers skills from:
https://github.com/obra/superpowers
Enable or create these Pi skills:
- using-superpowers
- brainstorming
- writing-plans
- systematic-debugging
- verification-before-completion
- mempalace
- workspace-orientation
For the memory layer, set up a local searchable memory system called MemPalace or equivalent with:
- a wake-up command for critical context
- search across prior Pi transcripts
- search across project or product notes
- separate namespaces or wings for different work areas
- a re-index or remine command after major sessions
Then create a `mempalace` Pi skill that documents the exact commands:
- wake-up at session start
- search before answering questions about past decisions
- search before resuming old projects
- re-index after major work
Finally, restart Pi or run /reload and show me the loaded skills.
This will not recreate my entire machine. It should get you close to the shape of it.
the habit matters more than the install
The real workflow is simple:
- Start with memory.
- Orient to the workspace.
- Brainstorm before building.
- Plan before editing.
- Use browser automation to test real flows when the work touches a website.
- Debug from evidence.
- Verify before believing “done.”
That is most of it.
If you are non-technical, this gives you a way to manage an AI builder without pretending to become a programmer overnight.
You are not trying to micromanage every line of code.
You are trying to make the agent follow a sane process.
That is the gap between vibe coding and actually building.
Leave a comment