§ 01 · The Hook
The bait, then the rug-pull.
Claude Code’s workflows shipped quietly, but Sean Kochel argues they deserve more than the “burns millions of tokens” dismissal making the rounds. This is a structured breakdown of the six composable patterns underneath every workflow, two real examples he built and runs himself, and the four controls that prevent a workflow from torching your token budget.
Where the time goes.
00:00 – 01:44
01 · Cold open — what workflows solve
Dynamic workflows as custom harnesses for tasks Claude Code handles poorly natively: research, security analysis, agent teams.
01:45 – 04:08
02 · How workflows work: parallel and pipeline
parallel() fans out sub-agents simultaneously and waits for all; pipeline() runs stages in sequence. Static vs. dynamic workflow comparison via a checkout migration decision.
04:09 – 05:08
03 · Setup: the six patterns
Introduction of the six named composable primitives; they can and should be combined.
05:09 – 09:00
04 · Patterns 1–3: Classify, Fan-Out, Adversarial
Classify-And-Act routes tasks by severity. Fan-Out-And-Synthesize runs parallel sub-agents and merges results. Adversarial Verification combats narrative lock with fresh-context debaters.
09:01 – 11:55
05 · Patterns 4–6: Generate-Filter, Tournament, Loop
Generate-And-Filter spawns idea generators then filters by rubric. Tournament runs pairwise elimination rounds. Loop-Until-Done cycles until a measurable acceptance criterion is met.
11:56 – 14:15
06 · Combining patterns: Deep Research and meta-prompt fact-check
Deep Research = Fan-Out + Adversarial Review. Fact-checking a skill file = Classify-And-Act + adversarial loop.
14:16 – 17:59
07 · Real workflow 1: mining session history for CLAUDE.md
Fan-out over 20 sessions, adversarial double-pass (Structure Lens + Novelty Lens), 10 genuine candidates found in 26 minutes.
18:00 – 23:00
08 · Real workflow 2: React Refactor Tournament
Scope, Discover, Backlog, Tournament (pairwise judges, 3 cycles), Fix in isolated worktrees. 19 parallel sub-agents.
23:01 – 25:20
09 · Best practices: prompting, /loop, token budgets, saving
Four controls: detailed prompting, /loop + /goal, explicit token budgets, save workflows to .claude/workflows/.
25:21 – 26:52
10 · Close and CTA
Subscribe ask; links to both workflows in description.
Visual structure at a glance.
Named ideas worth stealing.
05:09
list
Six Workflow Patterns
- Classify-And-Act
- Fan-Out-And-Synthesize
- Adversarial Verification
- Generate-And-Filter
- Tournament
- Loop-Until-Done
Named composable primitives that can be combined to construct any dynamic workflow.
Steal for designing any multi-agent automation: research, code review, brainstorming, content generation
14:16
model
CLAUDE.md Mining Workflow
- Fan-out over recent sessions
- Parallel candidate discovery agents
- Structure Lens adversarial pass
- Novelty Lens adversarial pass
- Synthesized report
Reads session history to surface patterns worth adding to CLAUDE.md, including outdated entries. Two adversarial passes filter for non-obvious, evidence-backed additions.
Steal for keeping any long-lived project CLAUDE.md current without manual review
18:00
model
React Refactor Tournament
- Scope
- Discover
- Backlog
- Tournament (pairwise judges, 3 cycles)
- Fix in isolated worktrees
Identifies React optimization candidates, ranks them through tournament elimination, and commits fixes in parallel isolated worktrees.
Steal for systematic code quality automation on any codebase with a clear best-practices skill
Lines you could clip.
00:50
"They can feel a little bit abstract like, hey, you can run something called a workflow now and it’ll burn millions of tokens. But there are some real gems that, dare I say, are game changers."
08:13
"It’s forcing the model to debate back and forth with itself with fresh context so that any of that narrative lock that was taking place kind of fades away."
24:21
"You can tell it that it has a token budget. If you were to say you can only use 100,000 tokens for this entire run, it is going to actually adhere to that."
Things they pointed at.
01:50channelCompound Engineering
10:20toolContext7
18:00toolVercel React best practices skill
How they asked for the click.
26:41
subscribe
"If you’re someone trying to upscale from basic vibe coding into more intermediate vibe engineering, as I like to call it, you should Hulk smash the subscribe button."
Single direct ask at the very end with a memorable phrase. Clean.
Word for word.
HOOK opening / re-engagementCTA the pitch metaphor analogy
00:00HOOKClud workflows dropped about a week ago, and they're not really getting enough airtime. And I think the reason for that is that they can feel a little bit abstract like, hey. You can run something called a workflow now, and it'll .
00:14HOOKBut there are some real gems that, dare I say, are game changers. So I'm gonna break down what workflows really are, how they work, and the six patterns
00:24HOOKthat you can use to make them with real examples. And if you want any of the ones that I show you, there will be a link in the description below. And so credit where credit is due, the best description of what these things are and how you can use them actually comes from Anthropic itself.
00:38HOOKSo a lot of the things I'm gonna go through in this video are based on this documentation. So at the most abstract level,
00:45HOOKCloud Code itself is an agent harness that is mostly built for coding, even though there are other use cases and types of tasks. But inevitably, there are these certain types of tasks
00:56that you might wanna do really well that ClaudeCode itself out of the box isn't particularly great at. So things like researching, security analysis,
01:06using agent teams, running code reviews, those are the types of things where ClaudeCode itself
01:12isn't super well suited to actually do those things in-depth. And so what workflows do is they allow you to dynamically create these, like, different harnesses on the fly.
01:23So that, like, in a pretty easy way, you can create these reusable harnesses that can solve pretty complicated problems in a a much easier way.
01:32So a few plugins out there, like Compound Engineering, for example, they tried to build these types of workflows into their skill files in the way that they would use sub agents, but now that stuff is just supported directly inside of Cloud Code. So one example just to, like, ground everything we're about to talk about, this new deep research that rolled out with Opus 4.8 and these workflow releases
01:54are an example of a dynamic workflow. So what this thing specifically does is it can fan out and do a bunch of different web searches.
02:03It can fetch all of the sources, Then it adversarially verifies the claims with separate sub agents.
02:10And then finally, synthesizes all of that back to you in a cited report. So this is an example of a dynamic workflow. And so this is something that you could have tried to force together in the past with different, like, skills and commands and trying to, like, manually call them and string them together.
02:26But now it's better, it's more seamless, it's supported natively, and it's easy for you to create these things with natural language. So how do they work? Uh, first things first is that you need to have the agent, obviously, that's powering all of this stuff.
02:39But then there are two things that make this, like, different and what constitute it being a workflow. Number one is that it can run things in parallel. And so in this case, what happens is that you can pass it, like, all of these different things that it needs to accomplish,
02:52and it can run all of them at the same time, and then it waits for all of them to finish. So for example, if you were gonna run, like, a deep research report, it would go out, it would run all of those like search queries and exploring your code base and all that stuff at the same time, and then would wait for all of them to come back together.
03:09The second piece is a pipeline. And so in the cases where things don't have to wait for all of them to done and they can be run-in order, we are running a pipeline. Now the thing is when we're working with workflows, it doesn't need to have both of these.
03:22Either of them can be used individually, or depending on the workflow, they can be combined. So here's, like, very concretely what this might look like in practice.
03:30So if you were to ask, for example, should we migrate our checkout service to a new provider? Inside of, like, the static traditional, like, clawed code harness, this might turn into, like, five different web searches.
03:41It fetches the top results from those web searches. It verifies what it found, and then it summarizes it back to you and gives you a generic research report.
03:50And so, for example, like, can have a skill that instructed it, like, hey, you need to go through these stages. So what makes a workflow different?
03:58Well, in a dynamic workflow, it might first go out and read our actual, like, current, like, Stripe integration or billing code. So maybe it identifies that there's three different, like, primary functions inside of the the app that handle these things. It then takes all of that as context
04:14and checks each of our features against, like, the new provider that we're considering documentation. It also has a separate agent that's trying to price out, like, based on the volume that we're doing. What is the cost consideration within this?
04:29And then maybe you have an adversarial review stage that kicks in, and it takes all of, like, the individual context that it's been getting from these different sections. And maybe it tries to make a case against migrating.
04:41And so the result of this is that you get a much more specific set of recommendations out the other side. So this is, like, fundamentally what the the difference is between, like, a static harness
04:52versus these, like, kind of, like, customized harnesses via a dynamic workflow. So in a bit, we're gonna go through, like, some very concrete examples of these things.
05:01But first, I wanna walk you guys through these six patterns that can be used to construct any number of workflows. So again, the one thing to keep in mind as I go through all of these things is that they can and probably should be combined together. So we're gonna go through again some of those cool use cases after we talk about what each of these things actually are.
05:21The first pattern up is called classify and act. And this is where you would give in some sort of task. It can then classify
05:29that task and like what it really means. And then it can route that task to specific agents, depending on, like, the logic that you set of how it chooses to actually route something. So a really simple example of something like this might be, like, handling, like, bugs and edge cases inside of your app.
05:46So you could have a workflow that classifies those bugs based on, like, the severity or the complexity. And then depending on exactly where it falls in that spectrum, maybe you're handing certain things off to, like, Haiku to solve, like, very basic things.
06:00Maybe you pass, like, medium bugs off to, like, Sonnet with a systematic debugging type of skill. And then maybe your most complex issues get passed into, like, Opus, for example. So this would be an example of the classify and act pattern.
06:14The next one up is called fan out and synthesize. So this is where you take a task, you split it up into a sequence of smaller steps. Each of these steps runs individually, like, as sub agents.
06:25And then the results of all of them get passed back to a synthesizer that returns you the end result that you were looking for. So again, a really well known example of this is going to be like a research style workflow.
06:37So maybe it's going out first and it's exploring your code base, then it's pulling in, like, actual documentation from providers, maybe using something like Context seven. Then it's looking for, like, common use cases that are circulating online.
06:49And then after it has all of these things, it's gonna synthesize all of that into a final result and report back to you. So number three and one of my favorite of these is the adversarial, like, review and verification
07:02type. And so one of the big downsides of language models is that they really tend to lock in on narratives. Meaning, if something comes out of the context that you've been generating,
07:12it might find one thread there, turn that into some sort of story, and then start jamming that story down your throat, when in reality, like, the claim isn't that verified, and it just locked into some direction.
07:24And now it has, like, blinders on, and it won't consider anything outside of that. And so the thing that's really cool about this adversarial approach is that we can challenge all of the claims and premises with a fresh verification or, like, adversary.
07:38That is really, like, a forcing function. Like, it's forcing the model to debate back and forth with itself with fresh context so that any of that, like, that was taking place kind of fades away, and you can spin up a bunch of these at the same time.
07:52So for example, each of these different, like, adversarial verifications that are taking place can all have, like, different definitions and scopes of what they're actually looking for when they're evaluating this claim. So the fourth is called generate and filter. This is one that I think compound engineering does really well, where we have different agents that are solely responsible for generating, like, ideas, for example,
08:14with different prompts about, like, how they specifically think about generating ideas. Then you get a big list of ideas out the other side, and you can actually filter them down based on a, like, a rubric, a set of criteria,
08:27overlap between them. And then finally, from that, you get, like, the best ideas out the other side, and the ones that didn't fit your criteria get discarded. And so you can imagine you wanna, like, brainstorm different approaches to some feature that you have in your mind.
08:41You could kick off three different sub agents that are thinking about how to solve that problem from different perspectives. And then you could filter all of the ideas that pop out the other side based on, like, the context of your app, the dos and don'ts of your app, maybe, like, your business or marketing standards, depending on, like, the use case that you're using this for, because this isn't just for coding use cases.
09:01And then again, you're returning just the best ideas, like where maybe you wanna take that that feature, maybe what the UX approach for that feature should be. It's really sky's the limit if you get creative with how you wanna use these things. So again, in a few minutes, we're gonna get into how you can combine all of these together.
09:16But first, let's finish up with the last two. So the fifth one is fun. It's called the tournament, and this is where you're spawning agents to compete on the same task.
09:24So each agent here is attempting to solve the same task using different approaches. And then we have a judge model that is judging the outputs of all of these things and trying to get down to, like, what is the actual winner. So this one almost feels like a combination of the generate and filter and the adversarial
09:40verification. But the difference is that we are going through rounds. So for example, we have these two different competing ideas that result in one winner, but then we had the secondary round that had its own test it was running that resulted in its own set of winners.
09:55And now we're gonna pair these two winners against each other in battle until we get to our final result. So maybe you're trying to brainstorm, like, the best UX approaches for your app, and each of these different attempts that you are launching is, a different approach to how you could think about the user experience. And then we're taking those winners, pitting them against each other, and finally landing on, like, what is actually the best approach to the UX for this feature or for the app in general.
10:19Or maybe you're trying to brainstorm viral hooks for your marketing campaign based on the hook library that you lifted off of your favorite YouTuber. That type of system would work equally well here. So the last one that we have here is called loop until done.
10:34And this one out of all of them is probably the one that gets used the most with others. So it's pretty straightforward. What this thing does is it's gonna continuously
10:43loop through a problem until a set, like, acceptance criteria is met, and it knows that it's complete. So maybe, for example, you realize that you just built this entire app and you weren't following, like, a test driven development approach, and now you have, like, no testing across your entire app.
11:00You could kick off an agent that's meant to discover all of the areas of your app that are untested. And then for all of those new findings,
11:08you could kick off a sub agent. That sole responsibility is to find the riskiest areas of your app that are untested, and it just continues to loop through this until, for example, it has, like, a certain percentage of test coverage across all the different, like, functionality inside of your app.
11:24So this one, like, feels kind of similar to a Ralph loop, but it's it's a little bit more flexible, I think, in how you can actually invoke it and the logic it uses to to get things done. So like I said earlier, there's a lot of use cases where you can combine these things together. So let's go through a few of those and talk about which ones they are combining.
11:42So one good example of this is the built in deep research workflow. So let's say, for example, that, like, you have an app that uses a language model, and you realize that, like, you might not be efficient with the amount of turns that are being taken, how it's, like, summarizing information,
11:58how it's cashing tokens, all of that type of stuff. And you know that you need to put something like that inside of your project so that your costs don't, like, get blown out of the water.
12:07Well, you could run a deep research workflow that first goes out and it fans and synthesizes. So it's gonna break down what that query is, like prompt optimization techniques for an app that does x, y, and z.
12:20And maybe it goes out and it determines that it needs six different sub agents that are gonna go out and they're gonna look at, like, different components of what you asked. After it takes into account all of that research,
12:32maybe then runs it through an adversarial review. And what that review is looking at is it's looking at the context of your code base, the conventions that you already have in place, the problems that your app is actually meant to solve, the tech stack that you are actually using, and it's going to fact check each of these claims that came through from the fan out stage to make sure that they are actually accurate and make sense given the context of your project specifically.
13:00And then after all of that is done, it will synthesize it down into a set of concrete recommendations for you. Now one of the things that makes this, I think, a little bit stronger than something like a
13:12skill is that as findings come out of the research or the adversarial review, it can continue to iterate and improve the quality of what is kind of going on.
13:25And we'll look at an example of that in a second where I show you, I think it's the third example that I have, where it starts spawning a lot of different sub agents to resolve things that are coming up in real time. So another use case of these things being combined together might be fact checking your meta prompts. I think one thing that people love to do is to tell their tool to go out and, you know, research something, and then, like, build a skill that replaces
13:50twenty years experience in some field. And again, these models are prone to narrative lock in.
13:55So if you're not, like, really fact checking those things and verifying everything that gets encoded into those prompts or those skills, you could be doing things that, like, just simply aren't correct, because the model has convinced itself that combining those things together actually reality, it may not really make sense.
14:13HOOKSo for example, you could have a classify and act pattern that actually checks through that, like, meta prompt or skill, and looks for all of the things that are being claimed to be a fact. And then based on all of those facts that it uncovers, it can act toward a adversarial
14:29HOOKreview that then actually loops through and looks at all of those claims, researches them, and make sure they actually make sense and integrate with the skill that you had in the first place.
14:42So now we're gonna go through two real concrete examples of these that I have made for myself that combine about three patterns, I think, each one. So the first one is mining from your session history updates that should be made to your Claude Markdown file.
14:55So a lot of people, like, create a Claude Markdown file once and then forget about it for eternity. And the Claude Markdown file is one of, like, the most important things for you to keep up to date if you want to vibe code, like, a total Chad and not become a meme that someone talks about on Twitter with having AI slop and such.
15:14And the reason for that is that you really wanna document patterns and conventions inside of your project that are not obvious. So Claude code and really any tools that supplies just as much to like something like Codex.
15:26They're really good at understanding things that are very clear patterns. But anytime they would have to read like a lot of stuff to understand something that could just be explained in a sentence or two, or if there are things about your project that would not be immediately
15:41obvious from a language model just reading your project, those are things you wanna have inside of your Claude Markdown file. And so here's what this workflow does.
15:50Step number one is a discover and digest. So we can think of this as, like, a fan out pattern, where it is going to take the last 20 conversations within this project, like sessions I've had within this project.
16:02And then it's going to loop through all of those sessions with parallel agents that read chunks of the session, and then propose anything that came out of that session that is a potential candidate for being included inside of the Claude markdown file based on, like, the rules that I gave it, which in this case were, like, things that are not easily inferable
16:25from, like, what is already inside of the project. So we're grabbing all of our chats. We're mining them for, like, opportunities
16:33for potentially updating the clogged markdown file. And then we're running through an adversarial verification,
16:38where it's gonna take all of those candidates, and then it has two different, like, skeptic lenses that is gonna look through to think if it needs to reject this.
16:46So the first one is the structure lens, which is going to try to see if what we're saying should go in that Claude Markdown file is easily inferred from what we already have in the project. And then it has another one that looks at, like, the novelty or truth
17:01of what actually came out in this mining loop. So is this already in the clawed markdown file? Is it not a real pattern that needs to be documented?
17:09Or is it simply not really supported by the evidence? So then it continues that process for two rounds, seeing if, like, okay, well, I loop through this again, am I finding anything new? And again, these are all, like, fresh agents, so fresh set of eyes.
17:21And then once that's all done, it synthesizes it down into a report for us. So this is a good example of where we're using, like, at least three different patterns, and we're doing something that would be, like, very convoluted and difficult to replicate inside of something like a like a skill.
17:36And I will get into, the end of this video, the best practices so that these things don't run away and blow through millions of tokens. Because full disclosure, this one did use millions of tokens to do this.
17:47And the reason that happened is because I didn't follow my own best practices that I'm about to discuss with you. So if we wanna look at, like, well, what does the output actually look like? This thing ran, I think, for about twenty, yeah, twenty six minutes.
17:58HOOKIt read the 20 sessions that I loaded it up with. It looped through six different times, which is definitely overkill. And it ended up finding 10 candidates
18:07HOOKthat survived two different adversarial passes. So in this case, like, the project that we're we're using here, this is like one of my, like, paid plugins that people get inside of my community. And I have certain, like, conventions that I like to follow when I am improving this and, like, releasing updates and doing all that type of stuff.
18:24And so what this was looking for in this case was my own cloud markdown file for, like, maintaining this thing that I build for other people. And so I found a bunch of different things, tooling and runtime issues inside of the project,
18:37invariance across files, like things that are different and, like, break from patterns and conventions, Details of, like, how different plugins and skills actually work together, like, aren't obvious without actually going in and reading those skill files. And then it actually found some things that are now out of date.
18:53So I didn't actually update my Clawdermarkdown file, and now what I specify in there is not actually correct. So for example, I have like this visual verification loop skill,
19:03which was originally stubbed as I was building this thing out, but now I actually have the full version of it. And so the clawed markdown file is saying that this is a stub, like, is no longer accurate. So these are all things that I would wanna move through then and update.
19:15And, we're gonna get into, like, some of the best practices of this in a second. But before I do that, wanna walk you through another workflow that I think is pretty cool.
19:23This So one is called the React Refactor Tournament. And so what this one is gonna do is it's going to invoke Vercel's
19:30React best practices skill. So what this one is gonna do is it's going to identify
19:35the candidates of optimization using that react best practices skill. It's gonna have judges identify which of these are actually the bigger issues inside of the project based on the context of the project and the severity of the thing.
19:49It's gonna have one winner from that, and then it's going to continue back through that loop of identifying the issues, running them through this tournament, and finding the winner for as many cycles as we tell it to. In this case, it's defaulting to three cycles so that it doesn't go crazy.
20:04And so if we wanted to pop in and, like, see what this looks like as it's running in real time, they actually have this, like, phased system where we can see, like, what are the phases of this workflow that are actually running. So in this case, it's first defining, like, the actual scope.
20:18It's then moving through a discovery phase and finding, like, all of the opportunities for where we would even, like, want to apply this thing. Uh, part of the skill that I defined is that anything it finds, it writes to a backlog so that we can always go back and reference those things and don't have to rerun the skill.
20:34And then it's gonna actually run it through the tournament and make the fixes. So we'll let this thing run for a little bit, and then we'll pop back in and look at the outputs. And so we can see in this case that all of these different tournament rounds are running at, uh, pretty much the same time.
20:47Like, they don't need to be run necessarily, like, in a strict pipeline where, like, one needs to wait or, like, anything like that. These are all running in parallel.
20:56So when we talk about, like, why this stuff can consume tokens, the number of, like, tasks that are gonna be done can balloon quickly if you're not, like, really aware of what type of workflow you're kicking this thing off on. So if the idea of running, like, 19 different sub agents at the same time is something that's, like, scary to you, Again, we'll get into some of the best practices in terms of, like, how you can control these things so that you don't end up with a session that is just, like, blowing through tokens like crazy.
21:23One thing that I will say, though, is, like, in this case, for example, the React best practices gives you, like, really good detailed guidance on what to do, and they give examples of the types of fixes. So honestly, if we had run this on Sonnet, it probably would have gotten, like, the same quality of work done, I think, without having to blow through this many Opus tokens.
21:42So those are the types of things, though, that, like, you can explain in natural language when you create these workflows, what models you want it to use for specific, like, rounds of the workflow, like, all of those types of things.
21:53You can control those and configure those things. So the last thing that we'll look at while that is running is like, what does this file actually look like? So these workflows are created as a JavaScript files.
22:05So the meta of the workflow, you have like the name, the description, uh, when to use it.
22:10If this isn't something that, like, you want to specifically trigger, and that is something to be aware of, these workflows will run by themselves. And so you wanna be, like, very clear about the when to use kind of, like, meta field so that it doesn't go off and do crazy stuff.
22:25But then we have, like, what are the different phases that are gonna actually run inside of this thing? And this is how we're getting that structure inside of that workflow,
22:33where we have, like, the scope, the discovery, the backlog, the tournament, the fix. All of this was created in natural language by me describing what I wanted to happen. And then the rest of this file is just giving it the logic of how it's going to actually work.
22:45It's very strict on, like, the schema of the thing, so that it's gonna, like, actually run, like, a little bit more, like, deterministically, and it's not gonna go off the rails and do random stuff. So it is very strict.
22:55But, again, all of this stuff gets created for you. So for example, in, like, that phase one, like, the scoping,
23:02there are very clear instructions on how things are being done, what the tasks are. So all of these things and the configurations, like how many rounds it's running in loops and, like, all of those things are specified inside of this file. Now if this is intimidating, you don't need to necessarily go in and read it, but you should at least be aware that this lives inside of your project in a in your directory
23:22in a workflows folder. And so now what we have happening is that the fixes are actually being done inside of separate work trees, and they are being committed as they are done. And so there's really endless opportunities for how you can combine all of these different types of, like, workflows to compose, like, really great ones that help you solve involved problems.
23:42But like I said a few times, you need to be aware of best practices and how you can control these things so that they don't go off the rails and end up burning through tokens. Because I promise you it will do that if you're not aware of what you can control. So these best practices are again coming from from Anthropic directly.
23:59So number one is prompting. You should be very detailed about telling it how to set things up. I actually use the exact language
24:07from these when I'm describing what I want it to do. So for example, with the tournament workflow that we just looked at, I told it, like, I want you to use a tournament with pairwise judges that do x y and z. So being very specific about how you prompt things.
24:21You can also tell it that you want this to be, like, a quick workflow that doesn't go crazy. So I think this is part of where, like, the whole, like, it's gonna burn tokens argument goes out the window. You can force it to do things in whatever way you want it to do.
24:34If you give it an open ended task, like, yeah, it might go up and accidentally spin up a 150 agents, But you should see that happening if you're paying attention to what's happening, and then just go in and modify the workflow so that it fixes that. Number two, using goals and loops.
24:49So on the loop side, if you create a workflow, maybe you created some workflow that can, like, look at failing poll requests, and it it runs through some sort of workflow to resolve that in whatever way you want to. You can run that on a loop, for example, that's going to look for failing pull requests on some sort of interval
25:04and then run it through your workflow. Uh, another thing you can do is use the slash goal command inside of ClawdCode to set, like, an actual hard measurable completion requirement so that the workflow has context
25:17around when to stop. Number three, and I think this is the biggest takeaway, is you can tell it that it has a token budget. So for example, if you were to go through and say, like, you can only use 10,000 tokens, you can only use a 100,000 tokens for this entire run, it is going to actually adhere to that.
25:35So this is, like, a really powerful thing if you're afraid of, like, the number of tokens that are gonna be used or whatever. Just, like, tell it what your threshold is for this thing being run properly, and then you won't have to deal with that.
25:48And then last but not least, you can save workflows. So you can save workflows, you can share workflows, and it's really easy to do that.
25:56So for example, like, we were to pop back down inside of this specific, uh, skill, if I was to come through and hit save, I can give it a name, and now this skill is going to be saved into our project, and then we can reuse it.
26:09We can share it. We can put it in a repo and share it with others. Like, whatever you want to do, sky's the limit.
26:14So like they say, it's a whole new world. It is, I think, borrowing patterns from, like, things that other plugins were attempting to do, but now it's an extension of ClawdCode, and it actually is going to work that way by default. And there is a lot of control that you have over the system.
26:30CTAAgain, if you want the two workflows that I went through specifically and you wanna customize them, which I I recommend you do customize them, you can find links for those in the description below. If you're someone trying to, like, upscale from basic vibe coding into, like, more intermediate vibe engineering, as I like to call it, you should Hulk smash the subscribe button.
— full transcript
§ 05 · For Joe
Six patterns that turn Claude Code into a real orchestrator.
WHAT TO LEARN
Claude Code workflows are not a new product layer — they are a named vocabulary for wiring parallel agents, adversarial reviewers, and elimination tournaments into repeatable automation that reacts to its own findings mid-run.
- Parallel fans out sub-agents simultaneously; pipeline runs them in sequence — knowing which primitive fits is the first design decision in any workflow.
- Adversarial Verification breaks narrative lock: fresh agents with scoped mandates force the model to debate its own conclusions rather than defend them.
- A Tournament is not just Generate-And-Filter — it runs elimination rounds, pitting winners against each other, so the final output survives multiple independent judges.
- Loop-Until-Done works when the completion condition is measurable (a coverage percentage, a candidate count) rather than subjective.
- The when_to_use field on a workflow file is a trigger contract — a vague value means Claude may activate the workflow at the wrong moment.
- Token budgets are a first-class prompt instruction; specifying use 100k tokens caps the run without editing the workflow file.
- Saving a workflow checks it into .claude/workflows/ — it becomes a versioned team artifact you can share and iterate like any other file.
