Video of the Day20:40Ras Mic · Tutorial
My Complete Codex Agentic Engineering Workflow
Ras Mic walks through the seven habits, plugins to slash commands, that turn OpenAI's Codex from a prompt box into a full agentic coding workflow.
August 14thThe argument in one line.
A software factory isn't a custom coding harness, it's a portable AGENTS.md file plus five skills (isolate, build, prove, ship, coordinate) that any AI coding agent can follow to ship reviewed, working code.
Read if. Skip if.
READ IF YOU ARE…
- You're running Claude Code, Codex, or Cursor on a real codebase and want a repeatable process instead of ad-hoc prompting.
- You're coordinating more than one coding agent on the same repo and keep running into branch collisions or overwritten work.
- You want AI-generated PRs reviewed to a measurable bar before you merge them, not just 'looks fine to me'.
SKIP IF…
- You're looking for a specific product recommendation rather than a workflow you build yourself, this is a DIY system, not a tool to buy.
- You don't use Git worktrees or branches at all; the entire isolation mechanism assumes a standard Git workflow.
The full version, fast.
The video argues a 'software factory' isn't a custom AI harness, it's a workflow: one AGENTS.md file plus five skills any agent can call. Every task runs the same four beats. Isolate opens a fresh Git worktree and branch so parallel agents never collide. Build follows a service-layer pattern that separates business rules from reusable operations. Prove captures before-and-after evidence, screenshots or metrics, while the bug is still reproducible. Ship opens the PR with that evidence embedded, then loops an automated code-review agent, reading its feedback and pushing fixes, until it reports a 5-out-of-5 confidence score with zero unresolved comments before the PR is ever presented for merge.
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 – 01:40
01 · Cold open — what a software factory is
Defines the term against expectations: not a giant custom harness, but workflow, skills, and domain knowledge that stay harness-agnostic and model-agnostic.
01:40 – 02:25
02 · Projects it powers: Pluto and Grogbot
Pluto was deleted and rebuilt in two weeks on a new agent framework; Grogbot spins up dedicated agents (proposal writer, client research, baby helper) reachable by group chat or iMessage.
02:25 – 03:29
03 · Bezalel — superpowers for any agent
One MCP server gives any coding agent memory, email, texting, a sandbox computer, cards, and bank access, so the same power-ups work regardless of which harness is in front.
03:29 – 04:10
04 · GoshenPay and the Boring Computers org
A church-giving payment system with automatic tax receipts, housed alongside sibling projects (Bezalel, Ruth, Nehemiah, Ezekiel, Scribe) under one GitHub org.
04:10 – 06:18
05 · Sponsor: Cursor Cloud Agents ship 500+ PRs
Cursor Cloud Agents reproduce a reported bug, fix it, and record a video of the fix embedded in the PR, letting the reviewer trust the change without re-running it, and can even verify whether a reported bug is real.
06:18 – 07:23
06 · Inside AGENTS.md — the four-beat workflow
Every task in the repo moves through the same four named stages: isolate, build, prove, ship, each backed by a specific skill file.
07:23 – 10:28
07 · Isolate — one worktree per feature
A hand-drawn branch diagram shows why every new feature opens a fresh Git worktree from origin/main: many agents can build in parallel without colliding, then merge back in.
10:28 – 12:48
08 · Build and Prove — service-layer code, then evidence
Code follows a service-layer split (orchestration owns the why/when, services own the reusable how); before shipping, before-and-after evidence is captured while the bug is still cheap to reproduce.
12:48 – 16:36
09 · Ship — loop until the review score hits 5/5
PRs open with before-and-after proof embedded, then an automated code-review agent (Greptile) is looped: it reads feedback and pushes fixes until confidence hits 5/5 with zero unresolved comments, only then is the PR presented.
16:36 – 19:22
10 · Harness-agnostic, model-agnostic, and how to steal it
The same AGENTS.md works across Codex, Cursor, and Claude Code (not, jokingly, Anti-Gravity/Gemini); the multi-agent rules that prevent collisions are laid out, and the whole skills repo is public to copy and adapt.
Lines worth screenshotting.
- A software factory is a workflow, skills, and domain knowledge, not a custom coding harness, so it works with Claude Code, Codex, or Cursor interchangeably.
- Rebuilding a project with a defined agent workflow took a week and a half versus the month and a half the first version took without one.
- Every coding task should run in its own Git worktree and branch, so many agents can work on many features in parallel without ever touching the same files.
- A service-layer architecture keeps 'why and when' logic in an orchestration layer and 'how' logic in a reusable service layer, so a bug fix in one flow propagates everywhere it's used.
- Capturing before-and-after evidence while a bug is still reproducible, before the fix, is cheaper than trying to prove it after the fact.
- A PR should embed a screenshot or video of the fix in action, so a reviewer can trust it without reading the code line by line.
- Looping an automated code-review agent until it reports a 5-out-of-5 confidence score with zero unresolved comments catches issues before a human ever reviews the PR.
- Rules like 'never commit to main' and 'one worktree per task per agent' are what let multiple AI agents work on the same repo without colliding.
- A cloud coding agent that reproduces a reported bug before fixing it can also be used to verify whether a reported bug is real in the first place.
- An instructions file that any agent can read is what makes a workflow model-agnostic, since the process lives in the file, not in a specific tool's memory.
A four-beat workflow file, not a custom harness, is what ships reviewed code fast.
WHAT TO LEARN
Naming the same four stages, isolate, build, prove, ship, in one instructions file lets any AI coding agent work in parallel without collisions and only surface a PR once it clears a measurable review bar.
01Cold open — what a software factory is
- A repeatable workflow, curated skills, and accumulated domain knowledge produce more reliable results than any specific AI tool or harness.
- A system built once to be harness-agnostic and model-agnostic keeps working even when the underlying AI tool changes.
02Projects it powers: Pluto and Grogbot
- Rebuilding a project from scratch with a defined workflow can take a fraction of the time the original build took, because the process, not the code, was the missing piece.
- Splitting responsibilities across dedicated agents keeps each agent's context focused instead of overloading one general-purpose agent.
03Bezalel — superpowers for any agent
- Giving an agent its own email, computer, sandbox, and even a card or bank connection turns it from a chat window into something that can complete real-world tasks.
- Routing multiple different coding agents through one shared tool layer means the choice of agent stops being a rewrite decision.
04GoshenPay and the Boring Computers org
- Organizing side projects under one umbrella makes it easier to reuse the same workflow and skills across all of them.
06Inside AGENTS.md — the four-beat workflow
- A single instructions file that names which skill to call at each stage turns a personal workflow into something any agent can follow consistently.
- Naming each stage of a workflow makes it possible to skip a stage deliberately instead of accidentally forgetting it.
07Isolate — one worktree per feature
- Branching every new feature from the latest main, in its own worktree, is what allows many agents to work on the same repo in parallel without overwriting each other.
- Checking open PRs and their changed files before starting a task catches file-level collisions before they happen instead of after.
08Build and Prove — service-layer code, then evidence
- Separating 'what this flow means' from 'how to do this operation reliably' stops the same bug from having to be fixed in five different places.
- Capturing the broken state before attempting a fix, while it's cheapest to reproduce, produces stronger proof than trying to recreate it afterward.
09Ship — loop until the review score hits 5/5
- Embedding proof, a screenshot, a video, or measured before/after numbers, directly in a pull request lets a reviewer trust the change without re-running it themselves.
- Automating the read-feedback-and-fix loop against a code-review tool's score means a human only sees the PR once it already clears the bar.
- A cloud coding agent that reproduces a reported bug before fixing it can also be used to verify whether a reported bug is real in the first place.
10Harness-agnostic, model-agnostic, and how to steal it
- A workflow proven across multiple AI harnesses is worth more than a workflow tuned to one tool's quirks, because the tools keep changing.
- Publishing your own instructions and skills file, then deliberately tweaking it against your own repeated habits over weeks, produces a system that fits your actual work better than an unchanged copy of someone else's.
Terms worth knowing.
- AGENTS.md
- A markdown file placed in a repo's root that tells any AI coding agent which skills to call and in what order, making a workflow portable across different tools.
- Git worktree
- A separate working directory linked to the same Git repository, letting an agent build a feature on its own branch without disturbing the main checkout.
- Service-layer architecture
- A code structure that separates business rules and decision-making (the orchestration layer) from reusable low-level operations (the service layer).
- MCP server
- Model Context Protocol server: a single connection point that gives an AI agent access to a standard set of tools and integrations, such as email, a computer, or a bank account.
Things they pointed at.
02:25toolEve (Vercel agent framework)
12:28tool@vercel/before-and-after CLI
14:10toolGreptile
Lines you could clip.
00:05
“A proper software factory is more about your workflow, skills, and domain knowledge more than it is the harness.”
17:30
“This didn't happen all at once. This was weeks and months of figuring out what my workflow is.”
15:16
“I'm not getting a PR that's getting a two out of five, a three out of five that has a security issue. I'm getting a PR that's been fully reviewed.”
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.
metaphorstory
I built my own software factory. Now when you hear that phrase, you're probably thinking of a giant custom harness, and that could be far from the truth. To be frank, a proper software factory is more about your workflow, skills, and domain knowledge more than it is the harness.
So a software factory should be harness agnostic and model agnostic. So I can use Codex, Cloud Code, Grok, Grokbot, Thisbot, Thatbot, Hermes Agent, whatever it is. If I have a proper software factory setup, I can use whatever model and whatever harness.
and i can still get results in today's video i'm going to be sharing with you the projects i've built with my software factory i'm going to explain to you how the software factory works which means i'm going to be sharing with you my agents .md file and my skills these are things i've never shared before i've shared one skill file here and there but i'm going to share everything with you in its entirety and finally i'm going to show you how to apply this to your agentic development yes you can copy my skills but you know what's more powerful if you build your own let's get into it.
So some of the cool projects that I've built that I want to share with you. First of all, you all know Pluto. I've been talking about Pluto for months, but here's what's so interesting.
I rebuilt Pluto in two weeks, meaning I deleted everything and I rebuilt it from scratch in two weeks. Now you might be wondering, why would you rebuild the entire thing in two weeks? First and foremost, I made the realization that OpenClaw as the agent was a terrible decision.
So we removed OpenClaw and we built our own person. personal agent using the Eve framework by Vercel. I have a dedicated video coming on that.
If you want to see, make sure to let me know in the comments down below. So we used Eve as the underlying framework and I basically built. Pluto in two weeks, and it was all because of my software factory.
In the same way with Grogbot, you can create multiple different agents. I have a proposal writer agent. I have a client research agent.
I have a baby helper agent. Recently had a child. Make sure you write Ws in the chat.
But I can also create a group chat where I can have different agents chat with each other, get work done, or I can directly chat with the underlying main agent, , as Grogbot likes to call it. And there's a lot of cool. things we've given this agent access to, like its own computer, its own sandbox environment, file system, its own email.
You can even give your agent access to its own card so it can make purchases for you. And obviously you can chat with your agent via iMessage. Cool stuff.
Another project that I built, and this has been getting traction on Twitter, is Bezalel. Bezalel, for those of you who don't know, was a biblical character in Exodus who was a master craftsman and God had given him wisdom to build the first tabernacle. That's what I called it.
Bezalel. Because with Bezalel, what you can do is you can have all the power -ups, all the tools, all the things that make Pluto great, but you can... give that to your own agent, whether you're using Codex, CloudCode, Cursor, whatever agent that it is that you're using, you can basically have your own Pluto with your own agent using Bezalel.
And the way it works is it's one MCP server, gives you access to thousands of connectors, your own email client. You can even give your agent access to its own computer, sandbox, memory, credit card. You can even connect your bank account and you can get your agent to do some budgeting.
Analysis on your money. And you can also set up iMessage. And what's cool is you can connect multiple agents.
I have my cloud code and my codex connected. And I can even select which agent gets. Which tool?
Another project I've been working on is my church payment system. I want people to be able to, you know, set up like a monthly giving subscription or a weekly one or a biweekly one with a specific amount and get receipts automatically that they can give to their accountant so they could file their taxes. Working on that as well.
And then I have a whole other organization called Boring Computers where I'm working on Bezalel. I'm working on, I called the version two of Pluto Ruth. Nehemiah is basically Boring Computers, my own little cloud VM.
Ezekiel is the E. framework for to work on Cloudflare. Pretty awesome stuff.
And Scribe is basically my own tracing slash hotel environment for my agents. I say that all to say, ladies and gents, I've been shipping. Now that you understand the power of my software factory, I think it's about time we talk about it.
But before we do, diapers are expensive. Let's hear a word from today's sponsor. I don't mean to flex, but look at this number.
Over 500 PRs closed, and this is in a very short time. And a lot of this is because of Cursor Cloud Agents. Let me share with you my workflow.
We have a place where we collect issues. In our case, it's linear. You can use anything as long as there's an MCP connection.
That MCP connection fires off a Cursor Cloud Agent, and these are the three steps that are followed. Cursor Cloud Agent reproduces the bug, makes the fix, and records a video demonstrating the fix. I'm going to show you the result of this.
Here's one PR. summary, the things that were fixed. But here's the most important part for me as someone who reviews these PRs.
I get a video of the fix. in action and because of this i don't have to blindly trust what the agent says i have video proof of the fix being implemented you see it right here in front of you here's another pr again you have your summary and there's this video right here linked i jump straight to the video first before i even read the pr just because it saves me so much time so we were updating our onboarding flow and you can see here the agents at work but here's what's even more insane this will blow your mind i can get the cursor cloud agents to verify the bugs that are sent Because let's say someone reported a bug that doesn't really exist.
Here's an instance where the agent verified the bug actually being real. It says here, displaying stalled run. And then if I move the video forward, it says confirming stuck chat.
So it confirmed that the bug was real. But guess what it did? It didn't just confirm that the bug was real.
It also fixed it. So not only can I use the agent to fix bugs, I can use it to confirm the errors that people are submitting. All this is possible because they have a powerful hardware.
harness, a powerful cloud environment. I have a desktop running right here that I can control myself with my application running locally. And I also have access to state of the art models and I can switch with just a few clicks.
If you're not using Cursor Cloud Agents to ship PRs the way we are, then you're falling behind. Make sure to change that by clicking the link in the description. Let's get back to the video.
All right. So the software factory. consists of a few files.
I actually have it open here on VS Code. We have an agents .md file, and then we have new feature, which is a skill, greploop and greploop -apps. The difference between greploop and greploop -apps is greploop -apps is called when you have 3 ,000, 4 ,000, 5 ,000 lines of code.
And then we have evidence -driven testing. We have code structure. before and after.
Let's look at the agents .md file. So here's the workflow. Step one, isolate, we're going to call the new feature skill.
Every new feature starts in a fresh Git work tree branched from origin main so agents can work in parallel without conflicts. Never build on main. This line right here is one of the most important lines in this agent .md file.
And I'm going to explain to you why. So let's say we're working on a project, right? In this case, let's say we're working on project Bezalel.
One thing that agents have unlocked for us is the ability to work on different features in parallel. Now, let's say this is the... project development path.
This is the main branch, right? For those of you who use Git, then you're familiar with this. For those of you who don't, you might not be.
Just try to follow along. So we're on the main branch. This is the start of the project.
This is the completion of the project. Let's say I want to work on the very first feature, right? What's going to happen is what isolate is going to do using the new feature skill, isolate is going to make a copy of the existing project and start a new path right this is what we call branching in git and let's say this is new feature one right this is like i'm just working on some random feature what the agent is going to do because of new feature the agent is going to start building the new feature on this new branch it's not going to build on the main branch it's going to build on a new branch on a new work tree what's cool about this is we can have multiple agents working at different parts at different stages on different features and guess what the main branch is not affected usually what happens is if you don't have something like this set up is you might have one agent working on this branch but then you tell another agent to build another feature
what's going to happen is it's going to be working on the same branch that the previous agent was working on. And this can cause a problem. This can cause a collision.
This agent might create a new file and this might delete the file or these two agents might edit the same file. There's a lot of issues that arise in this situation. So what isolate allows is it allows for my agent to spin off a work tree.
And in that work tree, I can build my new feature. Here's what's cool. Let me just delete this.
this is cleared up once the feature has been built i'm just going to speed run to the end once the feature has been built what the agent is going to do is it's going to merge it back into main so during this time while i was developing this feature i could have had 10 ,000 other agents working on a different feature, they're not going to collide.
They're not going to override each other. They're not going to step on each other's toes, right? So this is what the new feature does, right?
And if I read the skill itself, you can see the description here. It's to start a new task in an isolated work tree branched from origin made so multiple agents can work on the same repo in parallel without conflicts. Use at the beginning, watch this, of every new feature, fix or task before writing.
any code so this gets called in the very beginning this is why step one is isolate step two is code structure code structure happens during this point when the agent is working on the feature what code structure basically is it's basically telling the agent to write code in a service layer architecture with action slash boundaries orchestrating the why and when a service layer owns the reusable how with explicit inputs and structure returns this is just basically a way i like code to be structured because if it ever come a time where i have to manually review this code like it's 2022 or something then it's written in a way that is easy for me to digest and get used to, right?
So for the developers, you might disagree with a service leader architecture. You might want it written in a different way. The point for this is get this skill written in such a way where the code written makes sense to you.
For me, a service leader architecture makes sense for me. Not only that, the agents are really good at it, right? And when we read the description, it says, use when multiple workflows duplicate the same operational logic.
When deciding what belongs in action versus shared services, or when refactoring repeated operational blocks across domain flows. Use when adding new features that share mechanics with existing ones.
Another thing, I found that AI loves to write duplicate code or loves to write duplicate functions. This skill helps with writing maintainable code. So first, we isolate the feature, right?
This is where new feature gets called. Second, we... Build the feature, right?
Using code structure. We're building this feature as we speak, right? Our agent is building, building, building.
Number three, prove. We're going to call the evidence -driven testing skill. Verify with the repost checks plus runtime evidence.
Capture the before state while reproducing the issue prior to fixing it. When it's cheapest and after once the change works. What evidence -driven testing does is it's going to test whether the bug that you reported actually is broken.
It's going to try to reproduce the issue. it's going to make a fix, and it's also going to record the solution in action. Now, this will only work if your machine meets a certain criteria, but if this does not work for you, you can always use a cloud agent.
Or you can use the next step, which automatically is going to be added, which is the ship step. But I'm more so talking about the before and after skill. Now, this is a skill I ripped off the Vercel repo.
So this is Vercel skill that I've added into my software factory. Look what it says here. It says captures before and after screenshots of web pages or elements for visual comparison.
Use when the user says take before and after screenshot comparison, et cetera, et cetera, et cetera. So before and after basically will take. a screenshot of the before state and the after state.
And here's what it does. It will post it in the PR. Here's an example of the before and after PR.
So I wanted to update the dashboard agent control panel. I wanted there to be more toggles and like, I just wanted the UI to be changed. And this was the before state.
I didn't really like this. And this is the after state, right? So you can imagine when I'm reviewing PRs, I have a before and after state.
It makes life really, really easy, right? It makes reviewing very easy. That's what before and after does.
So if evidence -driven testing doesn't work for you, you can ask your agent, make it work for me. If it doesn't, fear not. you have before and after.
But let's look at step four, shipping. Before and after, we just talked about. Then it says, then greploop.
Open the PR with before and after proof embedded in the description, screenshot or video whenever the change has visible surface, measured numbers or output pairs when it doesn't. And then it says, run greploop or slash greploop apps when the PR exceeds greptile's file count limit until greptile reports five out of five with zero unresolved comments.
Finish. by presenting the PR URL. This part is my favorite.
Let me show you what happens. Let me go to the example PR earlier. Greptow, which is one of my favorite code review agents, you can see here, we got a confidence score of five out of five.
But here's what's interesting. I want you to realize that this was the first code push. This was the first PR.
And then Greptow... gave a review. It wasn't a five out of five to start with.
Maybe a three out of five, a four out of five. Could have been a two out of five, right? But my software factory, because it runs slash greploop, it will wait for the confidence score.
Once it sees it's not a five out of five, it will read the reviews and it will push a fix. And that's what this is. This is a second push.
And then greptile reviewed again. Still didn't get a five out of five. Gave some more feedback, right?
You can see here, this is the feedback it gave. And my agent read this feedback and solved it. And it pushed again.
After that, notice there's no feedback. And the score went from whatever score it was to a five out of five. Here's a perfect example of a PR that's currently in the works.
So I have a PR. I'm just going to open this in the browser so you can see this. This is an open PR right now.
The onboarding is being changed. see i have a before and after working right now but let's look at the confidence score oh the confidence score just became a five the reason why i know it just became a five is because i scrolled up earlier in the pr notice here it did a bunch of work and the last step was PR with before and after grep loop to five out of five.
So it kept working. It read the feedback and it kept improving onto the PR until it got a five out of five. So when I'm getting PRs because of my software factory, I'm not getting a PR that's getting a two out of five, a three out of five that has a security issue.
I'm getting a PR that's been fully reviewed by greptile. So what happens in this stage is let's say I've gone to the point where the features. good the pr has been made this is not getting merged by me until i get a five out of five so my software factory will continue to read the feedback from greptile and then will only give me the pr url once it's got a five out of five once we've reached five out of five status.
It's my job to look at before and after. It's my job to read the description. And then I just merge.
Doing this with multiple agents, multiple features, multiple harnesses, you can see how I can move really, really fast with a project that I have a defined scope on. I know exactly how things should look. And even if I mess up and I want to rebuild something again, Pluto took me, I would say maybe a month initially, a month and a half.
to get it to stable version. Pluto V2 with the software factory version one, I did not use a software factory with V2. It literally took me a week and a half to get it working two weeks for polish.
And now it's just more of a marketing thing, planning and all that type of stuff. It's literally ready to go. And that's because my software factory is harness agnostic and it's model agnostic.
I can use this with codecs. I can use this with cursor. I can use this with cloud code.
I can use this with whatever harness that it is that you want to use. It probably won't work with anti -gravity. Cause Gemini is just terrible.
So don't use it with anti -gravity. So when you take my agents .md, which tells your agent. how to use every single skill that I have, you inevitably have a software factory that will produce five out of five features that are ready for you to test and merge.
This is what a software factory is. Now, in terms of how you can use this, the first thing that I would do is I would go to the GitHub URL slash Michael Shumela slash skills. I'll link it in the description as well.
Copy this, give it to your agent and build a sample project. See how this works. for you but then i want you to tweak it to your liking into your workflow right this didn't happen all at once this was weeks and months of figuring out what my workflow is figuring out what i do repeatedly like the one thing i noticed that i kept doing repeatedly again and again is after I got a PR, I would run greploop always, right?
Now, this is part of my software factory. I don't need to run greploop because the agent knows to run greploop. Why?
Because it is explained in the agents .md file. And a couple of rules that I have in my agents .md file is never commit directly to main, one work tree and one branch per task per agent, never reuse or modify another agent's work tree, branch or uncommitted work. So I can truly have agents work in parallel, scope check before starting, skim over.
open PRs, changed files, never force push to main, resolve log files, work trees, don't isolate shared resources, and then how to complete a task. So I have all this information that you give to your agent with these skills. It will start to cook features for you in the highest quality possible.
And ladies and gents. that is my software factory there's a lot more i can talk about but i think i want to end it off here let me know in the comments down below what you think let me know if you want to see more videos about this i want to challenge you all to download all of this and to actually build something with it and i want to know your feedback let me know in the comments down below make sure to like comment subscribe hit the notification bell we just hit 100k subs thank you so much god bless you all it is really a dream come true and i have not forgot i'm going to do something special just Give me some time.
Recently had a baby, so been really busy with that. But that's pretty much it. Like, comment, subscribe.
Hit the notification bell. I'll see you in the next one. Peace!
The Hook
The bait, then the rug-pull.
The video opens on a claim built to get clicked: a personal 'software factory.' The reveal undercuts the hype on purpose. It isn't a custom-built agent harness, it's an AGENTS.md file and five reusable skills that make Claude Code, Codex, or Cursor follow the same isolate-build-prove-ship process on every task.
Named ideas worth stealing.
06:18list
The Four-Beat Agent Workflow
- Isolate
- Build
- Prove
- Ship
The spine of AGENTS.md: isolate the task in a fresh worktree, build with a service-layer structure, prove the fix with before/after evidence, ship with that evidence embedded and a review-score loop.
Steal forany AGENTS.md or agent instructions file meant to govern how a coding agent completes a task
10:28model
Service Layer Architecture
- Orchestration Layer (Actions) — owns business rules, state, auth, retries
- Service Layer (Shared Mechanics) — owns reusable operations, provider/SDK calls, structured returns
Separates 'what this product flow means' from 'how to do this operation reliably' so a bug fix or provider swap only has to happen in one place.
Steal forstructuring code an AI agent writes so a human can still review it quickly
17:38list
Multi-agent rules
- Never commit directly to main
- One worktree and one branch per task per agent
- Never reuse or modify another agent's worktree or branch
- Scope check open PRs before starting
- Never force-push to main, only --force-with-lease on your own branch
- Resolve lockfile conflicts by regenerating, not hand-merging
The guardrails that let many coding agents work on the same repo at once without stepping on each other.
Steal forrunning more than one coding agent against the same repository
How they asked for the click.
VERBAL ASK
05:50product
“If you're not using Cursor Cloud Agents to ship PRs the way we are, then you're falling behind. Make sure to change that by clicking the link in the description.”
Woven in as a mid-roll sponsor segment demonstrated with a real PR workflow (bug repro, fix, and a recorded proof video embedded in the PR) rather than a generic ad read, then handed back into the main topic.
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.
