Loops

Use /loops to list installed and curated loops, or /loop find <goal> to get a short recommendation set. NOME returns at most three loops and explains why they fit. The same pattern is available from CoWork and Mission Control, where loop cards are grouped by category and required capability badges.

/loop run <loop> and the CoWork Run dry-run action enter the canonical loop runtime in dry-run mode first. Dry-run means provider calls, GPU calls, network calls, production mutation, external sends, deploys, and billing actions are disabled unless a later confirmed runtime path explicitly allows them under policy. The receipt records trace_id, loop_id, loop_run_id, route metadata, requested/granted capabilities, approvals, artifacts, and the stop reason.

Build agent from this opens the canonical Agent Builder with the loop prompt as editable behavior draft, required capabilities as setup checklist, verification as acceptance checklist, stop condition as run stop rules, and approval requirements as policy hints. Build mission from this opens the canonical mission-template draft path. Publishing uses existing NOME stores; loops do not create a second agent or mission system.

/loop adapt <loop> creates an adaptation plan, such as narrowing scope, running nightly, or requiring approval before writes. Scheduling uses the existing routines/scheduler path and asks for confirmation before creating a schedule. A loop cannot run forever: max iterations, stop conditions, and approval gates are part of the run contract.

/loop doctor <loop> checks required capabilities, setup blockers, risk/authority level, verification, and stop condition before runtime. Every loop run emits a receipt and is intended to replay across Mac, iPhone, CLI, and web surfaces that expose the work item. Missing proof remains a blocker; local tests alone are not product-green.