loop-design
Skill0 starsChanged 5 months agoMITView on GitHub
Frame work as a self-correcting loop (objective, metric, boundary) instead of a one-off prompt. Use this at the START of any new session, chat, project, or task — especially when the user is scoping, planning, automating, or asking for output that will be iterated, repeated, or produced at scale (drafts, content, code, research, analysis, deliverables, workflows). Trigger this whenever the user describes a goal and wants Claude to keep working toward it, even if they never say the word "loop." Default to proposing a loop before grinding through the task by hand.
6 other projects use a version of this.
Adopted by
Most recently taken up by
- davisbuilds/dojotheir own version, first seen Nov 1, 2026
- manastalukdar/ai-devstudiotheir own version, first seen Oct 13, 2026
- HHU3637kr/skillstheir own version, first seen Sep 22, 2026
- Jaeyong-Cho/skillstheir own version, first seen Aug 20, 2026
- patr-coder/robobuilder-protheir own version, first seen Jul 3, 2026
- kymostudio/kymostudiotheir own version, first seen Jun 24, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- HHU3637kr/skills★ 146same name
- kymostudio/kymostudio★ 9same name
- Jaeyong-Cho/skills★ 1same name
- manastalukdar/ai-devstudio★ 1same name
- davisbuilds/dojo★ 0same name
- patr-coder/robobuilder-pro★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repositoryOne other file it gives its agents.
- persona-valueSkill
The file
We split this skill into the rules it gives an agent
3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 5 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 33
Every loop needs exactly three things.
- Distinctive: line 67
When a user opens a task that is iterative, repeated, scoped, or quality- sensitive, don't immediately produce a single best-effort pass.
- Distinctive: line 76
Keep it short. If the user has already given enough to infer all three, state your assumptions inline and just run the loop rather than …
“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Loop Design
Why this exists
Most people use AI by hand-cranking prompts: ask, read the answer, decide what's next, ask again. That keeps a human in the driver's seat for every turn and caps output quality at "whatever I had patience to refine."
Power users have moved past this. Instead of prompting each step, they design a loop: a small machine that generates its own prompts, judges its own work, and keeps going toward a goal until it hits a stopping point. The human's job shifts from executing the task to designing the loop. The keystroke work disappears; the judgment work stays.
This skill exists so that, at the start of any non-trivial task, Claude proposes and runs a loop rather than silently producing a single pass.
The three ingredients
Every loop needs exactly three things. If any one is missing, the loop can't run itself.
- Objective — what "done well" looks like, stated in one sentence. This is a definition of quality, not a description of the task. "Summarize the call" is a task; "a summary a busy exec could act on in 30 seconds without the recording" is an objective.
- Metric — how the system itself can tell whether a pass came out better or worse, without a human reading every word. This is the hard part and the highest-leverage one. If you can't yet say how a pass would be scored, you've found the real work — see "Defining a good metric" below.
- Boundary — how far the loop runs on its own before it stops and checks in. This is where the user's risk tolerance and values live: how many passes, what it may do unattended, and what must pause for human approval.
Get these three right and the loop asks, scores itself against the metric, adjusts, and repeats — no babysitting per turn.
Runs vs. learns: the feedback wire
- A loop that runs does the same thing today it did yesterday. That's automation. Useful, but flat.
- A loop that learns captures whether each pass landed and feeds that signal back into what it does next. That compounds — it gets better every cycle.
The difference is usually one small addition: a feedback wire. A score that gets logged. An up/down signal. A "winning examples" file that the next run reads first. Whenever you design a loop, ask: what is the one signal that, if captured and fed back, would make this loop smarter over time? Add it.
How to apply this at the start of a session
When a user opens a task that is iterative, repeated, scoped, or quality- sensitive, don't immediately produce a single best-effort pass. First, briefly frame the loop:
"Let's run this as a loop. Objective: <one sentence>. I'll score each pass on <metric>, rewrite anything below bar, take up to <N> passes, then show you the top <K>. Sound right, or want to adjust the metric or boundary?"
Keep it short. If the user has already given enough to infer all three, state your assumptions inline and just run the loop rather than interrogating them. Then actually execute it: generate, self-score against the metric, critique sub-bar passes, rewrite, and stop at the boundary — surfacing the winners and the scores, not every intermediate draft.
Defining a good metric (the hard part)
A metric is good when it's specific enough that two different passes get clearly different scores. Vague metrics ("make it good") can't drive a loop. Pick the cheapest signal that genuinely tracks quality for the domain:
- Code — objective and free: tests pass/fail, type checks, linters, build success, benchmark numbers. Exit codes are the metric; no reading required.
- Writing / content — a self-scoring rubric, e.g. 1–10 on: does the opening earn attention, is there exactly one core idea, would the intended reader learn something, is it within length. Rewrite anything below a 9.
- Research / analysis — a coverage checklist: are all sub-questions answered, are claims sourced, are counter-arguments represented, are numbers internally consistent.
- Design / UI — a heuristic checklist plus, where possible, a rendered screenshot the loop can inspect against the spec.
- Go-to-market / marketing content — score each asset on whether it connects a defined buyer persona to a specific value driver (not a generic benefit). A persona-to-value-driver rubric like the Persona-Value Matrix works well as a reusable scoring engine here, because the same rubric judges blog posts, landing pages, ads, and sequences. (Reference: The Persona-Value Matrix.)
The best metric is one the loop can evaluate itself. The second best is one a human can check in seconds. Avoid metrics that need a full read of every pass — that just reinstates the hand-cranking you're trying to escape.
Where the human stays in the loop
Designing loops doesn't free you to do nothing — it moves your effort to the decisions only you can make:
- The objective forces you to define what "good" actually means.
- The metric is a judgment call about what's worth optimizing.
- The boundary encodes your risk tolerance and values.
So the loop should pause and hand control back to the human at exactly the points the boundary names: before anything ships externally, before irreversible or costly actions, and whenever a pass scores low for reasons the metric can't explain. Surface the why, not just the result.
The loop template (copy-paste)
Objective: <what done well looks like, one sentence>. After each pass, score 1–10 against: <your metric>. For anything below 9, critique it specifically, then rewrite. Take up to <N> passes, then show me only the top <K>. Capture <the one feedback signal> so the next run starts smarter. [Attach 2–4 examples of the result you want — examples beat description.]
Quick start: turn any task into a loop
For a task the user already does with AI (drafting, summarizing, prepping, generating), help them answer three questions — that is the loop:
- Objective — what does "done well" look like in one sentence?
- Metric — how would the system know a pass got better or worse, without you reading every word? (If you can't answer this, that's the real work — solve it first.)
- Boundary — what can it do without you, and where must it stop and check in?
Answer those three and you've designed a loop. Add a feedback wire and you've designed one that learns.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

