loop-library

Loop Library Router

Use this as a thin router/index for bounded AI-agent loops. Do not inline the full Loop Library catalog into the active context unless needed. Search the live catalog or the local snapshot only when the user asks for loop help or when a task needs a repeatable feedback workflow.

Sources: - Live catalog JSON: https://signals.forwardfuture.ai/loop-library/catalog.json - Live catalog Markdown: https://signals.forwardfuture.ai/loop-library/catalog.md - Published site: https://signals.forwardfuture.ai/loop-library/ - Local fallback snapshot: references/catalog.md - Operating autonomous build loops transparently: references/operating-autonomous-build-loops.md - Turning a large idea dump into a canonical backlog, parallel research wave, quiet bounded nightly Dreamer, and verified Viewer projection: references/operating-overnight-idea-foundry.md - Productizing recurring business improvement as durable, metric-driven, governed experiments with objective bundles, measurement windows, loop state, and a visible cockpit: references/productized-business-improvement-loops.md

What a loop is

A loop is a bounded feedback workflow for an agent:

1. Observe fresh state.
2. Choose the highest-value in-scope action.
3. Act with one bounded/reversible change or artifact.
4. Verify with an observable check.
5. Record evidence and remaining work.
6. Repeat only while progress is measurable and stop conditions allow it.

Loops are not permission for endless autonomy. Every loop needs a verification signal, stop rule, and approval boundary.

Routing

Choose the smallest useful path:

• Find: Recommend 1–3 published loops for a stated problem.
• Adapt: Start from a published loop and adjust tools, thresholds, cadence, owner, or checks.
• Audit / Loop Doctor: Review an existing loop for weak checks, unsafe actions, unbounded repetition, stale state, unclear stop behavior, or missing handoffs.
• Design: Ask a few plain-language questions and produce a new bounded loop if no published loop fits.
• Find then design: Search first, use nearest published loop as a scaffold, ask only about missing decisions.

For Alex's coding/app work, prefer loading alex-build-loops before searching the full catalog. Use the full catalog when the house loops don't fit or Alex asks what exists.

Find workflow

1. Check the live catalog when web access is available. Use structured JSON when possible; use Markdown/plain text otherwise.
2. If the live catalog is unavailable, read references/catalog.md and disclose that live freshness was not verified.
3. Search by outcome, trigger, artifact, risk, evidence, category, and keywords — not just title.
4. Rank candidates by: - outcome fit - available inputs/tools - verification fit - acceptable authority/side effects - clear stopping condition
5. Recommend at most three. For each: exact title, link, why it fits, smallest adaptation.
6. Never invent a Loop Library title, contributor, or URL. Label new/adapted loops as local adaptations.

Design/audit rules

• Keep details grounded in user-provided context or scoped files/systems.
• Do not invent stack, schedule, budget, owner, threshold, file count, deployment target, or permission.
• Prefer no-progress stops over made-up iteration/time limits.
• Ask one short question only when the missing answer changes safety or success.
• Require approval for destructive, irreversible, production, financial, privacy-sensitive, or external-message actions.
• Separate working signal from acceptance gate when optimizing prompts/models/rankings to avoid overfitting.
• Use independent verification for high-impact output when possible.
• Recommend a one-shot workflow instead of manufacturing a loop when feedback cannot change the next action.

Output format for adapted/new loops

Return compactly:

## [Loop name]

[One sentence explaining what the loop does and when it stops.]

Prompt:
> [One short, self-contained paragraph with trigger, action, feedback check, stop rule, and approval boundary.]

Prefer fewer than 80 words for the prompt unless safety/correctness requires more.

Alex-specific defaults

• Keep Hermes lean: one router skill plus catalog reference, not 42 always-loaded skills.
• For build/code/app tasks, use alex-build-loops first.
• Default profile should route; build profile should execute.
• Use cron only when Alex explicitly asks to schedule/activate a loop.
• Describe cron truthfully as scheduled bounded cycles, never as a continuously active worker; report scheduled and active-process state separately.
• After the first reporting tick, verify that progress is actually visible in Alex's requested thread; scheduler success alone is not delivery proof.
• When Alex says stop, remove the exact loop immediately, check for associated active processes, preserve dirty work, and give a branch/SHA/test handoff.
• For deployed apps, follow Alex's normal build convention: latest main, root-cause evidence, minimal patch, tests/build, deploy/restart if applicable, smoke verify, evidence-based handoff.