loop-design-check

原文涵盖的主题

• 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

这里只展示节选，请以完整原文和当前要求为准。