Level 7 Capstone
Design your first real loop end-to-end - with an interactive helper that builds your loop spec and STATE.md as you go
Stop Prompting. Start Designing.
Across nine lessons you learned the whole stack: when a loop is worth building, the five building blocks, the memory file, the minimum viable loop, and every way loops fail quietly. This capstone turns that knowledge into one concrete artifact - a real, build-ready design for a loop you could run.
You do not need to write any code to pass this capstone. The goal is to designa loop correctly - because in loop engineering, the design is the engineering.
Your Mission
Take the candidate task you have been carrying since Lesson 56 and produce a complete loop design for it. A passing submission has five parts:
1. THE TEST - show your task passes the 4-condition test
(and name the gate that proves "done")
2. THE SKILL - a one-page SKILL.md: how to think, where to
look, and a "never do" list
3. THE LOOP - the Minimum Viable Loop: automation + skill +
state file + gate, with the build order
4. THE SAFETY - your red-team notes: how it could fail quietly
(Ralph Wiggum, drift, leaks) and the defense for each
5. THE METRIC - how you'll measure Cost per Accepted Change,
and your stop-the-loop threshold (e.g. <50% accepted)🏆 Capstone Project Helper
Use the interactive helper below to build parts 1, 3, and the spine of your loop. Tick the 4-condition test, pick a starter pattern (or go custom), fill in the fields, and it generates a ready-to-use loop-spec.md and STATE.md you can copy straight into your project. Everything updates live as you type.
loop-spec.md is your design on a page - hand it to a teammate and they'd understand your loop in one read. The STATE.md is the starting memory file you drop in your repo root. Together they're two of the five required parts, done.Finish the Other Three Parts
Expand the SKILL.md you drafted: how to think about the task, where to look / fix patterns, and a "never do" list of at least three hard rules.
Write one way your loop could declare "done" while failing, one rule that could drift, and one permission risk - each with its single defense.
State how you'll track Cost per Accepted Change and the acceptance rate at which you'd turn the loop off. If you can't measure acceptance, say how you'll start.
What "Great" Looks Like
- Picks a genuinely small, repetitive, machine-checkable task - not "rewrite our app."
- Has a gate that is an objective check (a real test/build), not "an agent reviews it."
- Separates maker from checker, and has a hard cap plus a human approval before merge.
- Is honest about where it is in the build order - most good answers are still at "make it work manually."
- Treats the loop as a multiplier on the engineer's judgment, not a replacement for it.
What You Have Learned in Level 7
- L56 - From prompter to loop designer; agent = model + scaffolding + loop
- L57 - The 4-condition test; when NOT to build a loop
- L58 - Automations (the heartbeat) + worktrees (parallel without chaos)
- L59 - Skills: write project knowledge down once
- L60 - Connectors: let the loop touch your real tools
- L61 - Sub-agents: separate the maker from the checker
- L62 - The state file: memory that outlives the chat
- L63 - The Minimum Viable Loop and Cost per Accepted Change
- L64 - When loops go wrong: quiet failures, comprehension debt, security
Build the loop. Stay the engineer.
🧠 Check your understanding
5 quick questions on Level 7. Answer each, then check your score.
How was Level 7?
Your feedback helps improve this course. Takes 30 seconds.