§ 01 · The Hook
The bait, then the rug-pull.
Sean Kochel opens with a flat "one of the best AI coding frameworks on planet Earth" — no curiosity gap, no manufactured stakes. The substance carries it: a 3-category map of the entire vibe-coding tool ecosystem, then a full propose → apply → archive run on a real codebase, then the killer sync command that keeps your specs and reality in lockstep.
What the video promised.
stated at 00:08“If you're tired of screaming into the void as Claude Code doesn't do what you said to do for the millionth time, well, you clicked on the right video.”delivered at 20:45
Where the time goes.
00:00 – 00:29
01 · Cold open
Names the pain (Claude Code ignoring instructions) and the tool (OpenSpec). Flags that the video also covers a new expanded workflow.
00:29 – 02:26
02 · Ecosystem map
Three-category whiteboard: spec-first (OpenSpec, SpecKit), SDLC enforcement (Obra, agent skills, compound engineering), autonomous pipeline (bMAD, GSD). Best 90 seconds of the video.
02:26 – 03:50
03 · The real-world task
Migrating his Forkcast recipe app from vanilla shadcn to a polished editorial design prototyped in Claude Design. Sets up a git worktree using Obra's worktree skill for a clean baseline.
03:50 – 04:09
04 · Install & onboard
npx install, opsx init, choose environment. Highlights the `onboard` command for first-time users.
04:09 – 06:34
05 · Explore command
Optional pre-spec phase. Reads context, surfaces ambiguities (RecipeForge vs Forkcast naming, design system migration scope), asks clarifying questions before any planning.
06:34 – 08:39
06 · Propose → design → tasks
Generates proposal.md (what & why), design.md (how), tasks.md (implementation), plus per-capability specs/ directory.
08:39 – 09:43
07 · Validate with Chrome MCP
Adds a verification step where the agent uses Chrome browser MCP to visually compare implementation vs. target mockups — not built-in, but easy to layer on.
09:43 – 10:49
08 · Apply: 2 hours autonomous
Runs `opsx apply` with Claude's auto mode. ~2h 8m of actual processing, multi-screen design system migration completed with no intervention.
10:49 – 13:05
09 · Walk the results
Compares Discovery page, user profile, and recipe detail screens against target mockups. ~80–90% match on first pass, minor spacing and color-accent misses noted honestly.
13:05 – 15:35
10 · Archive command
Moves the change into the persistent specs/ source-of-truth. Future changes that break a spec will surface the conflict — the long-term value prop.
15:35 – 18:55
11 · New & continue (iterative slicing)
Demos the iterative workflow: slice a larger plan into focused, sequential changes. Continue moves through propose → design → tasks step-by-step instead of all at once.
18:55 – 19:27
12 · Fast-forward command
Autonomous run-through of remaining stages once you trust the plan.
19:27 – 20:45
13 · Sync command (the killer)
Reconciles the master specs/ folder with whatever just got built. Docs literally cannot drift from reality.
20:45 – 21:01
14 · Outro & playlist CTA
Soft CTA — playlist link to other tool breakdowns, no subscribe push.
Visual structure at a glance.
Named ideas worth stealing.
00:32model
The Three Categories of Vibe Coding Tools
- Spec-first / alignment (OpenSpec, GitHub SpecKit) — spec is the artifact, code is downstream, human orchestrates
- SDLC enforcement (Obra superpowers, agent skills, compound engineering) — tools that enforce discipline like TDD red-green-refactor
- Autonomous pipeline (bMAD, Get Shit Done) — define-and-walk-away, sub-agents per phase, minimal human intervention
Sean's mental model for the entire AI coding tool ecosystem. Clean, reusable, immediately understandable.
Steal forMod Boss positioning slide — map JoeFlow's orchestrator into one of these buckets (or a 4th) to claim a clear category.
06:34list
OpenSpec Workflow
- explore — optional context-gathering + ambiguity resolution
- propose — generates proposal.md / design.md / tasks.md + specs/ delta
- validate — extra verification pass (can chain Chrome MCP for visual checks)
- apply — runs the task list autonomously
- archive — promotes change to persistent specs/ source-of-truth
- new + continue — iterative slicing of large plans into sequential focused changes
- fast-forward — autonomous run-through of remaining stages
- sync — reconciles master specs with built reality
The full command surface, in the order you'd run them.
Steal forDirect template for a JoeFlow / Mod Boss batch-orchestrator command surface.
10:38model
Three-artifact spec pattern
- proposal.md → the what and the why
- design.md → the how (architecture decisions)
- tasks.md → the implementation checklist
Every change generates these three files plus per-capability spec deltas. Splits planning into intent / structure / execution.
Steal forRoutine templates in JoeFlow's morning batch — every Chef-launched session could output this same triad before any code runs.
Lines you could clip.
00:08
“If you're tired of screaming into the void as Claude Code doesn't do what you said to do for the millionth time, well, you clicked on the right video.”
01:08
“The mental model is mostly the human is orchestrating the thing, but the agent is assisting.”
06:09
“Any of these assumptions that are surfacing as we have this conversation — the language model's just gonna decide what to do at the time of building the thing, and then you might not be happy with the output.”
14:50
“It forces you to have like this living set of specifications for all of the major features of your app.”
19:58
“Anytime we make any change that touches something that already exists, we have this built-in step that's gonna go back and actually update the documentation so that things never get lost and never fall out of touch with the reality of what is there.”
How they spent the runtime.
Hook length29s
Info densityhigh
Filler8%
Things they pointed at.
00:40toolGitHub SpecKit
01:35toolObra (superpowers)
01:36toolCompound Engineering
02:04toolbMAD
02:06toolGet Shit Done (GSD)
02:45toolClaude Design
03:13toolObra git worktree skill
08:45toolChrome Browser MCP
09:57toolClaude Code auto mode
How they asked for the click.
20:51next-video
“If you like this video, I'm gonna link to a playlist of other breakdowns of tools like this one that I have done. But that is it for this video. I will see you in the next one.”
Soft, back-loaded. No subscribe push, no Skool plug in-video (those live only in the description). Earns trust over leverage.
Word for word.
HOOKopening / re-engagementCTAthe pitchmetaphor
00:00HOOKToday, we're looking at . It's a spectrum of tool called OpenSpec, and it solves some of the biggest problems that I have faced with other vibe coding frameworks and plug ins and tools. So if you've never used it before and you're tired of as ClaudeCode doesn't do what you said to do for the millionth time, well, you clicked on the right video. And if you have used it before, they've recently added a new expanded workflow, which we will take a look at later. So really quickly, where does this tool sit in the ecosystem of all of these different tools that we have like, Opera and GitHub SpecKit and BMAT and all of these other things? I think these tools kind of work out into like roughly three different categories. Now the first category, which this one falls into, I would consider like spec driven tools.
00:47So these are gonna be things like GitHub spec kit and obviously open spec, which we are looking at now, where the spec that you create is the primary artifact that drives everything. And so a lot of time is typically spent making sure you're aligned on exactly what you are going to build, and then everything typically follows through nicely from there.
01:08So the mental model is mostly . I personally think this is the best approach if you are a vibe coder or if you're new to AI coding in general, because it forces you to get really clear on what it is exactly that you are building and what it needs to do. The second category I would call software development life cycle enforcement.
01:30So these are things like agent skills, over superpowers, and compound engineering, where, yes, they have certain workflows that they move you through. But the real value in these tools from my perspective is that they enforce best practices and discipline
01:45onto the actual coding process. So for example, with Obra, something like the test driven development, their red green refactor is a really strong thing to do anytime you're gonna build something. And that is not something, for example, that's gonna be built in necessarily to these other tools. And so the third group I would call like the more autonomous
02:03HOOKpipeline. And these are where we tend to see tools like bMAD, for example, or get shit done, where there's a lot of tooling around, like you being able to define something and then literally walk away and come back and, hey, now it's built something from you without, like, necessarily a ton of intervention.
02:19HOOKSo now, obviously, there's crossover between a lot of these categories, but what we are gonna be looking at today is open spec and how it works. So what we're gonna be doing in this video is solving a problem that I hear from a lot of people, especially in my free group and my pay group, but also in the comments on my videos, which is you get this like first version of something like this, and you end up thinking like, this is kind of ugly and it's not really looking like what I want it to look like, but you've spent a lot of work building
02:44HOOKthings, and you really wanna make it pop. And so in this case, I went into Claude design and I spent a little bit of time going through and trying to build things out so that it looks a lot more professional and is something I would actually want to use. So for example, this is what the recipe page looks like right now, and this is ideally what it would end up looking like. And so we're gonna try to use a spec driven development tool to bridge this gap and build all of these screens out step by step. And so something I'm really big on is that you can change skills together. Like, just because you're using one of these doesn't mean you can't use the others. So I'm still gonna use Obra's
03:20working with Git work trees skill in order to spin up this work tree, run all of my tests, and make sure we have a clean baseline before we start. So to get this thing working, it's pretty simple. All you need to do is install the package via this command. Then And you come down, move into your project and just type in open spec in it, choose your environment, and then from there you are ready to go. So one of the things that's really cool that I like about this library is they have this onboarding skill. So if you're new to this and this is gonna be the first time using it and you want it to kind of guide you through the process, if you use this onboard command,
03:51it's gonna actually take you through building your first feature with this system. But for purposes of showing you all the steps and how we're gonna use them, I'm gonna run this thing manually. I'm gonna do is I'm gonna hop back into Claw Design and I'm just gonna copy the command that they give you to allow Claw Code to fetch these designs. And then I'm gonna come through and I'm gonna run the first command which is explore.
04:11So I'm gonna kick this thing off and then we can chat about it. So like most good libraries, it has this optional exploration phase where you can actually think about the ideas before you commit to like exactly how you wanna move through and do it. And so the thing that I really like is you're not locked into like some very specific way of doing things. And with a lot of other tools,
04:32that's what happens. Like, they have their opinionated approach to how you should move through and do exploration, and that gets tied like very specifically to the rest of the process. And so there's not like a ton of flexibility in being able to use those things sometimes.
04:47But you can call this command at really any point in the process when you want to dive deeper into what you're about to change. And so this is a nice benefit over something like SpecKit that kind of assumes that you're gonna hop in directly to the spec and like know the thing that you want to build. It has this opportunity for you to really like hash that thing out ahead of time. So if you've used other libraries like compound engineering,
05:10they have that ideate function. This is like kind of similar, but again, a little bit more flexible. So once it's read through all of that context, it's gonna start like reasoning about like what we asked for. And so in this case, there are a few different ambiguities that we need to go through and answer because we're completely changing the established
05:28design system that we have documented inside of design.markdown, and that gets referenced to be used in agents.markdown. So all of those things need to be updated obviously. And then we're gonna have to also change, like, the structure of the repo because
05:44based on the information architecture that's in the new designs, that's not gonna map very cleanly onto what we have. So there's a good amount of work that's gonna need to be done. I pasted in a little bit of extra context that it needed, and now it is working on clarifying pieces of the plan. And one thing that I really like about this, it will flag things that we need to be aware of before we move forward. And so this process is really valuable because too many people tend to jump straight into,
06:09like, trying to build the thing. And what that means is that any of these assumptions that are surfacing as we have this conversation, the language model's just gonna decide what to do at the time of building the thing, and then you might not be happy with the output. So this explore features are really nice way to sidestep those problems without like a ton of ceremony and processes
06:29that we tend to have in other tools like SpecKit or BMAD or some of those other systems. But what do we from here? Once we have this fully explored, the next step is to generate a proposal. And so what you're gonna get out the other side is this proposal markdown file, a system design markdown file, and then your task list. So in this design system file, we're gonna get a few different things. Number one are gonna be like the primary
06:53architecture decisions. So for example, in this case for this project, how are we gonna migrate over all of the tokens for the design system? How are we gonna actually like build these components inside of our system? Because they're obviously different from what was inside of cloud design. How is our like app routing and like the actual architecture of the like the app itself going to change? So we get a bunch of cool details like that. Then the proposal is more about like, well, what is going to actually change inside of this project? So for example, design system migration,
07:25building out the new screens, building out the new component library, making sure that we're keeping note of how our data models and our APIs are going to need to change based on the new UI that we're building. Because I told it that I didn't wanna do all the back end changes right now. Right? So it's like a very clear change log of like what exactly are we intending to change with this spec. And then we get a phase by phase series of actual tasks that need to be done in order to implement this thing. So we're getting the what and the why of what we're doing from the proposal, the how it's going to be done on a high level from the design markdown file, and then we get the implementation steps from the task file. So this convention is awesome because all of the assumptions and all of the decisions are very clearly documented,
08:11and we have really concrete tasks at each step. And so the last piece of this, we get this new specs directory where for every major chunk of what we need to do. So for example, the bookmarks migration, the discovery page, the people that you're following, the actual, like, design system migration, each of these gets an individual spec that has very clear scenarios about, like, exactly what needs to be there. Now before we move on to actually, like, apply these changes and show what the work process looks like, One thing that I really love about this tool is that they have this validate function. And so in this case, I wanted to make sure it has an extra pass
08:46where it is going to actually verify its work using the Chrome browser extension MCP. And that's not something that's like built into the process. A lot of these tools, they tend to like functionally describe how something should work, but they do not often describe like visually how the thing really needs to look. And that becomes a problem if you're trying to migrate a design system from another tool. And so all we asked us to do was to add a step where it has to verify that. And now that it's made this new spec, it's gonna run through and validate it to make sure that we haven't lost any of the critical details inside of our spec that we're gonna be using to actually build this stuff with. So now we're gonna run the final command, which is apply. And then we're just gonna pass in the directory that it gave us for this project or like the identifier for this project, and we are going to let it run. Now one little note, I did boot up Claude with the Chrome flag,
09:43so that it can actually like interact with the browser as it's going through and verifying its work. Now this process of having like a front end visual check is actually one of the things that is in the Claude code creators stack of tips that can have some of the biggest improvement on what you get out the other side of these types of vibe coding tasks. Alright, guys. So this thing ran through for about two hours straight
10:10without really any intervention taken from me. The only thing I did was at a certain point, I turned on auto mode so that it would stop pausing to ask me questions. So in reality, with those stops in place, this took maybe three or four hours to actually do. But if we had it on auto mode, the actual time, like processing time, it would have taken two hours and eight minutes. And so again, this includes like actually doing all of the work as well as doing the verification
10:37that we put in place where it was using Chrome to actually look at the screens. And so we haven't seen what this is gonna look like yet, but it should be at least pretty close to our designs. So let's go check it out real quick, and then we'll come back and do the final step. So there's a few different things that I specifically wanna look at because they were some of the aspects of the app that was bothering me the most. The first is this discovery page that we have. So we can see it's like a very clear design. We have the sidebar. Obviously, the sidebar needs to be cleaned up a little bit because it didn't do it to spec. But then we have this hero section, what's cooking now. We have these little filter search options.
11:12Then we have this like kind of hero section, which are like updated more recent things. And then it kind of continues through in like a little bit of an editorial way. So if we pop over into the screen, it is looking pretty close to that. So I'm on like a very large screen. And so some of like the spacing of how close the sidebar actually is to like this this middle column, that spacing is a little messed up. So we can address those sorts of things. But overall, like this top section, how it's styled, the little details of like having the person's name and what the recipe was, the trending forks, the editorial pick, all of that stuff is,
11:50uh, pretty spot on. So I'm really happy with that. The other thing that was really bothering me was the user profile page. So if we were to click into, uh, Ren, for example, before this was like very vanilla, like it it was nothing. And now if we pop in and go look at what the design was supposed to be. So we can see here there's a few things that are off. This is supposed to be like an accent color. Uh, the alignment on like some of these buttons, these should be like roughly the same size. One should be accented. So there's like a few things that we would need to dial in on this. But overall, for doing like such a large scale refactor
12:23of the design system, it got like very close to what we were asking it to do. Even this recipe page is like a huge update from what was there in the past. Like, I'm very pleased with how it got through like that first version of what we are asking it to do. And again, the specter of an aspect of what we are doing is why it was able to do this so effectively. So it had, like, the clear functional requirements and clear verification steps. And then it also had those reference designs that it knew to go check. So this is great things work, but one of the surprisingly helpful things is how they finish up a feature branch. And that is one of the things that makes this an awesome tool to use. So if we were to come through here now and run the archive command, basically what this does is it's now going to sync all of the different specs
13:11and the context that was built up and gathered around it with the root source of truth about your app. And that's one of the things that I really love about this library. A lot of people complain about how it's difficult to manage the documentation of their app over time, and this is how OpenSpec helps you manage that. So if we were to go look at this OpenSpec folder where all of this lives, you'll notice that all of the work we were doing was inside of this changes
13:39folder. And so the way this works is that every single, like, net new feature that you have built, in this case, we built out a few of them. So we had, like, this new bookmarks view. We have the discovery page. We had the following page. We had the update to the design system. All of those different things are gonna get their own spec file. And the reason that this is valuable is when a change gets made then in the future,
14:01we're going to have a persistent source of truth that describes how this thing should actually work. So for example, if we were to come down now and look at the bookmarks spec, we have a very clear set of requirements and then, like, user story scenarios that explain, like, functionally what should be happening in this area. Now the reason that this is valuable is that down the line, if we were to go make a change
14:26to our bookmarks functionality in the app, When we go to then, like, archive that change like we just did, if we've done something that now breaks a critical piece of this spec, it is going to surface that issue and force us to reconcile it there. So we don't get these sort of, like, black swans or things that are just like hidden now inside of our project that we don't realize
14:50we broke. So again, it forces you to have like this for all of the major features of your app. And so after all of that is done, we get this archive folder. And if we were to click into this, anything now that we have worked on, so for example, this design system migration, all of that information actually gets stored so that we can always go back and reference it if we need to. So all the tasks we worked on, the proposal,
15:16how we were gonna make sure there was like visual fidelity in place, all of that stuff is now saved for us so we can always go back and look at it later. So this is the base workflow, but there's three other workflows you can use that solve a lot of problems that you get with other tools. So the first one up is actually two different workflows that you use together, and they are new and continue.
15:39One of the paradigms of this tool that I think really make it stand out compared with others is that it takes an iterative approach to planning. Like, you might have some idea, you start planning it out, but then information pops up along the way, and you want to reintegrate that information into your plan moving forward. So one of the ways that they solve that is through these two new commands, new and continue.
16:00So we're gonna kick off this new command and basically we're gonna say now that we have this front end change made, we need to build out the back end functionality so that the API routes are there, the data models are in place, and everything is good for us to be able to actually, you know, do this thing. And so we're gonna kick off with the new command
16:18to start moving in that direction. And so what this does is it sets up a shell for us to move through a similar process that we moved through earlier. So what we would do to continue through this process now is type in o p s x continue. And then if there are any questions that we need to answer based on this, we can put our responses in here. So in this case, have two options. Uh, one is I can do one huge change with everything in it. And number two is that I can slice these changes up into more focused changes and then take them piece by piece, where every single change gets its own proposal specs and tasks. Now since this is touching like the back end logic, I really wanna make sure that we don't miss anything important here. So I chose to go through and slice it that way, which means it's gonna take more time, but it's probably gonna be done better. So now in this case, since we have all of these different slices that we're gonna move through, we can run this new command again.
17:12But in this case, we're saying, well, what do we wanna kick off? Well, in this specific instance, we're trying to work slice by slice. And so we're gonna go through that entire process of creating the proposal, applying the changes, and archiving them for each of these individual pieces. So we can see similar to how we had that scaffolding for this broader plan, we now have the same scaffolding
17:34for this very specific change. So now if we were to come down and run this continue command, what it's gonna do is it's going to draft the proposal. So similar to how earlier we ran that propose command, we're now doing that in this step wise fashion. Instead of us having to call the specific command, we are just moving through the process using this continue command. So the difference that we can see now is when we go into this
17:57specific like change instance for wiring the public profile reads, instead of having generated all of those things at once like we did last time, now we have just the proposal piece. And so we could go through, we can read this, we can make sure that we're on the same page. And then from here, if we move through and run the continue command, it's gonna move on and generate the specs. Now the reason that this is really valuable is that earlier on we looked at that explore command.
18:23So if at any point we're in the middle of doing this and something crops up that we kind of don't know the best way to handle it, we can run the explore command. We can talk through the problem, and then we can integrate that change into whatever stage we're at now. So this library is really good at generating the context, storing it in a really intelligent way, and then letting you move through to the next stage really easily. So one of the things that's really nice is that if at any point we think we're already good enough with the plan and we just wanted to run through the rest of the stages, we can run this fast forward command. And so this is gonna allow us to go a lot faster, but still remain on rails. Like it's still following the system,
19:02which is enforcing like the best way of doing things and having your spec in place, and then developing from that spec and doing everything that you define there. And so this is very similar to what we were doing in that new and continue paradigm, except it's just gonna continue to move through it automatically. So this is now complete and that brings us to the final feature which I think is one of the most valuable things about how this library works.
19:26And that is the sync command. So basically what this does is it helps you keep a running tab of the actual state of all of the different features of your apps that you don't need to worry about documentation going off the rails and quickly becoming out of date. So if we were to come back into that master specs folder and we were to scroll down now to public profile,
19:47we can see that it has been updated based on this work. So all of this extra information in here about, like, the requirements and what the database needs to look like and all of those things, these are all based on the work that we just did in this change. So we already had the public profile spec that existed, but now it's been updated with the work that just happened. So anytime we make any change that touches something that already exists,
20:13we have this built in step that's gonna go back and actually update the documentation so that things never get lost and of what is there. And that is a huge value add that you don't get with a lot of other tools natively. So this library is pretty great. And I think for having like a daily driver type of workflow,
20:33CTAspecifically one that calls these other plugins like Obra or similar libraries in when you need them. For example, with like sub agent execution or test driven development,
20:45CTAthis is for sure a new daily driver, especially if you're working on an established project. So if you like this video, I'm gonna link to a playlist of other breakdowns of tools like this one that I have done. But that is it for this video. I will see you in the next one.
§ · For Joe
Steal the ecosystem map. Build the sync command.
JoeFlow / Mod Boss positioning playbook
Sean's 3-category framing is the cleanest mental model of the AI-coding tool space currently on YouTube — and OpenSpec's sync command is exactly the unlock JoeFlow's morning-batch orchestrator needs to keep a fleet of parallel Claude agents from drifting.
- Lift the spec-first / SDLC-enforcement / autonomous-pipeline framing for a Mod Boss positioning slide — claim the 4th category if JoeFlow doesn't fit one of the three.
- Match OpenSpec's three-artifact pattern (proposal.md / design.md / tasks.md) as the default output of every JoeFlow morning-batch routine — gives every Chef session a predictable shape before code runs.
- Ship a 'sync' equivalent on day one of the batch orchestrator: after every session, reconcile a master project memory file with what shipped. This is the long-term docs-don't-drift unlock and the strongest single feature in OpenSpec.
- Beat Sean's hook with a 5-second visual demo of spec drift — show the doc and the code disagreeing, then sync them. The substance is universal but his open is generic; a creator who leads with visual contradiction wins this audience.
- Steal the 'add a Chrome MCP verification step' pattern for JoeFlow's web-app routines — every routine should have an optional 'visually verify' phase.
- Lean into the 'human orchestrates, agent assists' line as positioning copy — it captures Joe's whole product thesis in 7 words.
§ · For You
If you're tired of Claude Code ignoring you, try this.
For non-creators who just want their code agent to work
The fix for Claude Code 'doing the wrong thing for the millionth time' isn't a better prompt — it's writing the spec first, in a structured format the agent has to read before it touches any code. OpenSpec is the free open-source CLI that enforces this.
- Install OpenSpec via npm (`npm i -g @fission-ai/openspec`), run `opsx init` in your project, pick your environment, you're ready.
- Use `opsx explore` BEFORE you ask Claude to build anything new — it surfaces ambiguities and asks you the clarifying questions you'd forget to think about.
- Run `opsx propose` to generate three files: proposal.md (what & why), design.md (how), tasks.md (the checklist). Read them, edit them, *then* let the agent code.
- Set up a git worktree before big changes so you can throw the experiment away cleanly if it goes sideways.
- After every successful change, run `opsx archive` to promote it into your project's source-of-truth specs folder — that way the next AI session starts knowing what your app actually does.
- If you're working on a long task, use `opsx new` + `opsx continue` to slice it into small focused changes instead of one mega-change. Slower, but the output quality jumps noticeably.
- Best for established projects where the agent keeps forgetting context. Less useful for tiny greenfield experiments.
