The /build Command.
One slash command, every blueprint. /build is the generic executor your workshop ships with. You name a blueprint (or describe a goal in plain English), and the same six steps run every time: read the blueprint, surface hard blockers, plan, execute in checkpoints, verify, and (optionally) log the decision. Once you have it, the question stops being how to wire a build and starts being which blueprint to point at next.
- A runtime, not a one-off command that every blueprint in the workshop already knows how to plug into.
- A six-step flow you can predict from blueprint identification to verification, with checkpoints between every move.
- A shortcut to the capstone because Stage 05's agent-that-builds-agents is /build pointed at a brand-new blueprint scaffolded on the fly.
Read the runtime before you run it.
Framework cards are concept-first. Have Claude walk you through how /build actually works, using the morning-brief blueprint as the example. No building yet. Just understand the runtime, then point it at something later.
How this fits in the OS.
Claude Code installed, your CLAUDE.md in place so the agent knows who you are, and the workshop repo cloned so configs/commands/build.md is reachable from your sessions.
Whatever blueprint you point it at. Today the repo ships morning-brief, grow-room-monitor, and youtube-cairns. /build reads the folder, follows the same flow, and hands back a working setup. Calls /log-decision at the end if it's installed.
Every other blueprint, including the ones that don't exist yet. Write a new blueprint folder the workshop way, and /build <name> runs it. The capstone (Agent That Builds Agents) is this same runtime pointed at a blueprint Claude scaffolds on the fly.
What /build actually is.
/build is the generic blueprint executor. One slash command. One file (configs/commands/build.md). The whole job is reading a blueprint and turning it into a working local setup.
It is deliberately not specialized. /build does not know what a morning brief is. It does not know what a grow-room monitor is. It knows how to read a blueprint folder, ask the few questions it actually needs, plan the build, execute in checkpoints, and verify. The specifics live in the blueprint. The runtime lives in /build.
This split is the whole point. If every blueprint needed its own custom slash command, the workshop would be a graveyard of one-off commands that drift apart. Instead, every blueprint files into the same runtime and the same six steps. The shape is the same; only the contents change.
When you write your own blueprint later, you don't write a new command. You write a README following the workshop pattern, drop it in the blueprints/ folder, and /build <your-blueprint-name> runs it. The runtime is doing the work you'd otherwise rebuild from scratch every time.
How a blueprint plugs in.
A blueprint is a folder under blueprints/ with a specific shape. /build knows where to look for each piece. The shape is small on purpose:
README.md. The product promise, the architecture, the 4D versus 8D split if it has one, and the test checklist. This is the first thing/buildreads to figure out what it's building.QUICKSTART.md(orQUICKSTART-4D.md/QUICKSTART-8D.md). The step-by-step deploy. Numbered moves, in order./builduses this as the spine of the execution phase.- Code, configs, schemas, sample data. Whatever the blueprint actually ships. For
morning-brief, that's the JSON contract and the Supabase migration. Forgrow-room-monitor, it's the Python MCP server./buildreads what's there and uses it.
The three blueprints in the repo today follow this shape. blueprints/morning-brief/ has the README, the 4D and 8D quickstarts, the JSON contract, and the schema. blueprints/grow-room-monitor/ has the README, the quickstart, and the full Python server. blueprints/youtube-cairns/ has the README, the 8D quickstart, the pipeline, and a starter vault.
You don't memorize the folder shape. When you write a new blueprint, ask Claude to scaffold one that follows the workshop pattern. /build will read it the same way it reads the ones already shipped.
The six-step flow /build runs.
Every /build session moves through the same six steps in order. Read these once and you'll recognize them every time the runtime fires.
Identify the blueprint
~1 minYou either named a blueprint (/build morning-brief) or handed it a goal in plain English. If you named one, /build reads the folder. If you described a goal, it asks one question: "should I use an existing blueprint, or draft a build plan from your goal." For the morning brief specifically, it hands you off to the friendlier /build-morning-brief command (more on that two sections down).
Gather only hard blockers
~5 minThe runtime asks only what it can't proceed without. Where should the output land? Which sources are wired? Which delivery channel sends the ping? Which accounts need manual auth? What's your cost ceiling per run? If a safe default exists, it doesn't ask. No bike-shed questions.
Plan in checkpoints
~3 min/build returns a short Build Plan before touching anything: the files it will create or edit, the accounts you must handle, the commands it will run, how you'll test it, and the rollback plan. It waits for your approval. This is the highest-leverage minute of the whole flow. If the plan is wrong, push back here, not after the files are written.
Execute in small checkpoints
~30-60 minThe runtime builds in a fixed order. Folders and config first. The compile step second. The delivery step third. A manual test fourth. Scheduling last, and only after the manual test passes. The order is enforced for a reason: scheduling a broken compile is how an agent fires silently into nothing every morning.
Verify
~5 minA build is only done when the artifact exists, you can inspect it, the delivery ping fires (or you've explicitly deferred it), no secrets are sitting in plaintext, and you know the single command to run it again. Anything less and the runtime treats the build as unfinished.
Log the decision (optional)
~2 minIf /log-decision is installed, /build offers to log the final architecture choice: the blueprint, the sources, the delivery channel, the reasons you picked them. Next time you run /build on a similar problem, that record is searchable. Say yes. The compounding kicks in around the third build.
Why the morning brief has its own command.
You'll notice the repo also ships /build-morning-brief. The natural question: if /build is the generic runtime, why does the morning brief get its own slash command?
Two reasons. One, it's friendlier as a name. "Build my morning brief" is what a Sunday-cohort student actually types. /build-morning-brief reads like that. /build morning-brief reads like a tool invocation. The capstone is the moment to lower the friction of typing.
Two, it carries the capstone-specific scaffolding. The morning-brief command knows about the 4D versus 8D split, knows about the spec lock that pins Telegram as the May 3 delivery adapter, and knows the source list to pick from. /build doesn't carry any of that, by design. The wrapper command holds the capstone scaffolding so the runtime stays generic.
Under the hood, /build-morning-brief is doing the same six steps. Same hard-blocker pass. Same Build Plan shape. Same checkpoint order. Same verification. It is /build underneath, with a friendlier door and a couple of capstone-specific defaults pre-loaded.
Capstones get friendlier-named wrappers. Anything else uses /build <name> directly. When you ship your first blueprint that isn't a capstone, no wrapper needed. Just write the blueprint folder.
The capstone unlock.
Stage 06 ships Agent That Builds Agents, the meta-capstone. The promise: hand the agent a one-sentence problem ("Every Friday at 5pm, summarize my week from Gmail and Calendar and post it to my Obsidian weekly notes") and get back a working, deployed, scheduled agent.
The engine behind that meta-capstone is the runtime on this card. When you say "build me an agent for X," you are invoking /build with a goal instead of a blueprint name. The runtime asks its one routing question, you say "draft from the goal," and Claude scaffolds a fresh blueprint on the fly: the folder shape, the README, the compile step, the delivery step. Then the same six steps run.
Put plainly: the meta-capstone is not a different command. It is /build, plus the ability to author a brand-new blueprint inline before executing it. Once you understand the runtime on this card, the meta-capstone stops feeling like a leap and starts feeling like the natural next move.
What changes for you.
The artifact (one slash command in a markdown file) is the easy part. The bigger thing is what shifts in how you approach the next build:
- You stop writing a custom command per build. The first instinct after seeing a working agent is to write a slash command for it. With
/buildon your computer, that instinct gets redirected. The slash command you wanted to write becomes a blueprint folder instead, and the existing runtime handles execution. - You start writing blueprints, not workflows. The unit of work shifts from "a Claude session that builds the thing" to "a folder Claude can read and execute." Blueprints are reusable. Sessions aren't.
- You start trusting the runtime. By the third
/buildsession, you stop reading every line of the Build Plan and start scanning for what's different. The pattern is the same every time, so you focus on what's specific to this build. The runtime carries the rest.
This is the shift from running individual builds to operating a build system. Same command. Different blueprint each time. Same six steps. Different agent at the end.
A worked example.
Here is the canonical invocation, the one that produces the Sunday capstone:
/build morning-brief
What happens, in order:
- Step 1.
/buildnotes the blueprint name, readsblueprints/morning-brief/README.mdandQUICKSTART-4D.md, and (because morning-brief is the Sunday capstone) suggests handing off to/build-morning-brief. You either accept the handoff or tell/buildto run the generic flow anyway. - Step 2. The runtime asks the hard blockers: which sources to enable (Gmail, Calendar, Slack, Obsidian), where the brief should land, which delivery channel sends the ping, and your cost ceiling per run. Three or four questions. Not a wall.
- Step 3. A short Build Plan comes back: the folders to create under
apps/morning-brief/, the compile script, the delivery wiring, how you'll manually test, and what to undo if you want to roll back. You read it and approve. - Step 4. Execution. Folders first. Compile second. Delivery third. Manual test fourth. The runtime pauses between each one and waits for your confirmation.
- Step 5. Verification: the brief file exists, you can open it, the ping fired, no real keys are in plaintext, and you know the single command to run it again.
- Step 6.
/buildasks if you want to log the architecture decision. Say yes. The next time you point/buildat a similar problem, it can search what already worked.
Now swap the blueprint name. /build grow-room-monitor runs the same six steps against a different folder and produces a different agent. /build youtube-cairns runs the same six steps and produces another. The runtime is constant. The blueprint is the variable.
Where to go next.
Three natural moves from here: see the canonical blueprint walkthrough, see the meta-capstone the runtime unlocks, or back up a layer and re-read the slash-command primer that frames every command in the workshop.