The Workflow That Actually Makes Vibe Coding Work

The Chaos Isn’t the Code

I kept getting stuck. Not with the code itself — with the mess that happens when you skip the thinking and jump straight to building. You end up reworking things you shouldn’t have built in the first place.

So I built a system to fix that. I posted a condensed version on Reddit and it hit nearly 7,000 views and 32 shares. This is the full version.

Before any of this starts, I validate the idea. Is it worth building? AI can’t answer that. That takes your judgment. Once I decide a project is worth the time — whether it’s for work, family, or a personal tool — here’s the exact workflow I use.

Step 1: Brain Dump → Gemini

Hit the transcribe button on your voice notes app. Say everything you’re thinking. Paste it into Gemini and ask for a detailed one-to-two page summary.

Take that summary into Notion. Edit it. Get your thoughts lined up. Paste it back into Gemini and have a conversation. Export and refine.

Keep it to one or two pages. Anything longer is too much for your brain to work with when it’s still in creative mode.

Step 2: Foundational Spec → Claude

Take that refined doc and paste it into Claude. Tell it: “We’re building a foundational spec for Claude Code.” It knows what to do. Let it beef it up.

This document becomes the anchor for everything that follows.

Step 3: GitHub Repo + Two Critical Files

Create a repo. Add the foundational spec as overview.md. Then add a second file: Project Protocol.md.

The Project Protocol is the piece most people are missing.

" Most vibe coding problems aren't code problems. They're planning problems. Fix the plan, and the code mostly takes care of itself. "

It’s not just a prompt. It’s a working agreement between you and Claude Code that defines exactly how every project runs. The core of it is this:

We do not build what we have not defined. We do not define what we have not questioned. We do not move to the next phase until the current one is validated.

Here’s what the protocol actually enforces:

Phase Zero — Discovery & Ambiguity Clearing. Before a single line of code is written, Claude asks every question it needs to accurately scope the project — grouped by category, not fired one at a time. Purpose, users, tech stack, integrations, constraints, dependencies. Phase Zero isn’t done until Claude can say: “I have no remaining questions that would change how I scope this project.” Then it produces a one-page summary. You approve it. Nothing moves until you do.

Milestone Scaffolding. Once Phase Zero is locked, Claude maps the entire project into logical phases before any issues get created. Each milestone gets a name, a one-sentence goal, a list of deliverables tagged as [ME], [CLAUDE], or [TOGETHER], and a specific, testable validation method. “It works” doesn’t count. “The webhook fires and n8n receives the payload confirmed in the execution log” counts.

Issue Generation — Phase by Phase. You tell Claude which milestone to issue out. It presents all issues for review first. You approve. Only then does it write them to GitHub.

Session Continuity. Every session opens with a status check: what milestone you’re in, what issues are open, in progress, and closed, and what’s next. If you start a session without context, Claude asks which project and milestone before it does anything else.

The last line in my protocol doc: It’s all in the reflexes.

You can grab the full Project Protocol here: keithgroben.notion.site/Project-Protocol

Step 4: Claude Code CLI — Not the App

In the CLI, say: “Read my overview, read my Project Protocol md, create Phase 0 and all phases.”

This takes time. Once it’s done, you chat through the Phase Zero questions — all the ambiguous stuff that would have caused rework later. Then Claude writes out the phases. Depending on the project, that can be a few minutes or a few hours.

Use the CLI. The app doesn’t have full permissions for GitHub issue creation, and that’s a core part of how this works.

Step 5: Get to Work

From here, every session is simple. Open Claude Code in your CLI. Ask: “What’s next?” It finds the open issues and you go.

After each issue completes, ask: “How do I validate this works?” Then check it yourself instead of burning credits on Claude checking its own work. If it’s just you running the project, keep your budget tight.

The Foundation Comes First

There’s a pattern in Proverbs that keeps showing up in my work life. Plan before you build. Think before you act. Wisdom is in the preparation, not the motion.

I used to think working fast was the same as working well. It isn’t. Jumping straight into building — with AI or without — is just another way of trusting your gut over your plan. And your gut is wrong more often than you think.

The Project Protocol isn’t about slowing down. It’s about making sure every move you make is the right move. When Phase Zero is done right, the rest of the project accelerates. You’re not reworking decisions you should’ve made at the beginning.

“The plans of the diligent lead to profit as surely as haste leads to poverty.” — Proverbs 21:5

What would it look like to bring that same discipline to every project you start — not just the code ones? The principle works in your business, your crew, your estimates. Define it before you build it. Validate it before you move on.

Further Learning

• Shape Up: Stop Running in Circles and Ship Work That Matters — Basecamp →
• How I Use Claude Code to Ship Faster — YouTube →