Lesson 4.1 ended by telling you where your first loop comes from: a check you already run every morning by hand. So you have a candidate.
This lesson is the deliverable, and it comes down to three decisions you can finish today:
- Which check, tested against one question from Module 3.
- The template, Module 1's six slots, filled in for that check.
- The rung you can evidence, which is lower than the one you want.
Step one: which check
You probably have three or four morning checks. Put each through one question: can a machine tell you it's done?
| The morning check | Can a machine tell you it's done? | Verdict |
|---|---|---|
| Last night's new error signatures | Yes. Each signature either has an issue filed against it or it doesn't. Nothing needs an opinion. | a loop |
| Does the staging page still look right? | No. A score is a model's opinion about a screenshot, and no run turns it into evidence. | a loop with a permanent gate |
| Is anyone blocked in the team channel? | There is no mechanical condition anywhere in that sentence. | not a loop; a habit |
The staging-page check is the UI scoring pattern from Lesson 4.1, and you saw there where a score stops.
Pick the one that survives the question. If two survive, pick the one you'd most resent doing again tomorrow morning. That second rule is a judgment, not a mechanism, but it's the one that decides whether you are still running this thing in a month.
Step two: into the template
Here are the same six slots from Lesson 1.2, pointed at a loop this course never built: checking new error signatures after a deploy.
When the deploy finishes, inspect signatures new since the last deploy. Take one bounded action. Check each has an issue, a stack trace and a suspect commit the same way every time. Stop on success; stop at 8 iterations; stop at $2 a run; stop and ask on the same signature unattributed, twice.
| Slot | Value |
|---|---|
| Trigger | the deploy finishes |
| Fresh input | signatures new since the last deploy |
| One bounded action | one edit and one check, not a plan |
| Mechanical condition | each signature has an issue, a stack trace and a suspect commit |
| Iteration cap | 8 iterations, hook-enforced |
| Budget | $2 a run, prose only |
| No progress | the same signature unattributed, twice; then it stops and asks |
The two stops are not the same kind of thing.
8 iterations is hook-enforced, by the PreToolUse hook you already wrote in
Module 1. Change the number, keep the hook. It fires before any permission check
and can't be argued past.
$2 a run is prose only. It sits inside the prompt text, and no hook is ever handed a cost figure: the hook payload carries no cost field. Write it anyway, and know which one is a wish. That is narrower than "budgets are unenforceable": something outside this hook may well hold your budget. It just isn't this one.
The "no progress" rule is defined before the first run, as in Lesson 1.2.
A template that only fits its own example is not a template. This is the blank form you are being handed, and this filling of it is a loop the course never built.
Step three: the rung you start on
You're going to want to skip a rung. Don't. Your loop starts on rung one, Manual: you type it, and you watch every turn.
That's not because your loop is weak. It's the rule from Lesson 3.3:
The rung you're on is the one you have evidence for, not the one the tooling can reach.
On day one you have no runs, so you have no evidence, so there is no rung above the first one.
So decide the number now: how many clean runs, where the checker's evidence and your own reading agreed, buy rung two (Triage)? Lesson 3.3 priced rung three to four at twenty runs, and said plainly that the number was a personal one. This blank is yours. Pick it while the loop is still interesting, not in week three, when reading diffs has become the chore the loop was supposed to remove.
And write the teardown line today, in the same file as the goal:
/goal clear → delete the task by id → CLAUDE_CODE_DISABLE_CRON=1Then read the listing back, and don't treat it as proof. An empty task listing was never proof that a loop stopped.
Today: one page
Three things, on one page, today:
| What to write down | |
|---|---|
| The line | your /goal, all six slots filled, in a file you will find again |
| The rung | Manual, and the number of clean runs that buys the next one |
| The stop | the teardown, written before the first run, not after the first surprise |
After this lesson
You will be able to:
- pick your first loop from a check you already run by hand, by asking whether a machine can tell you it's done;
- fill in the six-slot
/goaltemplate for it, and say which stop is hook-enforced and which is prose only; - start it on rung one, and set the number of clean runs that buys rung two;
- write its teardown before its first run.
Where to go from here
That's the course. One loop, designed, wired to four primitives, verified by something that wasn't the maker, and stopped on purpose. It was built slowly, end to end, so that this one page costs you an afternoon instead of a quarter.
Go and pick the check. I'd rather you shipped a boring loop this week than designed a clever one for a month. The clever one doesn't get built. The boring one is running by Friday.
Companion article
Every hook, script, and command in this course, written up and executed: How to build an agent loop in Claude Code