When a friend or colleague shows me how they use Claude Code, I usually see the same thing. Claude does a few steps, stops, and waits. They type continue. It does a bit more and stops again. The tool is doing the work, and the person is doing the looping. I did exactly this for months. When I finally counted, I had kept the work moving by hand 284 times in 60 days.
This series is for them, and for you if you have Claude Code and suspect you're using a fraction of it. I start here because it's the change people notice the same day: 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,
- point all three at the tools you already use, like your analytics, error tracking, tracker, Slack and ad accounts,
- and spot the trap that makes a finished-looking job wrong.
This is the first of six posts on getting more out of Claude Code. The others cover giving it a team of agents, setting up work that repeats every week, teaching it your job once with skills, putting it on a schedule, and sharing one tracker with your agents.
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.
The finish line doesn't have to live in a file on your laptop. With a connected tool, it can sit in your analytics, your tracker or your ad account. Say people sign up for your app and never finish onboarding. With your product analytics connected (PostHog, in this example), the same shape becomes:
/goal Using the PostHog connection, pull the last 14 days of the
onboarding funnel from <first step> to <last step>. Write funnel.md with
each step's count and drop-off, the step that loses the most people,
and three error events or session recordings from that step as
evidence. Show the step counts here. Don't change anything in PostHog.
Stop after 8 turns if unfinished and tell me what's missing.
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.
A release is the other slow thing worth watching. The first hours after an app update are when a new crash hurts most, and when you're least likely to be looking:
/loop Every 15 minutes for the next 2 hours, check PostHog error
tracking for issues first seen in version <version>. If a new issue
affects more than <N> users, tell me the error, how many people hit
it, and on which screen, then keep watching. At the end, give me a
one-paragraph summary and stop this loop.
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.
Once a read-only routine has given you a couple of weeks of summaries you trust, let it do the next step itself. The best candidate is the morning check most app teams do by hand: what broke overnight, and did fewer people get through onboarding. A routine can run that check before you wake up, fix what it clearly can, and leave everything else as a ticket:
/schedule Every weekday at 8:00 <your timezone>, using the PostHog,
Linear and Slack connections and the <repository>:
1. List error-tracking issues from the last 24 hours that affect more
than <N> users, and compare the onboarding funnel with the same
day last week.
2. For each error whose cause you can point to in the code, fix it on
a new branch, run the tests, and open a draft pull request that
links the error. Never merge, never deploy.
3. For each error you can't explain, and any onboarding step that
dropped more than <X> points, create a Linear issue with the
evidence. First check that an open issue for it doesn't exist.
4. Post a five-line summary to <Slack channel>: new errors, draft pull
requests, new issues, funnel change, anything you couldn't reach.
Three details carry most of the weight. The pull requests are drafts, so a person still reads every change before it ships. The "check first" line keeps a daily job from opening the same issue every morning, which is the most common way these routines turn into noise. And the Slack summary includes what it couldn't reach, because a missing connection otherwise looks exactly like a quiet night.
The same shape works outside code. A Monday routine can read last week's spend and results from your ad accounts, compare the cost per result with your target, and post suggested changes to Slack. The routine never touches a budget. You change it after reading the suggestions.
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, skills that learn, routines, and headless project management.