loop-design-check

Topics in the source

• Loop Design + Review
• When to use / not
• Red-line premise: two levels of feedback
• Action 1 — Write a loop (5 steps)
• Step 0 · Subtract first: should you even build it? (4-condition gate, any miss = veto)
• Step 1 · Define a machine-decidable goal (the hard part — the loop lives or dies here)
• Step 2 · Pick the loop type
• Step 3 · Pick a skeleton

Premise. An LLM is a feed-forward system: prompt in → tokens out, with no built-in "steer toward the goal" across turns. To make it behave like a goal-oriented system, you wrap a feedback loop around it. This skill helps you write that loop correctly and review it so it won't run away. Use it when: You want to hand a repeating task to an agent that runs over and over (write→test, test→fix, fix→verify…). You already have a loop and worry it spins, cheats, or runs a wrong answer to completion. Don't use it for: A one-off task → just do it; don't wrap a loop around it. A plain timer / poll → use /loop; no design needed. How to wire the loop architecture (pipelines → DAGs, long-run recovery) → that's the mechanism layer; see autonomous-loops / continuous-agent-loop. This skill only covers "is the goal right, and will it run away" — it does not re-explain mechanism. | Level | Who owns it | What it does | |---|---|---| | Execution (low) | machine / agent | Measures "how far from the literal goal" and grinds it to zero. The machine is strong here. | | Judgment (high) | human | Decides "is this goal itself right, should it change, should it stop." The machine can't step outside its own loo

This is an excerpt. Refer to the complete source and its current requirements.