The to-do list has been the bane of my existence for as long as I can remember

High school. University. Every job since. Some version of a list, written out again each time, doing the same work of remembering that I did last week.

I do not use them for work anymore. And for the last week I have been explaining why I do not write skills either — I have not created one since around January, and I do not even look at them. What replaced both is the thing I want to walk you through here.

Here is what it looks like in practice. I published a video yesterday. It is seventeen hours old. It is already a tutorial on my site, with a community announcement underneath it, plus social posts, an email and follow-up messages waiting as drafts.

I did not write a prompt for any of that. I did not paste anything anywhere. I said one sentence: repurpose my YouTube video.

Where this sits in the story so far

Two years ago everything was prompt engineering. How do I phrase the question better.

The last eight to twelve months were context engineering. How do I make sure the model has the memory and the information it needs, so I stop repeating myself.

What is arriving now has a technical name — graph engineering. I have been calling it a playbook for a year, because that is the business word for it.

And a graph is a much smaller idea than the name suggests. Here is a task. Here is another task. They are connected with an arrow. That is a graph. A to-do list is one task. Several tasks tied together with arrows is a graph. That is genuinely the whole concept.

The five conditions — is this job even ready?

Not everything should be a playbook. Before you build one, it has to meet five conditions.

1. You have done it by hand, many times. This is not “I woke up and have seven things to do today.” It has to be something repetitive, something you have already done manually enough times to know its shape. I have around 700 YouTube videos and I have turned 338 of them into tutorials by hand before this existed. That is what earns a playbook.

2. It crosses more than one part of your business. This is the one people get wrong. A playbook is not a checklist or a standard operating procedure for a single AI employee. It is about work that gets produced in one department and handed to another. If it never leaves one desk, you do not need a graph — you need a good employee.

3. There is something measurable at the end. Not “create better content.” For me it is not even “create a tutorial” — it is repurpose my YouTube video, and the finish line is a published tutorial with a URL that meets a standard. Something you can point at and say that is done, or that is not.

4. There is a place where you say yes. Somewhere in the run you need a gate. In mine, the social posts and the email announcement are produced as drafts. Nothing sends until I say so. Multiple departments doing work is fine; you still need to know where you are in the loop.

5. You are allowed to break it. This is the one most people forget, and it is the one that stops people starting. It will not run properly at the beginning. You have to be comfortable breaking things while you learn how the model works, what belongs in each department, and what has to be handed to the next one.

The seven steps to build one

Step 1 — Notice it. Do not design it. I did not sit down and architect a repurposing pipeline. I noticed I was downloading a transcript, then working out what the tutorial was about, then writing the tutorial, then writing an announcement. Same order, every time. I noticed a shape I was already living in.

Step 2 — Write down the steps in the order you actually do them. Order is not decoration. You cannot do the announcement without the tutorial. You cannot write the tutorial without the transcript. You cannot write the email without a link to the tutorial. The sequence is real and it constrains everything.

Step 3 — Name what each step has to hand over. Not what the step does — what it produces that the next one cannot start without. The tutorial produces a URL. The email needs that URL to link back. The social posts need the same URL and the content brief the tutorial was built from.

Step 4 — Write a checkable line for each step. One thing that has to be true before the work moves on. This is your guard rail: it stops step five running on a broken step four. Pass or fail, not opinion. And if two steps run side by side rather than one after the other, this is what keeps them talking about the same thing.

Step 5 — Put yourself in it deliberately. Decide where you want to be asked. Mine is at the things that reach other people — social and email stay as drafts. Some of the other gates I have since removed, because I watched them run correctly a few times and stopped needing to look.

Step 6 — Let it be bad. Seven hundred videos in, things still break. That is fine. What you want is for it to tell you: we had a problem here, it did not work properly, here is where. You get notified, you fix it, you carry on. Think of a real employee handed a procedure — there are always circumstances where they cannot do the job, so they come back and say we are stuck.

And here is the important half of that: when it breaks, you are not changing the outcome you wanted. You are fixing the contract between the departments. Do not throw away the thing you asked for because the first attempt failed. Work out how the handoff should have gone — and by “work out” I mean ask Claude to work it out. It is far better than you are at spotting what is wrong, and it has time you do not.

Step 7 — Collapse it into one sentence. The finished playbook should be triggerable by a single instruction. Mine is repurpose my YouTube video from yesterday. That sentence is the whole point of the exercise.

The common mistake this prevents

Designing the graph before you have lived it.

It is tempting, because designing is more fun than noticing. But a playbook you invented is a guess about how work flows through your business, and a playbook you noticed is a description of how it actually does. The first one will be wrong in ways you cannot see until it runs. The second one is already true — you are only writing it down.

If you cannot point at ten times you have done this by hand, you are not ready to graph it. Go and do it by hand.

Do this now

Get a blank piece of paper.

Write down one job you used to keep a to-do list for. Then write down the department that job gets handed to next. Mine: a YouTube video goes to the teaching department to become a tutorial, then to community for the announcement, then to marketing for social and email, and there is a further step in sales for following up on anything that comes back.

Draw a box around each one. Draw a line between them. That is your first graph.

Then the only question that matters: if the first box were finished, what exactly would it have to hand the second one? Write that down. Not the list of tasks inside each box — the thing that has to cross the gap between them.

If you can do three departments instead of two, do three.

What this looks like once it is running

I have seven of these active in my own business right now. A morning brief. A community morning pass and a community evening pass. A platform watch. The video library that turns YouTube videos into tutorials. A content marketing flywheel. An outbound lead generation system that runs continuously. And a weekly roundup.

None of them is clever. Each one is just AI employees in different departments, arrows between them, and an outcome at the end.

Recap

• A graph is tasks with arrows between them. That is the whole concept.
• Five conditions: done by hand repeatedly, crosses departments, measurable outcome, a place you say yes, and permission to break it.
• Notice the playbook you are already living in — do not design one from scratch.
• Every step needs a named handover and one checkable line before the next step runs.
• When it breaks, fix the contract between the steps. Never abandon the outcome.
• You are finished when the whole thing runs off one sentence.

I am betting you already have departments in your business, even if you have never named them. The Campus AI OS is free, installs as folders and files on your own machine, and arrives with six departments and playbooks already built in — so you can watch one run before you write your own.