The job was never “write a skill”. It was “staff a department”.

Lead generation was the thinnest department on my campus. Two employees, and one of them had exactly one recorded run. Anyone who replied to an email, asked a question, or went quiet after a call was falling straight through the cracks, because nobody was staffed to catch them.

So I did the build live, on camera, with no idea whether it would work. And the thing I want you to notice is what I actually did during that hour. I did not write a skill. I did not write a prompt. I did not open a code editor or a terminal. I answered four questions.

That is the whole shift. You stop being the person who assembles the parts, and you start being the person who approves the direction.

What a playbook is, in plain language

A playbook is a set of jobs with arrows between them. Job one hands something to job two. Job two cannot start until job one has produced the thing it needs. The technical world has started calling this graph engineering. I have been calling it a playbook for a year, because that is what it is.

It is worth knowing where this sits. Two years ago the skill was prompt engineering — asking a better question. The last year was context engineering — giving the model better information so it stopped guessing. What is happening now is the layer above both: designing the shape of the work so the same model is not doing the research, writing the answer, and grading its own homework inside one giant chat.

The playbook I ran here is called staff a department. It has seven stages. Every stage has a job, an output, and a line that has to be true before the next stage is allowed to start.

The seven stages, and what each one actually did

1. Demand evidence. Before building anything, prove the gap is real. It came back with the honest version: lead generation is the thinnest department on the campus, one of its two teams has exactly one recorded run, and there are six inbound replies sitting unanswered from yesterday.
2. Kill gate. A separate check that asks whether this should be built at all. It can come back “no, do not bother”. This one came back go.
3. Build. The team gets assembled — in this case a follow-up team with four workers: draft a reply, triage replies, plan a follow-up cadence, and reactivate past buyers.
4. Validate. All required fields present, nothing malformed.
5. Cold install. Install the thing by itself, on a clean campus, as if you were a customer who had never seen it. This is the stage that catches what your own machine hides.
6. Listing. Write the shopping cart entry. I stopped this one. More on that below.
7. Roster and org chart. Update the record of who works here, so the department knows it has a new employee.

Threading through all seven is a single run ID. That ID is the contract. It is what lets stage six know what stage three produced, and it is what lets the reporting layer, later, read back what the whole run actually shipped.

The four places I said yes — and the one where I said stop

This is the part worth copying.

Gate one: where does a team live? I have a group of scout agents — research specialists that go find things. It asked whether to move them into lead generation. I deferred. They already do work in more than one department, and a filing decision made in a hurry is a filing decision you undo later.

Gate two: a three-way choice I did not understand. It offered me three options and I could not tell what they meant for me. So I asked, in plain words: which do you suggest, and will any of these break the other playbooks or departments I already have? That second half is the important one. I do not want a clean answer to today’s question that quietly breaks last month’s work.

Gate three: write the cart listing. I said stop. Option three would have created a storefront for a single department. But I had changed my offer structure the week before — I now sell the whole staffed campus, not departments one at a time. Building that listing would have quietly reopened a menu I had deliberately closed. It flagged the blast radius before touching anything, which is exactly why the gate exists.

Gate four: repackage now, or test first? Near the end it found a real problem: the new team had a front door but no back door. It could receive work but never wrote a record of what it produced, so the reporting layer would never see it. It gave me two choices — test what we have and come back, or give it fifteen minutes to fix and repackage. I said repackage. Testing something you already know is half-finished is a waste of a test.

Three things it caught that I would have missed

It found an employee I already had. Late in the build I asked whether we could reuse the email writer that already lives in my copy team. The answer was careful: the broadcast email writer and a one-to-one reply are genuinely different jobs, so keep the new one — but the orchestrator’s own description never mentioned the copy team at all, so a request for outbound email would land wherever the wording happened to match. One line fixing that boundary was worth more than any code sharing.

Honestly, it should have checked the register of existing employees before it started building. That is a real miss and it is on the list.

It caught its own overrun. There is a limit on how long a plugin’s description can be. It wrote the team, checked its own work, found the section was over the cap, trimmed it, and pushed the detail into a reference file. Nobody asked it to.

It flagged two new employees it thinks I need. The campus logs every request I make and watches for patterns. I had asked for a one-page plan enough times that it noticed there is no employee good at that, and proposed hiring one. That is the loop working: the work you keep doing by hand becomes the next job description.

The common mistake this prevents

Believing the playbook is supposed to run clean.

It did not run clean. It hit an error four plugins deep. It found seven issues, two of which were mine. It got a sign-off wrong three times, each one slightly ahead of the evidence, and said so.

That is not the playbook failing. That is the playbook doing the one thing a checklist in your head can never do — telling you where it is unsure and stopping to ask. If you are waiting until yours runs perfectly before you trust it, you will wait forever. Build it, break it, and fix the contract between the steps rather than the outcome you wanted.

Do this now

Take a blank piece of paper. Write down one job you keep doing by hand. Then write down the next thing that happens to it — the part that gets handed to a different part of your business. Draw a box around each and an arrow between them.

That is your first graph. Now answer three questions about it: what has to be handed over for the second box to start, what has to be true before it is allowed to start, and where do you want to be asked before it goes any further.

Those three answers are the difference between a to-do list and a playbook.

Recap

• A playbook is jobs with arrows, a required output at each step, and a run ID threading the whole thing together.
• Your job during a run is not building. It is holding the gates.
• The best gate question is “will this break anything I already have?”
• Cold install on a clean campus is what catches the defects your own machine hides.
• Expect it to break. Fix the contract between the steps, not the outcome you asked for.

The Campus AI OS is free, and it installs as folders and markdown files on your own hard drive — nothing goes to someone else’s cloud. It ships with six departments and playbooks already built in, so you can watch one run before you write your own.