Ulw Loop

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 ultrawork's delivery-boundary capability instead.
• Scope and milestones are already known and only durable checkpoint/resume tracking is needed; use ultrawork's durable-checkpoint capability.
• The user gives only a north-star outcome such as revenue, stars, or adoption and has not accepted a bounded first loop goal.
• 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.

Examples

Good example:

• Prompt: ./loop make OMH a credible Hermes workflow pack with install, docs, QA, and feedback cycles.
• Expected behavior: Start a permission-scoped loop, maintain loop_cycle/v2 selected-driver state, choose the next concrete task, and keep external outcomes as waiting states.
• Why: The request is long-horizon and needs repeated discovery, verification, feedback, and resume decisions.

Bad example:

• Prompt: ./loop merge this already reviewed one-line README fix.
• Expected behavior: Use a direct delivery or PR workflow instead of starting a persistent loop.
• Why: The task is bounded and should stop after merge evidence rather than create ongoing cycles.

Completion Checklist

• The request is classified as task, project, north-star ambition, external-wait, or unclear before a loop starts.
• The current loop_status_card/v1 names the queue item, tick status, verification_plan, and next action.
• failure_mode_summary checks verification_gap, comprehension_debt, and cognitive_surrender before progress advances.
• Completion is backed by linked goal/runtime evidence; queued loop ticks alone are not observed work.
• Native /goal activation and continuation are backed by loop_goal_driver_observation/v1, and each observed role advance is backed by loop_phase_transition/v1.

Recovery Notes

• Prefer the native omh_loop tool when the plugin is loaded: assess, start, status, feedback, permit, run_once, goal_driver_observe, and queue_observe reach the same loop_cycle/v2 state, and a mutation submits the record_revision that status reported. Where it is absent, the same lifecycle is omh loop assess|start|status|feedback|permit|run-once|goal-driver-observe|queue observe, and every other Loop surface stays on that CLI.
• If a queued tick is pending, show it as prepared queue state and use loop status/run-once before claiming progress.
• If feedback is unclear, ask one gate question or route back to research/plan rather than advancing the loop.
• If the goal turns into external waiting, record the waiting state and next observable signal instead of continuing locally.
• Checkpoint on context/budget exhaustion. Migrate loop_cycle/v1 with migrate-driver --apply before external binding.
• Resume paused native goals with re-registered gates; external goals follow driver recovery. Transfers require observed stopped/absent reconciliation; handoffs never dispatch.
• If the loop runs out of next actions, re-read the scoped files, recombine the near-miss attempts, then escalate to a more radical change before declaring the loop blocked.

Workflow Lane

• Current lane: Intent -> plan (oh-my-hermes, meta-router, deep-interview, context, plan, ralplan, adversarial-consensus, codebase-onboarding, +8 more) - clarify, plan, ship, or loop goals.
• If intent belongs to another lane, hand back to oh-my-hermes or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: omh-routing/references/skill-common-rail.md.

Use When

Use when the user starts a high-level goal or invokes loop. Direct loop invocation means start/continue through interviewer, planner, researcher, builder, reviewer, and loop-controller lanes until a real gate stops it.

Strong routing signals: `loop`, `./loop`, `$loop`, `goal loop`, `long horizon goal`, `never stop`, `research plan goal feedback`, `token exhaustion resume`, `permission profile`, `star 10k`, `10k star`, `loop engineering`, `keep running until done`, `루프`, `목표 루프`, `장기 목표`, `끝까지`, `토큰 고갈`, `피드백 루프`, `끝날 때까지 계속`, `계속 돌려줘`

Catalog Metadata

Category: goal-loop Phase: continuous-goal-loop Hermes role: planner Quality tier: loop-gated Reasoning demand: heavy

Quality bar:

• Treat direct loop, ./loop, $loop, and OMH loop invocations as a start/continue signal rather than a picker or passive clarification path.
• Classify the goal as task, project, ambition, external-wait, or unclear inside the loop, then keep progressing until a real permission, evidence, verification, context, budget, or external-wait gate appears.
• A mid-run user message is an interjection, not a stop: answer it briefly and, in the same reply, continue the run — re-read the phase todo when one is active and dispatch or advance the next pending step, or name the armed wait it is waiting on -- handle, bound completion signal, deadline -- instead of re-reading status. Only the user's explicit stop or cancel, or the engine's own completion gate, ends the run; when the interjection changes scope, say so and update the declared plan or todo instead of silently abandoning it. A mid-run message is the latest steering for the active task, not automatically a replacement objective: it replaces the objective when the user says so and steers the current one otherwise.
• A follow-up that needs new authority, materially expands the scope, or changes external state not already authorized is described first and started only on the user's approval: the turn ends by naming that next action and asking whether to take it, as one question carrying the choices the user has, never by declaring what will not be done; persistence never broadens the authorized scope. A refused escalation is answered the same way, with a safer alternative inside the boundary or the authorization the boundary asks for — never a workaround or an indirect execution.
• The closing brief scales to the change: one or two sentences plus the observed validation for a simple change, more only when the complexity earns it. Lead with the result or decision, in the user's words; omit abandoned approaches unless they explain a tradeoff the reader needs; narrate no internal bookkeeping (todo transitions, waits). When the work stops at a boundary or at a decision the user owns, end with the next action offered as a question, and state what was left undone as the option it leaves open, never as a refusal. Required closing lines stay outside this scaling: the observed run summary, and any prepared-not-observed or unmerged work, are stated whatever the brief's length.
• Expose core OMH roles: interviewer, planner, researcher, builder, reviewer, and loop controller.
• Route tiny direct tasks to one-cycle delivery surfaces instead of forcing loop overhead.
• Reframe a north-star ambition into a bounded arena, observable problem, next loop goal, and next verification without shrinking its ambition.
• Separate task discovery, distribution, execution, verification, next-task decision, runtime tick queueing, durable-checkpoint/handoff, feedback, waiting, and resume decisions.
• Expose a permission profile before executor/runtime dispatch, repository mutation, PR, merge, or external publishing.
• Expose the automation, worktree, skill, connector, and subagent building-block states without treating planned blocks as observed work.
• Choose workflow patterns such as single-step, fan-out-and-synthesize, adversarial verification, tournament, or triage batch as orchestration metadata only.
• Keep repeated scaffold shape stable, summarize within bounded budgets, and add verifier lanes only when risk or evidence warrants them.
• Keep prepared worktree/subagent/connector plans, observed executor work, linked goal completion, and external waiting as distinct evidence states.
• Use cheap inner-loop checks frequently and expensive outer-loop checks sparingly.
• Keep the practical small-loop recipe visible: test as stop signal, plan -> execute -> verify, one task at a time.
• Surface verification_gap, comprehension_debt, and cognitive_surrender as warnings before a loop starts looking self-steering.
• Session-bound host_observed resumable_goal plus explicit coding ownership prepares one executor goal. Otherwise use native /goal and /goal gate add. Never prepare two controllers.
• Ingest bounded snapshots via omh loop goal-driver-observe. External state guides recovery, not checkpoint decisions; native turns still require activation and contiguous same-session evidence.
• Treat ticks as preparation only. Advance one legal role phase through loop_phase_transition/v1 only after its named gate has observed evidence.
• Treat a judge done verdict, a turn-ceiling pause, or a gate-retry pause as narration; completion still requires the linked goal ledger completion gate and observed evidence.
• Treat any future change to the default as a maintainer-reviewed product decision, not a runtime phase or automatic loop outcome.
• Compare only observed outcomes under matched task, model/provider, permissions, turn budget, and verification surface; unresolved evidence keeps the current default.
• Keep promotion governance separate from goal-ledger completion and ordinary measured-loop keep/discard decisions; do not invent subjective scorers, fixed numeric thresholds, minimum run counts, weighted percentages, or per-turn artifact quotas.
• Name the one element gating this loop from the loop_constraint_assessment/v1 block before choosing the next action; if none is binding, say so from the recorded reason rather than assuming.
• For an iteration that must outlive this session, run under another profile, or needs its own Hermes worktree, load references/board-iteration.md: builder and verifier rows chained by parents, a needs_input block when the loop must stop for the user, and resume from board readback rather than memory.
• When the goal is measurable, declare the evaluation contract before the first attempt - exact command, metric name, direction, and the rule that the loop may not modify the scoring harness - and bind every keep or discard decision to it; when no such contract exists, say the goal is unmeasured instead of scoring it by judgement.
• Run a measurable cycle as attempt, commit, measure, then keep or reset; a reset is the normal discard, and rewinding to an older commit is for a run of discards that traces to one bad ancestor.
• For a measurable loop, keep a human-scannable ledger the loop itself appends to - one tab-separated line per cycle carrying commit, metric, cost, keep or discard or crash, and a one-line description - beside the JSON loop artifacts.
• Send long-running cycle output to a log file and pull only the declared metric and error lines into context; read the whole log only when the cycle crashed.
• Choose the wait strategy before starting long-running work and bind it to a completion signal the host exposes, never to a status loop: a command that fits one tool call runs once in the foreground with a duration-sized timeout; a longer terminal command runs in the background with completion notification armed and no process-status polling; a delegated lane relies on its delivered result while the parent continues independent work or ends the turn; a CI, PR, deploy, file, port, log-line, or external-session condition uses the host's monitor when observed, else exactly ONE bounded watcher or adaptive backoff outside model turns. Record the handle and observation mode at dispatch; every armed wait needs a hard deadline, a cancellation path, and a fallback naming the missing capability. Each wait closes in one terminal state with bounded evidence; an unbounded idle or busy-wait is a defect and a lost notification times out. One decision-changing midpoint peek and any user-requested status check stay allowed; neither is the wait mechanism. Ladder and terminal states: shared rail.
• On an equal metric keep the simpler change, always keep an improvement achieved by deletion, and do not let a small gain buy added complexity.