I wrote this series because I kept seeing the same thing. Smart people around me, colleagues, friends, founders, had Claude Code installed and used it like a chat window: ask, copy the answer, ask again. They were getting a fraction of what it can do, and the missing piece was never skill. Nobody had shown them the rest. The first thing I show them is how to stop babysitting it.
You probably know the pattern. Claude does a few steps, stops, and waits. You type continue. It does a bit more and stops again. I once counted my own: 284 times in 60 days, I was the thing keeping the work moving. You can hand that job to Claude. Tell it what done looks like in a form it has to prove, and it keeps working, checks the actual result, and then finishes, keeps going, or stops to ask you one clear question. Setting that up on purpose is what I call loop engineering, and none of it needs code.
By the end of this post you can:
- give Claude a finish line with
/goaland let it work until it can show the result, - have it watch something slow and tell you when it's done,
- put a weekly chore on a schedule that runs without you,
- and spot the trap that makes a finished-looking job wrong.
This is the first of four posts on getting more out of Claude Code. The others cover giving it a team of agents, setting up work that repeats every week, and teaching it your job once with skills.
What a loop needs
Every loop that finishes has the same five parts: a finish line, an action, a check, a note of what happened, and a rule for what comes next. Most people only ever write the action ("fix this", "write that") and leave the rest to luck.
Look at the third way out. "Blocked, ask a human" is a good outcome. A research loop I ran once worked through a full pass of data, then stopped on purpose and handed me a one-line question instead of guessing its way into a second, more expensive pass. A loop that asks when it runs out of safe guesses is doing its job. A loop without that exit either runs forever or quietly makes something up.
Loop one: give it a finish line
Claude Code has this built in. Type /goal followed by the condition you want, and after every turn a small, fast model checks whether the condition is met. If it isn't, Claude starts the next turn by itself, so you stop typing continue. It stops when the condition is met, when it's judged impossible, or when you type /goal clear. Your usual permission prompts still apply, so it may pause to ask before running something; /goal doesn't grant new permissions.
One thing to know: the checker only reads the conversation. It doesn't open files itself. So write the condition as something Claude has to show on screen, like counts, a list of what's missing, or a test result, and give it an upper limit. A good first one, with a small export of tickets or requests saved in your folder as tickets.csv:
/goal Write triage.md with one entry per row in tickets.csv: the ticket
ID, a suggested next action, and anything missing. Show the input and
output row counts and list any IDs you skipped. Don't change
tickets.csv. Stop after 10 turns if unfinished and tell me what's left.
For bigger jobs, where you want to see the plan first, ask for a checklist with the proof for each item before any work starts:
Task: <what you want done>. Inputs: <files or links>. Output: <where it
goes and in what format>. Before doing anything, write a checklist
where every item names the proof that it's done: a file, a count, a
command's output, a screenshot. Show me the checklist and wait for my
OK. Then work through it, record the proof for each item, and tell me
anything that's blocked.
Name the items after what happened, not after what you built. "Every open email has a drafted reply" is checked when the replies exist. "Build the reply drafter" is checked the moment the drafter exists, which is much earlier, and that's how half a job gets marked finished.
The trap here is a check that only looks like the real thing. A small online store I help runs a tool that drafts answers to customer questions from a marketplace. Its first real run showed a couple of dozen questions as pending, and only two could actually be answered. The rest had been closed by the marketplace days earlier, and the tool's count of "pending" was an old copy nobody had checked against the source. Coding has the same trap: I once watched a test run report success twice while it had run zero tests, because the success signal came from the wrong place. Whatever you check, check the thing itself, not a number that's supposed to reflect it.
Loop two: let it watch something slow
Some work isn't waiting on Claude. It's waiting on an export, a report, a deploy, an email. /loop handles that inside your session. Give it an interval and a prompt and it repeats on that schedule; give it only a prompt and Claude picks the wait itself, shorter while things are moving and longer when they're quiet. Your session has to stay open, press Esc to stop a self-paced loop, and you can ask "what scheduled tasks do I have?" to see and cancel the rest.
/loop Check <the status page, file, or folder to watch>. Done means
<the exact status or result>. At the first check, note the time. Check
every few minutes, faster when it's close, and never wait past 30
minutes from that first check. When it's done, or the 30 minutes are
up, tell me the latest status and stop this loop.
Treat the 30 minutes as a request to Claude, not an exact timer. The best version of this I've seen was a domain move that had to wait for the new address to spread across the internet. The loop checked once an hour and said "not yet" until it was ready. Then it ran the rest of the move itself and deleted its own hourly check as the last step.
The trap here is waiting on something nobody is watching. In one of my runs, several helper agents started a slow job in the background, ended their turn expecting to be told when it finished, and never heard back. The fix was one sentence in their instructions: whoever starts a background job collects its result before stopping. If you start something slow, say who checks on it.
Loop three: run a weekly chore without you
For work that comes back every week, /schedule creates a routine: a Claude Code session that runs in the cloud on a schedule, even with your laptop closed. It's available on paid plans and still marked as a preview. Because it runs in the cloud, it can't see files on your laptop. It reaches your tracker only through a connected tool (Google Drive, Notion, Linear and the like) or a repository you give it. It also runs without asking permission, so start with a job that only reads and writes a draft:
/schedule Every Monday at 9:00 <your timezone>, read <the tracker or
document link> through <the connected tool>. Write a short summary: what
is overdue, what is due before next Monday, with links. Don't change
the tracker and don't send messages. If you can't reach it, say what
access is missing.
After it's saved, open the routine, check that its connections are there, press Run now once, and read the result. A green checkmark on a run only means the session ran; open it and check the summary against the tracker yourself.
Check the whole chain
Even a loop that checks the real result at every step can miss the thing that matters. A feature I worked on had six separate systems, each checked and working: store setup, billing, dashboards, analytics, the server, both apps. The feature still did nothing, because the link that was supposed to open it was never wired to anything. Six green checks proved six parts worked. None of them proved the parts were connected.
So before you call a multi-step job done, run one real example through the whole thing from start to finish, and look at what comes out the other end.
Your setup, ready this week
You don't need all three loops at once. Start where your week already hurts:
You're done when a run gives you the result you expected and you know how to stop it. I went into this expecting the problem to be loops that never stop. The one I keep running into is loops that stop politely without the one thing they were asked for, which is why the finish line matters more than anything else in this post.
The rest of this series: graph engineering, loops and graphs, and skills that learn.