Big Idea

The argument in one line.

Claude Code workflows turn six named multi-agent patterns into composable JavaScript files you can describe in plain language, letting a single session fan out dozens of sub-agents, run adversarial reviews, and react to its own findings mid-run.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You already use Claude Code daily and feel the ceiling of static skill files for research or multi-step tasks.
You have tried stringing sub-agents together manually and wanted a cleaner, reusable structure.
You want to automate repeatable maintenance like keeping CLAUDE.md current or refactoring React components.
You are worried about runaway token costs from multi-agent runs and want concrete control mechanisms.

SKIP IF…

You are new to Claude Code and still learning how basic prompting and skill files work.
You only use Claude Code for one-off, single-session tasks where parallelism adds no value.

TL;DR

The full version, fast.

Claude Code workflows upgrade the agent from a single-threaded assistant to a composable multi-agent harness built from six named primitives. Any complex task can be broken into fan-out, adversarial verification, tournament, or loop stages that run in parallel or sequence. Workflows are strict JavaScript files you create with natural language; the when_to_use field controls auto-triggering. The primary cost controls are explicit token budgets in the prompt, the /goal command for hard completion criteria, and careful scoping of sub-agent count.

Free for members

Chat with this breakdown — free.

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

Create a free account →

Chapters

Where the time goes.

00:00 – 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.

Atomic Insights

Lines worth screenshotting.

Dynamic workflows let you set a token budget by prompt — Claude adheres to it, making runaway costs a prompting problem, not a platform problem.
The six workflow patterns are composable — production workflows combine at least three: Classify-And-Act, Fan-Out-And-Synthesize, Adversarial Verification, Generate-And-Filter, Tournament, Loop-Until-Done.
Narrative lock is a structural failure mode of LLMs: once the model commits to an explanation, adversarial verification with fresh-context agents is the structural fix.
Workflow files are strict JavaScript with a JSON schema — that strictness prevents deviation, not the model’s judgment.
The when_to_use meta field is the auto-trigger contract: a vague value means Claude may run the workflow spontaneously.
Running 19 sub-agents in parallel is how a tournament workflow consumes tokens — the ceiling is parallelism, not task complexity.
Mining CLAUDE.md candidates from session history surfaces outdated entries that reading the codebase alone would never find.
A workflow can spawn additional sub-agents in response to mid-run findings — something a static skill file cannot do.
Isolated worktrees let parallel fix agents commit independently, preventing collisions across concurrent edits.
Quick workflow is a valid prompt instruction that scopes agent count — specificity is the primary cost lever.

Takeaway

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.

02How workflows work

Parallel fans out sub-agents simultaneously; pipeline runs them in sequence — knowing which primitive fits is the first design decision in any workflow.

04Patterns 1–3

Adversarial Verification breaks narrative lock: fresh agents with scoped mandates force the model to debate its own conclusions rather than defend them.

05Patterns 4–6

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.

07CLAUDE.md mining workflow

Mining CLAUDE.md candidates from session history surfaces outdated entries that reading the codebase alone would miss.

08React Refactor Tournament

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.

09Best practices

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.

Glossary

Terms worth knowing.

Dynamic workflow: A reusable multi-agent harness in Claude Code that can spawn parallel sub-agents, run them in sequence, and adapt its structure based on intermediate findings.
parallel(): A Claude Code workflow primitive that fans out tasks to sub-agents simultaneously and waits for all to complete before proceeding.
pipeline(): A Claude Code workflow primitive that passes each item through a sequence of agent stages in order.
Adversarial Verification: A workflow pattern that challenges one agent’s output with a separate fresh-context agent prompted to find flaws, reducing narrative lock.
Narrative lock: The tendency of a language model to commit to one explanation early and resist updating it even when context supports a different conclusion.
Tournament pattern: A workflow where multiple agents attempt the same task, a judge model picks winners, and successive elimination rounds run until a final winner emerges.
Loop-Until-Done: A workflow pattern that repeats a sub-task cycle until a measurable acceptance criterion (e.g., test coverage percentage) is met.
Token budget: An explicit cap on token consumption stated in the prompt that Claude Code enforces across the full workflow run.
Worktree: A separate checkout of a repository that lets one agent work on and commit changes independently of the main branch or other parallel agents.
CLAUDE.md: A project-level Markdown file read by Claude Code at session start that encodes project-specific conventions not obvious from reading the code alone.

Resources

Things they pointed at.

00:55linkAnthropic Claude Code Workflows documentation ↗

01:50channelCompound Engineering

10:20toolContext7

18:00toolVercel React best practices skill

Quotables

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.”

Disarms the common objection immediately — good cold-open clip.→ TikTok hook↗ Tweet quote

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.”

Crisp explanation of adversarial verification value — stands alone.→ IG reel cold open↗ Tweet quote

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.”

Practical control tip most viewers do not know — immediately useful.→ newsletter pull-quote↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

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

metaphoranalogy

Clud 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 burn millions of tokens.

But 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 that 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. So a lot of the things I'm gonna go through in this video are based on this documentation.

So at the most abstract level, Cloud 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 that you might wanna do really well that ClaudeCode itself out of the box isn't particularly great at. So things like researching, security analysis, using agent teams, running code reviews, those are the types of things where ClaudeCode itself isn'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. So 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.

So 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 are 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. It can fetch all of the sources, Then it adversarially verifies the claims with separate sub agents.

And 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.

But 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.

But 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, and 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. The 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. Either 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. So 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.

It 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.

And 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?

Well, 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 and 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? And 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. And 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 versus 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. But 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. The first pattern up is called classify and act. And this is where you would give in some sort of task.

It can then classify that 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. So 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. Maybe 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. The 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. And 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. So 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. And 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 type.

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, it 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.

And 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.

That 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, narrative lock that was taking place kind of fades away, and you can spin up a bunch of these at the same time.

So 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, with 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, overlap 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. You 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.

And 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.

But 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.

So 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 verification.

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. And 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.

Or 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.

And 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 loop 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. You 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, you 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.

So 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.

So 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, how 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. Well, 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. And 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, maybe 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.

And 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 skill 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.

And 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 twenty years experience in some field.

And again, these models are prone to narrative lock in. So 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.

So 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 review 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.

So 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.

So 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.

And 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.

They'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 obvious 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. Step 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.

And 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 from, like, what is already inside of the project.

So we're grabbing all of our chats. We're mining them for, like, opportunities for potentially updating the clogged markdown file.

And then we're running through an adversarial verification, where 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.

So 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 of 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? Or 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. And 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. And 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. And 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. It 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 that 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. And 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, invariance 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. So 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, which 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. And, 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. This So one is called the React Refactor Tournament.

And so what this one is gonna do is it's going to invoke Vercel's React best practices skill.

So what this one is gonna do is it's going to identify the 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. It'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. And 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. It'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.

And 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.

Like, 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.

So 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.

One 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.

So 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.

You 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.

So the meta of the workflow, you have like the name, the description, uh, when to use it.

If 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.

But 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, where 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. It'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. But, again, all of this stuff gets created for you.

So for example, in, like, that phase one, like, the scoping, there 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 in 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. But 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. So number one is prompting.

You should be very detailed about telling it how to set things up. I actually use the exact language from 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. You 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. If 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. So 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 and 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 around 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. So 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. And 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. So 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.

We 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.

So 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.

Again, 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.

But that's it for this video. I will see you in the next one.

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.

Frameworks

Named ideas worth stealing.

05:09list

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 fordesigning any multi-agent automation: research, code review, brainstorming, content generation

14:16model

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 forkeeping any long-lived project CLAUDE.md current without manual review

18:00model

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 forsystematic code quality automation on any codebase with a clear best-practices skill

CTA Breakdown

How they asked for the click.

VERBAL ASK

26:41subscribe

“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.

MENTIONED ON CAMERA

00:55linkAnthropic Claude Code Workflows documentation ↗

FROM THE DESCRIPTION

PRIMARY CTAWhere the creator wants you to go next.

OTHER LINKSAlso linked in the description.