loop-worthiness-test

Source Metadata

Original cangjie-skill frontmatter from the distillation run:

name: loop-worthiness-test
description: |
  判断一个任务是否值得做成 Loop 的四条决策标准。
  当用户在纠结"这件事要不要自动化"、"该不该用 loop"、或"为什么我的 loop 得不偿失"时使用。
  不适用于: 已经决定要做 loop 后的设计阶段、或一次性任务。
  关键 trigger: "这件事值得做 loop 吗"、"该不该自动化"、"loop 成本太高怎么办"。
source_book: "Loop Engineering 视频合集"
source_chapter: 视频3 (小木头引用 Iddo Money) / 视频4
tags: [decision-framework, cost-benefit, automation, checklist]
related_skills: [loop-three-elements, loop-build-path, comprehension-gap]

Loop Applicability Four-Condition Test — Preventing Over-Engineering

R — Reading (Original Text)

"He gave 4 test conditions; only when all 4 are met is doing a loop worth it. First, this work repeats at least weekly... Second, verification can be automated... Third, your token budget has to hold up... Fourth, the agent has the same set of tools a senior engineer has." — 小木头 (Video 3)

"The majority of tasks don't need loops." — Adam Gillock (Video 1)

I — Interpretation (Own Account)

Judging whether a task is worth building a loop system for requires satisfying four conditions at the same time:

High-frequency repetition: The task is done at least once a week. One-off or low-frequency tasks are not worth building a loop system for.
Automatically verifiable: There are tests/Lint/checks that can automatically catch bad results, without needing manual review of every output.
Sufficient token budget: Can bear the cost of repeatedly reading context and trial and error, including wasted tokens.
Complete toolchain: The Agent has logs, a runtime environment, and self-testing capability, and can run code itself to see results.

Only when all four are met is it worth doing a loop. This is a counterintuitive filter — most people see that loops are cool and want to use them, without first making an applicability judgment.

A1 — Past Application (Cases in the Book)

Case 1: Worth doing a Loop — Topic Selection Inbox (Video 3)

High frequency: daily ✅ | Verifiable: has topic-score rating ✅ | Budget: small ✅ | Tools: has research API ✅
Conclusion: Worth it

Case 2: Not worth doing a Loop — One-off script (implied in Video 1)

High frequency: one-off ❌ | Verifiable: N/A | Budget: N/A | Tools: N/A
Conclusion: Not worth it, a single prompt is enough

Case 3: Partially satisfied — Thumbnail generation (Video 1)

High frequency: weekly ✅ | Verifiable: subjective scoring ❌ | Budget: medium ✅ | Tools: has ✅
Conclusion: The verification step is the bottleneck; an independent scoring agent needs to be introduced

A2 — Future Trigger (Future Triggers)

When agonizing over whether to automate: "I want AI to do X every day, is it worth doing a loop?"
When the Loop cost is too high: "This loop costs too many tokens per run" → check conditions 3 and 4
When Loop output quality is poor: "What the loop produces is unusable" → check condition 2 (whether verification is reliable)
When promoting Loops across a team: Use this test as the decision threshold for "whether to do it"

Language signals: "is it worth doing a loop," "should it be automated," "the loop cost is too high," "is this task suitable for a loop"

Differences from adjacent skills:

loop-three-elements: Assumes the decision to do it has already been made, and focuses on "how to design it" (this skill is the upfront decision)
loop-build-path: Focuses on the build steps (this skill is the judgment before building)
comprehension-gap: Focuses on the risks after the loop runs (this skill is the judgment before running)

E — Execution (executable steps)

Step 1: Four-condition checklist

Check the target task item by item:

□ 高频重复: 至少每周做一次?
□ 可自动验证: 有客观标准判断好坏?
□ Token 预算: 能承受反复试错?
□ 完整工具链: agent 有日志+环境+自测能力?

Step 2: Decision

4/4 passed → proceed to loop-build-path to start designing
3/4 passed → identify the bottleneck condition, resolve it first before building the loop
≤2/4 passed → a loop is not recommended; replace it with a single prompt or simple automation

Step 3: If not satisfied, alternatives

Condition 1 not satisfied → single prompt / on-demand triggering
Condition 2 not satisfied → Human-in-the-loop
Condition 3 not satisfied → reduce frequency / simplify the action
Condition 4 not satisfied → improve the toolchain first, then consider a loop

B — Boundary

Scenarios where this skill should not be used:

You have already decided to build a loop: at this point you should proceed to loop-build-path, and no longer make an applicability judgment
Purely technical issues: "Why is this loop throwing an error?" — this is debugging, not decision-making
Non-repetitive tasks: one-off tasks should just be done directly; no loop is needed

The author's blind spots and limitations:

The four test conditions are rules of thumb and lack rigorous empirical support
Condition 2, "can be automatically verified," is hard to satisfy in creative tasks (writing, design), yet such tasks may still have loop value
The video's authors all have technical backgrounds, so their applicability judgments for non-technical scenarios (content creation, research) may be inaccurate

Adjacent but easily confused methodologies:

Cost-benefit analysis: a general decision-making framework; this skill is the concretization of it in the loop domain
MVP thinking: "build the minimum viable version first"; this skill is "first judge whether it is worth doing"