Loop

This is a Hermes-native loop workflow skill.

Why This Exists

loop exists for goals whose correct implementation cannot be known upfront but can be discovered through bounded cycles of definition, action, verification, and revision without confusing planned cycles with observed progress.

Do Not Use When

• The user asks for one bounded delivery cycle; use ulw-work's delivery-boundary capability instead.
• Scope and milestones are already known and only durable checkpoint/resume tracking is needed; use ulw-work's durable-checkpoint capability.
• The user gives only a north-star outcome such as revenue, stars, or adoption and declines the bounded first loop goal you proposed; stop at the proposed arena, problem and verification and wait.
• The goal is too vague to name an observable problem, next artifact, verification signal, or stop condition.
• The goal depends mainly on external waiting, adoption, revenue, or community response without observable local next actions.
• The permission profile does not allow repeated research, handoff, queue, or feedback cycles.
• The request is a check repeated on a timer inside this session, such as polling CI, a deploy, or a queue every few minutes until it changes; that is Hermes' native /loop (an interval plus --until or --times), which only the user can start, so name the command instead of opening a goal loop.
• The work must run unattended on a schedule that outlives this session, such as hourly or nightly; use omh-automation-blueprint, which settles overlap, missed runs, retries, and failure pauses before a Hermes cron job is created.
• The request is one objective with a stated done condition that needs no interviewer, planner, researcher, or reviewer cycles; native /goal keeps the session on it (/goal draft writes its completion contract), and this skill keeps the long-horizon loop engineering.