Run the
operation.
Systems that run without you.
Work you can trust at scale.
A team that can do it too.
Beginner: use Claude.
Advanced: build the system that uses Claude for you.
Master: run an operation on it and teach your team to do the same.
Finished Level 2? Good. This is the last climb. Back to Level 2.
› 4 Layers refresher
Every strong prompt still has four layers, written in order: Objective (one sentence, the win), Context (the world, who you are, who Claude is), Output (the shape), and Workflow (the steps, when the path matters). Guardrails sit at the bottom, always on. Level 3 does not re-teach this. If it's rusty, read the full breakdown in Beginner · The 4 Layers, then come back. Everything here assumes the framework is automatic by now.
Fewer modules. Bigger stakes.
Seven modules, not fifteen. Not because there's less to learn, because each one is heavier.
Every practice here is a real project, not an exercise. You run it on your actual business, with actual people, and it has to hold.
Scheduled Systems
Build work that runs on a clock without you starting it. A scheduled task is a product feature, described in plain English: what runs, when, what it hands you, where it stops. No code, no cron syntax. You describe the job, the platform runs it.
- Scheduled tasks as product features, described in plain English
- Designing a recurring job: what runs, when, what it hands you, where it stops
- The safety pattern: scheduled jobs draft, they don't send, until trust is earned
- Reviewing what ran while you slept, and schedule vs human trigger
- Set up one real recurring job on your actual work
- Run it for a full week
- Review the quality of every run before trusting it further
A new scheduled job starts at draft only. It runs, it prepares the output, it waits for you. It does not send, post, or commit anything on its own. Only after several clean runs does a job earn the right to act without a review step, and even then only for low-risk work. Never let a brand-new schedule touch anything that leaves your hands unreviewed.
Delegation at Scale
Break big work into parallel streams Claude runs at once, then review the results as one. Think of a subagent as saying "go research these five, report back." Fan out to many streams, fan back in to a single synthesis you review.
- Subagents in plain English: go research these five, report back
- Fan-out and fan-in as one pattern
- When parallel helps (independent work) vs hurts (dependent work)
- Reviewing the synthesis, not every step, to keep your own chat clean
- Run one big job as several parallel streams
- Have Claude synthesize them into one report
- Review only the synthesis, not the raw work behind it
Independent tasks parallelize well: five separate research streams that don't need each other's answers. Dependent tasks don't: if step two needs the result of step one, running them at once just creates confusion. Know which kind of job you have before you fan it out.
Quality Control Systems
Turn your quality bar into something that holds across every output, yours and your team's. You built the bar in Level 2. Now it patrols on its own: a rubric Claude runs on any draft before you ever see it.
- Anti-slop as a standing system, not a one-time pass
- The review rubric Claude runs on any draft before you see it
- Baking QC into skills so it happens automatically
- Auditing a week of outputs and the adversarial read on high-stakes work
- Write a one-page quality rubric
- Turn it into a critique skill
- Run a full week of content through it
Instead of you catching problems after the fact, the rubric catches them before delivery. Every draft passes through the same checklist automatically: hedge words flagged, unsourced claims flagged, the real point buried too far down flagged. High-stakes work still gets a human adversarial read on top. The rubric is the floor, not the ceiling.
Client-Facing Work, Run Safely
Use all of this on live client work without a single "how did that go out" moment. The trust boundary is simple: Claude drafts, a human always signs. Everything else in this module protects that one rule.
- The client trust boundary: Claude drafts, a human always signs
- Data hygiene: client-confidential info never enters memory or a shared Project
- Per-client isolation: separate Projects, no context bleed
- The approval gate on anything leaving your walls, and the near-miss protocol
- Set up one client's isolated workspace with trust rungs
- Add a hard approval gate to it
- Document exactly what is automated and what never is
The moment something almost goes out wrong, stop and write down what happened before you fix it. Which gate should have caught it. Tighten that gate. A near miss is free information about where your system is thin. Treat every one as a required update to your rungs, not a one-off apology.
An agency runs five client accounts. Each client gets its own Project: its own voice, its own knowledge, its own history. Nothing from Client A's Project ever informs Client B's output. Every draft for every client sits behind the same approval gate before it leaves the building. One operator, five separate rooms, zero crossovers.
Confidential client details never get written to shared memory. They live only inside that client's own Project.
A team lead runs content for five newer agents they mentor. Each agent gets an isolated Project holding that agent's own voice and market, never shared with the others. All output is approved before it posts. One operator, five brands, zero crossovers.
Any client-confidential detail from one agent's deals never enters another agent's Project, and never enters shared memory at all.
Claude Code as a Power Tool
Use the most powerful surface to build and run things for you, without writing a line of code. You direct Claude Code. You never author code and you never need to read it. It reads and writes real files and runs what it builds, and it always shows you a plan first.
- What Code gives you that Chat and Cowork don't
- CLAUDE.md as the standing brief, written for real work now
- Plan mode: Claude shows the plan, you approve before it touches anything
- Describe, approve, use, never read the code, and the hard stop boundary
- Point Claude Code at a folder for one real job
- Write the CLAUDE.md briefing it
- Use plan mode to build one internal tool, then use the tool
Claude Code is great for prototypes and internal tools you fully control. The moment a build touches payments, user accounts, authentication, or real customer data, stop. Call a developer. You are the director of this tool, not its engineer, and knowing exactly where to hand off is the whole skill.
Teach Your Team (Rollout)
Take everything you built and make your people able to run it too. Never hand someone autopilot on day one. Walk them up the same trust ladder you climbed. Your skills and Projects are the transfer mechanism: your system becomes their starter kit.
- The teaching sequence: never hand them autopilot first
- Skills and Projects as the transfer mechanism
- The one-page "how we work with Claude here" doc
- Rollout order and measuring adoption
- Run one person through their first three lessons this week
- Use your own kit as their starter kit
- Note exactly where they got stuck
- The 4 Layers first. Nothing else matters until this is automatic.
- Files and research next. Get them comfortable uploading and asking.
- Their first skill. One playbook, built from their own repeated work.
- A Project. Their own workspace, briefed the way you brief yours.
Measure adoption honestly: who actually uses it, where they stall, and what you need to fix in the kit itself, not just in them.
An ops lead rolls the weekly-brief system to two coordinators. Week one: the 4 Layers, on their own real tasks. Week two: files and research. Week three: they build their first skill from something they already repeat. Week four: their own Project, briefed the same way the ops lead's is. Every output stays at draft-plus-approve for the whole first month.
A team lead rolls the Listing Machine Project and the voice skill out to three newer agents. Week one: the 4 Layers and read-versus-write, taught live. Week two: each agent gets their own cloned Project, their own voice, their own market. Week three and four: they hold at draft-plus-approve, every listing and post reviewed before it ships. The mentor's system becomes the team's system.
Master Capstone: Teach Your Downline
Prove mastery by making someone else capable, not just doing more yourself. Pick one person. Take them from zero to running one real workflow. Hand them a starter kit. Teach, don't do it for them. Your leverage is now other people's leverage.
- · Pick one person. Someone who does real work you understand.
- · Hand them a starter kit. Your 4-Layer templates, one skill, one Project, one trust-laddered task.
- · Teach live. Walk them through it in person or on a call. Don't just send a doc and disappear.
- · Hold them at draft-plus-approve for a full month. Review every output with them weekly.
- · Document the rollout. Write down what worked so the next person is easier than this one.
This capstone never fully ends. Every person you bring up the ladder can bring up the next one. That's the difference between using a tool well and running an operation.
A founder onboards their first hire to run the content queue. The hire gets the 4-Layer templates, the content skill, and the content Project, all taught live in one sitting. First month, every piece sits at draft-plus-approve with a Friday review. By month two, routine posts move to spot-check. The founder wrote the rollout down after week one, so the next hire takes half the time.
A team lead onboards a newer agent to run their own listing content. The Listing Machine gets cloned to the newer agent's voice and market. The 4 Layers get taught live, not just documented. First month sits entirely at draft-plus-approve, with a Friday review of everything that shipped. The mentee has turned into an operator, and the mentor has one less thing to carry alone.
New words
Only the terms that are new at this level. Everything from Beginner and Advanced still holds. For the rest, see the full glossary in Level 1.
› Scheduled task
Work that runs on a clock instead of when you ask. Described in plain English: what runs, when, what it hands you. New jobs start as draft-only. They earn the right to act on their own only after proving themselves over several runs.
› Subagent
A separate helper Claude sends to do one piece of a bigger job. "Go research these five, report back" is a subagent instruction. You review the combined result, not each helper's raw work.
› Fan-out / fan-in
The shape of parallel delegation. Fan-out is splitting one job into several independent streams that run at once. Fan-in is bringing all those streams back together into one synthesized result. Works well for independent tasks, poorly for tasks that depend on each other.
› Quality rubric
A written checklist Claude runs against any draft before you see it: hedge words, unsourced claims, a buried lead. Turns your personal quality bar into a standing system instead of a memory you rely on.
› Approval gate
A required stop before anything leaves your walls. Claude drafts, the gate holds it, a human signs off, then it ships. The gate is what makes delegation safe at scale.
› CLAUDE.md (operator's view)
The standing brief for a Claude Code folder, written from the operator's seat, not a developer's. It states who you are, what the tool should do, that a plan comes before any build, and exactly where the hard stop is. You write it in plain English and never touch the code it produces.
› Rollout
The planned sequence for teaching your system to another person: framework first, then files and research, then their first skill, then their own Project, all while holding them at draft-plus-approve. A documented rollout makes the next person easier than the last one.
You've reached the top.
The last capstone never ends: keep teaching. Every person you bring up the ladder can bring the next one up too.