Big Idea

The argument in one line.

Vibe coding ships a demo fast but collapses in production; the fix is a five-step assembly line where each Claude Code skill plays a named dev-team role and all coordinate through a shared Notion task board.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You've shipped a vibe-coded project that worked in demo but broke under real users or real data.
You use Claude Code regularly but find yourself re-prompting the same thing every session with no persistent plan.
You want AI to manage its own task queue — picking up the next item, testing it, and handing it off — without you micromanaging every step.
You're comfortable with VS Code, Firebase basics, and running npm commands; this isn't a beginner's intro to coding.

SKIP IF…

You've never written or run code before — this assumes CLI, VS Code, and Firebase familiarity.
You use a non-Firebase backend; the implement-task skill shown is tightly coupled to Firestore and Firebase Auth.
You're looking for no-code vibe coding — every skill here runs inside Claude Code's terminal interface.

TL;DR

The full version, fast.

After a year of building apps without writing code by hand, the presenter identified the two failure modes: AI that starts coding before anyone knows what's being built, and AI that adds new features without checking if they fit. His solution is five named Claude Code slash commands that act as a dev team — /plan-product turns a plain-English brief into a spec and Notion task board, /implement-task builds one task at a time using Context7 MCP for version-correct library code and Playwright for self-healing browser tests, /review-task runs code and security audits with fresh eyes, /qa-task writes automated tests that fail closed against real databases, and /plan-feature checks feasibility before adding to a live app. All five read from and write to the same Notion database, so status flows automatically from New to Done.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 00:43

01 · Why vibe-coded apps break

The trust problem: apps built with AI broke often because the AI started coding before anyone knew what was being built. The fix was forced planning.

00:43 – 04:13

02 · /plan-product

One sentence to a full spec: slash command asks clarifying questions, picks an architecture (pragmatic balance), creates a Notion page with documentation + a task board with six implementation-ready tasks.

04:13 – 09:57

03 · /implement-task

Builds one task at a time using Context7 MCP for version-correct library code. Launches Playwright to test in a real browser, self-heals a live bug on camera, marks tasks ready for review.

09:57 – 11:09

04 · /review-task

Runs code review and security review as parallel sub-agents with fresh context. Catches non-blocking findings (emulator flag misconfiguration) and updates Notion with notes per task.

11:09 – 12:18

05 · /qa-task

Installs test libraries, sets up config, writes 42 automated tests for auth in one run. Tests fail closed — a missing mock turns red instead of hitting production or a paid API.

12:18 – 14:17

06 · /plan-feature

Adds QR code generation to the live app — but first checks feasibility against existing architecture via sub-agents. Creates a new Notion task before writing a line of code. Implement-task then picks it up and Playwright tests the download button.

14:17 – 15:05

07 · Get the skills free

All five skills available in the free Skool community. Shows the GitHub repo structure and how to drop the files into a .claude folder.

Atomic Insights

Lines worth screenshotting.

AI doesn't break apps — starting to code before anyone knows what's being built does.
A shared Notion task database is a better coordination layer than conversation history; skills read it, update it, and hand off without human prompting.
Context7 MCP prevents a specific failure mode: AI coding against library APIs it half-remembers from training data.
Self-healing Playwright tests inside the implement step catch bugs before code ever reaches a human reviewer.
A security review pass is not a code review pass — running both as separate sub-agents catches different failure modes.
Tests that fail closed mean a missing mock turns red instead of silently hitting your production database or paid API.
The riskiest moment in a vibe-coded project is adding the second feature — that's where most apps collapse.
/plan-feature runs feasibility checks before writing a line of code, so new features don't break existing ones.
Task status (New → In Progress → Ready for Review → Done) is the only coordination primitive all five skills need.
A developer who stopped writing code by hand still has to set up Firebase, paste credentials, and make one architecture call — the human role shifts to decisions, not implementation.
Parallel sub-agents in the review step mean correctness and security checks run simultaneously, not sequentially.
42 automated tests for authentication is the output of a single /qa-task command — no test-writing by hand.

Takeaway

Five named roles, one shared task board, zero handoff meetings.

WHAT TO LEARN

The reason vibe-coded apps break isn't the AI — it's that there's no spec, no review gate, and no test that fails before the bug reaches a user.

Start every project with a forced planning step that produces a written spec and a task list before any code runs — the AI cannot build reliably toward a target it doesn't have.
A shared, persistent task database (Notion, Linear, any board) is a better coordination layer than conversation history; it survives session resets and lets multiple skills pick up where the last left off.
Use version-specific library documentation (via a tool like Context7) before generating implementation code, or expect the AI to write against APIs it half-remembers from training data.
Self-testing is not optional — running the app in a real browser after each task, before marking it complete, catches a different class of bugs than static code review.
Code review and security review are not the same pass; running both as separate agents with fresh context catches bugs that slip through when a single reviewer is primed by the code it just wrote.
Write tests that fail closed: a test that silently passes when a mock is missing is worse than no test, because it creates false confidence while letting real data get hit.
The second feature is riskier than the first — always run a feasibility check against existing architecture before adding to a live codebase, or new code will silently break old behavior.

Glossary

Terms worth knowing.

Context7 MCP: A Model Context Protocol plugin that fetches current documentation for specific libraries before the AI writes code, preventing the AI from using outdated or hallucinated API signatures.
Playwright: A browser automation framework used here to let Claude Code open a real browser, interact with the app it just built, and verify that features work — then self-heal any bugs it finds before marking a task done.
Notion MCP: A plugin that gives Claude Code read and write access to a Notion workspace, used here to maintain a live task database that all five skills coordinate through.
Fail closed: A test design principle where a missing or misconfigured dependency causes the test to fail rather than silently pass, preventing real databases or paid APIs from being hit during automated test runs.
Vibe coding: The practice of describing software in natural language and letting an AI write all the code, without the human author writing implementation manually — fast for demos, fragile without a review and testing layer.
product.json: A configuration file created by /plan-product that stores the Notion page ID and project metadata, so subsequent skills can find the right workspace without searching or spending tokens on discovery.

Resources

Things they pointed at.

14:17linkAutomate & Earn with AI — Skool community ↗

04:19toolContext7 MCP

02:37toolNotion MCP

07:45productFirebase / Firestore ↗

07:40toolPlaywright

Quotables

Lines you could clip.

00:45

“The AI would start coding or it would plan but just a little bit before either of us actually knew what we were building. So step one was forcing a plan.”

Names the core failure mode of vibe coding in one sentence — widely relatable→ TikTok hook↗ Tweet quote

12:18

“This is where I've seen most Vibe Coded apps break. When you try to add a new feature to an already existing product, you need to check if it fits and how it fits.”

Counterintuitive insight — the second feature is riskier than the first→ IG reel cold open↗ Tweet quote

14:22

“All these skills are basically a full dev team.”

Clean mic-drop summary, no context needed→ newsletter pull-quote↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

analogystory

00:00I've been a developer for ten years and I haven't written a single line of code in almost a year now. So let me show you the setup that makes this possible and how I make sure that the apps that I build don't break. It's basically a set of Cloud Code skills wired into their latest official plugins.

00:15I'll show you all this one by one while building a real app. And stick around because at the end I'll show you how to download and use this yourself. For a developer like me this is a weird thing to admit.

00:25Writing code by hand was the thing I was good at for a decade. And now AI took that from me. So I had to adapt but letting an AI do it felt reckless.

00:34So this video is about the systems I had to build before I could trust AI. Because the first apps that I've built with it they broke a lot and I spent a lot of time on debugging. The first thing I had to fix was planning a product.

00:46The AI would start coding or it would plan but just a little bit before either of us actually knew what we were building. So step one was forcing a plan. Now let me show you what this one does while trying it on a real example.

00:59Now there are multiple ways we could go about this, but I'm gonna use Versus Code. These commands can also be used in the terminal or in the Cloud Code desktop app. The first thing I'm gonna do is create a new folder, and I'm gonna call it digital menus, cause this is gonna be an app that lets restaurants create their own digital menus, basically.

01:17Now in order to use the skill, you have to type in slash plan product. So I just described the app.

01:23You can generate digital menus with categories, items with name, price, description, and the app generates a public menu page customers can view on their phone. Okay. Then I told you to keep the first version lean with owner, auth, a menu builder, and one public menu page.

01:38I mean, I said no photo uploads, but maybe we'll implement them, so let's leave them here. But no team accounts and no payments yet. And we're gonna use Firebase for the database and for the users.

01:49Okay. Now let's end the prompt and see what it does. Now we are entering a planning session.

01:53First is checking the project state. See, we have a configuration file which is not present here and if it's not, then it will create it. And now it's gonna ask me some questions.

02:02So how should a customer reach a restaurant's public menu? Through a custom slug? Can one owner account have multiple restaurants or strictly one?

02:09For now, let's have one per owner. What should the public menu support be untext? Let's go with item images, restaurant branding, reorder drag and drop.

02:18How polished should the menu builder editing fill for v one? Let's go with form plus explicit save. Now it's storing all this information in an architecture page inside my Notion.

02:27So the skill knows that the Notion MCP is available and it knows to create a structure just like a regular project would. So we'll have a documentation database basically and then a board with all our tasks. Now it's asking us for some architecture decisions.

02:40You can just choose other and tell it to choose. I'm gonna go with Next. Js because it's easy to deploy it inside Firebase.

02:46How should the public menu page be rendered? I'm gonna go with this one, rendered. Then for hosting, we're gonna be using Firebase.

02:53Then it's asking me if I want it to enforce any hard constraints, I'm gonna go with mobile first public page. Now it gave me a summary of what we decided.

03:02First, a table of the feature list and then the nonfunctional constraints. And it's asking me if it should proceed with the architecture design with the scope. Once I confirm, it will launch some parallel agents to define the architecture and store everything inside Notion.

03:15I'm just gonna tell it to go ahead. Now it gave me three different options for the architectures. Each of the triples of agents run this.

03:22I'm going go with pragmatic balance. Now it's asking me if I have a Notion page for this product, create it fresh because it doesn't exist. Now it's searching where to create it inside my Notion.

03:32I'm going to create it inside products and it's done so. It created some Notion pages as I've told you. This right here, I'll show you in Notion in a second.

03:40Then it created six implementation ready tasks and this file right here for configuration for my other skills. So it has the page ID, so it doesn't search every time, so we don't spend a lot of tokens.

03:51Now this is what it did in Notion, it created this page here, digital menus. If I expand it, it will have a documentation and an architecture with the choices that we've made.

04:01See, it even structured the database. Now it also created this tasks data database where it added the tasks I just showed you with an order to them and with the status. We use both order and the status for the upcoming skills.

04:13Now it told me to run implement tasks, and this is the second thing I've built, a skill that implements the tasks. I'm also using some plugins for it like Context seven, which checks for the latest versions for specific libraries. Then I'm also using code exploring sub agents to go faster and to check where this new feature fits.

04:32Let me show you how awesome this one is. So I'll just type in implement task. That's it.

04:37Now it goes to my Notion. It will move the first one to in progress right here. Let's see what it's doing.

04:43First, it reads the product adjacent so it knows where to go inside my Notion. Okay. It's called the Notion update page.

04:49It moved this one to in progress. Okay. In the meanwhile, we need to create a Firebase project manually.

04:53So let's go to firebase.com. I'm gonna create a new project, digital menus, continue, create project.

05:01Okay. So it's running. We'll have to wait a few seconds.

05:04And now let's enable users and the database. So for database, we're gonna be using Firestore. Create database.

05:11Let me make this a bit bigger. Okay. Standard edition.

05:15I'm gonna go with the default options. We're gonna start in production mode and create. We have our database set up.

05:22Now let's enable users. So go right here to security authentication. Let me close this.

05:27Then click on get started. Let's go with email and password, enable, save, and that's it.

05:33Okay. Let's go back here. As you can see, this guy is working.

05:36It created the project right here on the left side. It even created the dot EMV file with some placeholders here. So let's go and copy this from Firebase and give them to the AI.

05:46To do so, go right here in settings, general, and let's add a web app. I'm gonna call it digital menu web, register app, and then it gave me all the info we need. So let me just copy this and go back to Claude.

05:57Now it's doing a temporary smoke test. It's connecting to the Firebase client SDK to the local emulators as the Firebase config library says. And now it's running a check to make sure that the code is clean.

06:07Now it's handing off the task and it's moving the status to ready for review. It's also adding a comment with what it did. And now it's asking me what's next.

06:16See, we have multiple options here. We could implement more tasks, we could run review, or we could actually test.

06:23But this is only after review has passed. Now let me also run the app manually. I'm just gonna open a terminal here and then and run npm run dev.

06:32Okay. It's running. Let me copy the link, go to Chrome, and then paste it.

06:36Awesome. It looks like it's working. Let me zoom in a bit.

06:39Now I'll just copy this again because I lost them. Go back to Claude. So before we build anything, use this for EMV local.

06:46And then I gave it the Firebase config. It told me that it added this data here in EMV local, but it still kept the emulator as true. We're gonna use this Firebase project for development, so no emulator.

06:57So I can just show you what it's doing. We could also test in this env. And it changed it to false.

07:03Now it should also update the documentation, so it knows that we could use this project for testing. Now it's logging into my Firebase, which is crazy.

07:10I don't know if I want to let it. Now we're gonna implement a few more tasks before I show you the review skill, but I'll go fast through them so we can actually see something in the interface. Okay.

07:19So I'm just going to run implement task again. It's going to pick up the second one. See, the first one is moved to ready for review.

07:25Now it's going to pick up this one, owner authentication, sign up, login and root guard. The production build passed.

07:31Now it opened this window right here. Let me make it fit. And it's using Playwright to test.

07:37But as you can see, it has a problem. Let me show you how it self heals. It even stopped my app here.

07:41As you can see, it found a real bug already and we didn't even start testing yet. Now it's reloading the dashboard. Let's go back, and it looks pretty good.

07:49Let me zoom in a bit. Now what is it doing? It's filling in the form.

07:52It's creating an account. Awesome. And now it's signed into the dashboard with the new account it created.

08:00It's returning to login. Okay. And it did.

08:03And now it's trying to log in with the same account that it created and it's also working. Okay. I think that's all it developed.

08:10Now it's deleting the test user and it moved the task to ready for review as well. Now, I would stop here and start reviewing the tasks before I implement anything else, but I'm just going to go ahead and implement all of them. So this is another way you can call the implement task skill.

08:26Run the implement task skill for the next four tasks one by one. So the agent will decide when to run the skill. So I'm just gonna run this and skip ahead to when it's done.

08:34If there's something interesting along the way, I'll share that. Now I also had to enable storage right here. Just press on get started.

08:41And now while this one was running, I also created a fake restaurant. I created it with this logo and then a few images for the food. Okay.

08:49These are almost done. Now it's working on the last one. And as you can see, something I forgot to mention, this skill also updates the documentation of the project.

08:56So it knows of the new feature we just added. Okay. Now let's go through the app ourselves.

09:01I'm gonna start it here. Open a browser and just refresh here. Let's create an account.

09:07Awesome. Now let's create a restaurant. We can also upload logos now.

09:11Awesome. Let's create restaurant. And now we can configure the menu.

09:14I'm just gonna add a category for mains and then another one for starters. And let's start adding some items. We can also upload images for items.

09:23I'll skip ahead and add a few. I've added six mains and two starters. Now if I click on the link then it will open right here.

09:29So we have the logo up top then the restaurant name. We could also implement the feature to add a cover photo so it looks a bit better. Now we have the mains without pricing, also the starters.

09:38Now let's try reordering. So I want to move mains after starters. And then I want to have this starter as the first one.

09:46Let's check the link again. And it worked. Now let's see if it's a public link.

09:50I'm just gonna copy it, go back, log out, and then try to access it like this. And it looks like it's working awesome. Now I finished all the tasks and as you can see they are ready for review.

10:00So let me show you my third skill, the one that in my opinion is the most important, review task. I'm only gonna run it for the first two tasks because there isn't much to review for the first one because it was just a project setup.

10:12Review task. If I were to run it like this, it would take all the tasks ready for review. But I'm just gonna tell it, write for the first two tasks.

10:20And it does two things. First, it checks for the actual code. It checks if it's right and if it does the thing it was meant to do.

10:27And the second one, it checks for security issues. It uses two official plugins from Cloud Code, Code Review and security review. Now it's running some agents in parallel as you can see, so it doesn't spend too much time on it itself.

10:40Okay. Seems like it's done. Both pass as the implement task skill is so good, and it also does some manual testing.

10:46Now it's updating Notion pages with some notes for each one of these two tasks. It also ran ahead and found a problem for test three, but I didn't tell it to run it for test three.

10:57It did reveal some non blocking findings. We forgot the emulator in the environment example. So if someone else gets the project, then it won't know that we're using a real Firebase project, but we don't need to fix this one right now.

11:09So the fourth one is QA task. It basically acts as an automation QA engineer. It will write automated tests.

11:16But before it does that, it logs the project up. So if the project is linked to a real environment, we don't want it to change that data. It will take the tasks in ReadyForQA, and it will only test those.

11:28So let's go ahead and run it, slash QA task. This one is also using an official Cloud plugin for testing. It found the two tasks it needs to run for.

11:38It's installing the test libraries as this is the first time it runs. For the next ones, it doesn't need to do so. It's setting up the test config.

11:46Okay. So we've added 42 tests basically just for auth because that was the only real functionality of the first two tasks. Now it's updating the Notion pages.

11:54And it's telling me that the next logical step is to run review task on the rest of them. But I'm not gonna do that now because you get the point. So if we open one of them, we can see the comments that the AI has added.

12:05The first one was for implementation. The second one was for review. And then the third one for QA.

12:12Now if we go to our documentation, you'll see that it's updated with everything we've built. Now let me show you the fifth one.

12:20It's similar to the first one where we plan a project, but this time we want to plan features inside projects. This is where I've seen most Vibe Coded apps break. When you try to add a new feature to an already existing product, you need to check if it fits and how it fits.

12:34So let me show you how it works. You have to type in plan feature and then give you the feature you want to build.

12:40For us, it will be QR code generation for public manual links. Okay. Let's send it.

12:45Now it's reading the product configuration again. It's gonna go to the documentation and see if it fits and then it's gonna run some sub agents in parallel to check if this feature actually fits. Project is set up.

12:55QR code generation is a small self contained feature. Now it's gonna ask us some questions because this is planning. We want to display it in the dashboard.

13:03We want it as a PNG. We're gonna generate a plain QR and we're gonna generate it in the browser. Now this skill is not gonna implement the feature.

13:11This will only go back to my Notion and create the tasks just like a technical business analyst would. So all these skills are basically a full dev team. Okay.

13:19It checked everything. It's feasible. We can implement it.

13:22We don't need to do any prerequisite work. And now it's creating a new Notion page for the next task. Awesome.

13:28Let's go back to Notion and check it. It's right here. Let's go ahead and run implement task on it.

13:33I just need to type in implement task. It will know to get that one because it's the only one in the status that this skill picks, which is new. Now this time it's also running the tests.

13:42The first time we run it, we didn't have any. Now it's also using Playwright to test it itself. It's creating a new account.

13:50Now it's setting up a restaurant. And as you can see, we have the QR right here. It points to this link, so I can't test it on my phone because it's on my local.

13:58Now if we were to deploy this app, then it would point to our domain. It actually pressed the download button. It tested everything even the PNG size.

14:06Now it's updating the documentation and also the status of the task. Awesome. It's done.

14:11As you can see, it's moved to ready for review. Now we can run review and then QA on it. But you already get the point.

14:17We have the plan product skill, which acts both as a business analyst and as a software architect. Then we have implement feature, which acts as a dev. Then we have review task, which acts as a senior developer.

14:29Then QA task, which acts as a QA engineer, together with a developer that writes unit tests. And then we have plan feature which basically acts as a technical business analyst. Now, like I promised at the start, all of this can be yours.

14:42Every skill you just watched me use is sitting in my free school community. Let me show you how to download it, so check the link in the description for this. Then you can head to Classroom, five AI agents that plan, build, review and QA.

14:53Right here. These are documented as well here. And then go on this link right here and you have the agents ready to be downloaded.

15:01I appreciate you making it all the way until the end and see you in the next one.

The Hook

The bait, then the rug-pull.

Ten years of writing code by hand, then almost none for a year — not because the work stopped, but because the pipeline got good enough to trust. This breakdown walks through the exact five-skill Claude Code setup that made that shift possible, shown live on a real app, with the bugs that appear on screen and get fixed in real time.

Frameworks