I have a software factory, it's just all skills (you can copy them)

Channel: Ras Mic
Published: 2026-09-01
URL: https://www.youtube.com/watch?v=blI10_91xgA

In this video, I share how I ship features at speed while maintaining quality using my software factory. Sponsored by Cursor.

Resources:

Transcript

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. I can use Codex, Claude Code, Grock, Grockbot, this bot, that bot, 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.mmd 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.

Projects Built with My Software Factory

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 2 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 personal agent using the Eve framework by Vercel. I have a dedicated video coming on that. If you want to see it, make sure to let me know in the comments down below. 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 Grockbot, 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 W's 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, the chief of staff 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 one's 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 why I called it Bezalel because with Bezalel what you can do is you can have all the powerups all the tools all the things that make Pluto great but you can give that to your own agent whether you're using Codex, Claude Code, 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 and analysis on your money. And you can also set up iMessage. And what's cool is you can connect multiple agents. I have my Claude 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 set up like a monthly giving subscription or a weekly one or a bi-weekly 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 version two of Pluto, Ruth. Nehemiah is basically Boring Computers, my own little cloud VM. Ezekiel is the Eve framework forked to work on Cloudflare. Pretty awesome stuff. And Scribe is basically my own tracing hotel environment for my agents.

I say that all to say, ladies and gents, I've been shipping.

Cursor Cloud Agents Workflow

Now that you understand the power of my software factory, I think it's about time we talk about it. But before we do, I want to highlight how I'm shipping at scale. 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: the Cursor Cloud agent reproduces the bug, makes the fix, and records a video demonstrating the fix.

Here's what's important 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 a 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 could 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 agent 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 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.

The Software Factory Structure

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. GP loop and GPL loop apps. The difference between GP loop and GPL loop apps is GP loop apps is called when you have like 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.mmd file. 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.mmd 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: 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 says: "Start a new task in an isolated git work tree branched from origin main so multiple agents can work on the same repo in parallel without conflicts. Use at the beginning 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: 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/boundaries orchestrating the why and when. A service layer owns the reusable how with explicit inputs and structured 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 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 layer 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.

Step 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, etc." 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.

Step Four: Ship. Before and after, we just talked about. Then it says: "Open the PR with before and after proof embedded in the description. Screenshot or video whenever the change has visible surface. Measure numbers or output pairs when it doesn't. And then it says, Run GPL loop or GL loop apps when the PR exceeds GPL's file count limit until Grapile 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. Grapile, 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 Grapile 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 GP loop, 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.

(capture appears truncated)