The argument in one line.
OpenSpec enforces spec-driven development for AI coding by requiring you to explore, propose, and validate changes before applying them, then syncs the resulting specs back into your documentation to prevent drift.
Read if. Skip if.
READ IF YOU ARE…
- A vibe coder who has built a first version of an app and finds it ugly or structurally off, and wants a spec-driven process to bridge the gap between what was built and what was designed.
- A Claude Code user frustrated by AI going off the rails mid-build who wants a lightweight framework that forces alignment on what to build before the coding starts.
- A developer working on an established project who struggles with documentation drifting out of sync and wants a built-in archive and sync workflow to keep specs current automatically.
- Someone already using AI coding tools like Obra or BMAD who wants to understand where spec-first tools like OpenSpec fit and when to use one approach versus the other.
SKIP IF…
- You are building something brand new from scratch with no existing codebase — OpenSpec is most valuable on established projects where specs need to stay aligned with reality over time.
- You want a fully autonomous build-and-walk-away pipeline; OpenSpec is spec-driven and human-orchestrated — you are expected to review proposals and guide each phase before proceeding.
The full version, fast.
OpenSpec is a spec-first CLI framework that turns Claude Code into a disciplined collaborator by making the specification itself the primary artifact, not the code. The workflow runs through five commands � explore, propose, validate, apply, and archive � producing a proposal, a system design, granular task lists, and per-feature spec files that double as living documentation. A new iterative layer adds new, continue, and fast-forward for slicing larger features into reviewable chunks, while the sync command reconciles changes against existing specs so docs never drift from reality. Use it as a daily driver on established projects, lean on the explore step to resolve ambiguity before building, and pair it with browser-verification MCPs when migrating visual design systems.
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 →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.
Lines worth screenshotting.
- OpenSpec is a spec-first CLI framework where the specification is the primary artifact that drives the entire build — the agent assists, but the human orchestrates.
- Spec-first development forces clarity about what you are building before any code is written, which prevents the assumption accumulation that derails most vibe-coding sessions.
- The three AI coding tool categories are spec-driven (OpenSpec, GitHub SpecKit), SDLC-enforcement (Obra, agent skills), and autonomous pipeline (bMAD, get-shit-done) — they are complementary, not competing.
- The explore command lets you think through a design change before committing to a spec, which is the flexibility that tools like GitHub SpecKit skip.
- A design.markdown file documents the established design system and is referenced by agents.markdown — changing the visual system requires updating both to stay in sync.
- The sync command is OpenSpec's killer feature — it detects when your codebase has drifted from the spec and proposes updates to realign them.
- Combining OpenSpec with Obra's git worktree skill gives you spec clarity plus isolated branch sandboxing — the two tools are designed to work together, not replace each other.
- The validation step after propose and before apply is where OpenSpec flags ambiguities and risks that would otherwise become bugs discovered post-build.
- Vibe coding fails most often not from a bad model but from skipped specification — the spec is the missing discipline, not the AI capability.
- The archive command stores completed specs as institutional knowledge that can be referenced when building related features later.
- Installation is one npm command plus open spec init in your project directory — there is no configuration file to create or agent infrastructure to set up.
- The iterative workflow (new → continue → fast-forward → sync) maps to how real features evolve — small additions, mid-session continuations, accelerated execution, and alignment checks.
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.
Terms worth knowing.
- OpenSpec
- An open-source, spec-driven AI coding framework (Fission-AI/OpenSpec) where a human-written specification file is the primary artifact that guides Claude Code through a structured propose → validate → apply → archive workflow.
- Spec-driven development
- A software development approach where a detailed specification document is written and agreed upon before any code is generated, ensuring the AI coding agent stays aligned with the intended design.
- Vibe coding
- A development style where a programmer directs an AI agent using natural language prompts rather than writing code manually, relying on the model to handle implementation.
- SDLC enforcement
- Software Development Life Cycle enforcement — tooling that imposes structured development disciplines (such as test-driven development or code review gates) onto an AI-assisted coding workflow to maintain quality.
- Spec artifact
- A persistent written document — typically Markdown — that defines what a software feature or system should do, serving as the authoritative source of truth that an AI coding agent reads and follows.
- Autonomous pipeline
- An AI coding workflow where the agent can interpret a high-level goal, plan, implement, and iterate with minimal human intervention between steps, returning a finished result.
- Sync command (OpenSpec)
- An OpenSpec command that detects drift between the current codebase and the original specification, then updates the spec to reflect what was actually built — keeping documentation and implementation aligned.
- Design system
- A shared set of reusable UI components, color palettes, typography rules, and spacing guidelines used consistently across a software product to ensure visual and functional coherence.
- Test-driven development (TDD)
- A software practice where failing tests are written before any implementation code, then the minimum code needed to pass those tests is written — ensuring features are built to a verifiable standard.
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
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.”
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.
metaphor
00:00Today, 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.
00:13So 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?
00:38I 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. So 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.
00:58And 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. So 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.
01:25The second category I would call software development life cycle enforcement. So these are things like agent skills, over superpowers, and compound engineering, where, yes, they have certain workflows that they move you through.
01:39But the real value in these tools from my perspective is that they enforce best practices and discipline onto 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.
01:55And 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 pipeline.
02:04And 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:19So 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 things, and you really wanna make it pop.
02:46And 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.
03:04And 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.
03:17So I'm still gonna use Obra's working 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.
03:27So 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.
03:40So 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, it's gonna actually take you through building your first feature with this system.
03:55But 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.
04:30And with a lot of other tools, that'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.
04:43And so there's not like a ton of flexibility in being able to use those things sometimes. But 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.
04:54And 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, they have that ideate function.
05:12This 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 design system that we have documented inside of design.markdown, and that gets referenced to be used in agents.markdown.
05:36So 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 based on the information architecture that's in the new designs, that's not gonna map very cleanly onto what we have.
05:50So 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.
06:05And so this process is really valuable because too many people tend to jump straight into, like, 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.
06:22So this explore features are really nice way to sidestep those problems without like a ton of ceremony and processes that we tend to have in other tools like SpecKit or BMAD or some of those other systems. But what do we from here?
06:35Once 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.
06:48So in this design system file, we're gonna get a few different things. Number one are gonna be like the primary architecture decisions.
06:55So 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?
07:06Because 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.
07:17Then the proposal is more about like, well, what is going to actually change inside of this project? So for example, design system migration, building 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.
07:36Because 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.
07:47And 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.
08:05So this convention is awesome because all of the assumptions and all of the decisions are very clearly documented, and 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.
08:20So 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.
08:34Now 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 where it is going to actually verify its work using the Chrome browser extension MCP.
08:53And 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.
09:06And 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.
09:28So 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, so that it can actually like interact with the browser as it's going through and verifying its work.
09:48Now 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.
10:06Alright, guys. So this thing ran through for about two hours straight without really any intervention taken from me.
10:14The 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.
10:31And so again, this includes like actually doing all of the work as well as doing the verification that 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.
10:49So 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.
11:01So 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.
11:07But then we have this hero section, what's cooking now. We have these little filter search options. Then we have this like kind of hero section, which are like updated more recent things.
11:17And 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.
11:26So 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.
11:38But 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, uh, pretty spot on. So I'm really happy with that.
11:52The 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.
12:05And 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.
12:12Uh, 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.
12:20But overall, for doing like such a large scale refactor of 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.
12:33Like, 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.
12:48And 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.
13:03So 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 and 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.
13:21A 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 folder.
13:40And 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.
13:49We had the following page. We had the update to the design system. All of those different things are gonna get their own spec file.
13:56And the reason that this is valuable is when a change gets made then in the future, we'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.
14:22Now the reason that this is valuable is that down the line, if we were to go make a change to 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.
14:44So 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 we broke. So again, it forces you to have like this for all of the major features of your app.
14:58And 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.
15:13So all the tasks we worked on, the proposal, how 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.
15:31So the first one up is actually two different workflows that you use together, and they are new and continue. One 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.
15:45Like, 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.
16:15And so we're gonna kick off with the new command to 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.
16:27So 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.
16:38So 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.
16:54Now 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.
17:28So we can see similar to how we had that scaffolding for this broader plan, we now have the same scaffolding for 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.
17:42So 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.
17:54So the difference that we can see now is when we go into this specific 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.
18:08And 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.
18:45So 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, which 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.
19:11And 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.
19:41So if we were to come back into that master specs folder and we were to scroll down now to public profile, we 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.
20:01So 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, we 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.
20:23And 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, specifically one that calls these other plugins like Obra or similar libraries in when you need them.
20:41For example, with like sub agent execution or test driven development, this is for sure a new daily driver, especially if you're working on an established project.
20:51So 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.
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.
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.
How they asked for the click.
VERBAL ASK
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.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
OTHER LINKSAlso linked in the description.
Visual structure at a glance.
