The Seven-Command Build Loop
Six slash-commands turn vibe-coding into disciplined software delivery for non-coders
- Difficulty
- Moderate
- Time to result
- ~days to results
- Steps
- 7
- Confidence
- 95%
A fixed, repeatable pipeline of reusable slash-command prompts saved in the codebase that walks a non-technical builder from raw idea to shipped feature: Create Issue, Exploration, Create Plan, Execute, Review, Peer Review, Update Docs. Use it whenever you build a serious feature (not a throwaway) and want AI to plan before it writes code.
Origin
Zevy built the backbone inside a ChatGPT 'CTO' project's system prompt ('step one we do this, step two we do this'), then extracted each recurring step into a Claude Code slash command whenever he noticed himself repeating it.
Core principles
- 01Planning must precede code; eager coding agents cause the gnarliest bugs
- 02Reusable prompts (slash commands) beat re-typing the same instructions
- 03Each phase has a distinct goal; don't collapse explore, plan, and execute
- 04The plan lives as a committed markdown file so future agents inherit context
How to run it
- 1
Create Issue
Mid-build, when a bug or idea surfaces, fire /create issue so Claude captures it fast into Linear (via MCP) with a template, so you can keep working without losing the thread.
Pro tip Dictate with voice (Whisperflow) as if briefing an engineer; the command is tuned to ask only brief clarifying questions.
Watch out The generated ticket is 'ready to be explored,' not ready to be built.
- 2
Exploration Phase
Pass the ticket (e.g. 'linear STU-88') so Claude reads the codebase, states its understanding of the current system, and returns clarifying questions about scope, data model, and UX before any solution is chosen.
Pro tip Spend real time here reviewing Claude's stated understanding; this is where you catch it misunderstanding the problem.
- 3
Create Plan
Run /create plan to produce a markdown plan file with a TLDR, the critical decisions made, and status-tracked tasks that Claude updates as it works.
Pro tip Split the plan into backend and frontend sections so you can route each half to the best model.
- 4
Execute Plan
Tag the plan file and run execute; the agent builds the feature from the plan, often in minutes for work that would take a human engineer days.
Pro tip Use Cursor's Composer model for fast, non-complex execution to stay in flow.
- 5
Manual QA + Review
Run the app locally, manually QA it, then run /review so Claude reviews its own code and flags critical/high/medium bugs.
Watch out Always manually QA first to catch anything obvious before trusting the automated review.
- 6
Peer Review
Have other models (Codex, Composer) independently review the same branch, then feed their findings back through the peer-review command.
- 7
Update Docs
Update documentation and tooling so the next agent working in this area writes better code and repeats fewer mistakes.
Pro tip Do this even on successes; treat it like a post-mortem.
In the wild
Live on the podcast, Zevy dictated a spec for drag-and-drop fill-in-the-blank quiz questions, ran /create issue to file Linear STU-88, then /exploration phase, /create plan, and execute — building a full feature in minutes.
→ A working feature built locally end-to-end during the recording, ready for QA and review.
Common mistakes
Letting the agent code before planning
Early tools were 'super eager to write code'; when implementing payments or database changes, jumping straight to code 'always results in terrible things' and gnarly bugs.
Is it for you?
Best for
Non-technical PMs or solo builders shipping real side-project features in Cursor/Claude Code
Not ideal for
Throwaway prototypes, or heavy database/migration work that still belongs with engineers
From the transcript
“these are all my slash commands. Basically what slash commands are they are reusable prompts that I save within the codebase that I can run…”
“After creating the plan we have execute plan. After execution we have review and then we have peer review which is really cool”
“planning is really important when you're implementing something uh technical”
From the episode
The non-technical PM’s guide to building with Cursor
Zevi Arnovitz (Meta)