/ulw-loop

name: "ulw-loop"
description: "[omh] Ambitious project goal needing many build cycles: agentic interviewer -> planner -> researcher -> builder -> reviewer cycles until a real gate. Use when the user says: loop, goal loop, long horizon goal, never stop, research plan goal feedback, token exhaustion resume, permission profile, star 10k."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, goal-loop]
    category: goal-loop
    phase: continuous-goal-loop
    role: planner
    quality_tier: loop-gated

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