agent-skills/skills/loop-engineering/SKILL.md

name	description	license	homepage	tested_with	status
loop-engineering	Turn a one-off agent prompt into a self-supervising loop that runs unattended, safely. Five stages — manifest, unit, watchdog, attribution, re-grade — plus a human-approval gate on any outward-facing or irreversible step. Distilled from a production fleet that has run thousands of concurrent scheduled agent units. By Elite AI Empire (Our Tools).	MIT	https://ourtools.eliteaiempire.com	claude-code v2.x	draft

Loop Engineering

DRAFT — not for sale yet. This is the packaged, sanitised version of a pattern we run in production at real scale (thousands of concurrent scheduled agent units on our own fleet). No internal hostnames, IP addresses, credentials, or private tooling paths are included below — only the shape of the pattern, which is generic and reusable on any agent stack.

The problem this solves

"Set up a recurring agent task" usually means a cron job that calls an LLM and hopes for the best. That fails quietly in five specific ways: the job gets renamed/duplicated and nobody notices; the process dies and nothing restarts it; a "successful" run silently did nothing (wrong output path, stale credentials, disarmed permission); nobody can tell WHICH code version produced a given result six weeks later; and old conclusions are trusted forever even after the logic that produced them changed. A loop that has run unattended for months without any of these failures needs five separate mechanisms, not one cron line.

The five stages

1. Manifest

A single declarative registry of every unit the loop is allowed to run — not tribal knowledge scattered across scripts. Each entry states: what the unit does, its priority tier (can it be delayed under load, or must it always run first), its restart policy, and its resource budget. Classify units by an explicit, ordered rule set (first-match-wins) rather than trusting free-text descriptions — match on the unit's actual name and command line, never on a human-readable description field, which can drift from what the unit really does. Why it matters: without a manifest, "which jobs exist" is itself an unanswered question, and a job that silently stopped being scheduled looks identical to a job that was never needed.

2. Unit

The thing that actually executes — a scheduled process, not a suggestion. Two properties matter more than people expect:

• Content AND executable-mode both have to be verified, not just content. A file can be byte-identical to its last-known-good version and still be silently broken if its execute bit was stripped by an unrelated deploy — that failure mode is invisible to a hash check alone.
• The running process, not just the file on disk, is the ground truth. A script can be patched correctly while the process still running in memory is executing the OLD bytes (started before the patch landed) — check the process's start time against the file's modification time, not just whether the file "looks right." Pin anything load-bearing (golden copy + hash manifest) so an unrelated automated change can't silently revert it without a deliberate, logged re-bless step.

3. Watchdog

A supervisor that checks the units, not a human remembering to look. Two properties, learned the hard way:

• Admission control, not just a batch runner. If your loop's supervisor starts units in an arbitrary order (e.g. alphabetical) under resource pressure, low-priority research jobs can starve out the units that actually matter, because they happen to sort first. Always start highest-priority tier first, unconditionally, with no resource veto on that tier; let only the lower, deferrable tiers compete for what's left.
• A monitor that goes silent reads as "all clear," which is the worst possible failure mode. Treat "is my watchdog itself still running" as a first-class thing to watch, at the same priority as the units it supervises — never lower.

4. Attribution

Every run's output should be traceable to exactly the code, inputs, and time window that produced it — a labeled claim (e.g. a status field written by the same code being audited) is not independent evidence of anything; it's a claim the code makes about itself. Prefer external, structurally-verifiable evidence (a fresh, uniquely-tagged output compared against an independently-counted source of truth) over trusting a self-reported label. State plainly, next to every result, what evidence backs it and what's still unverified — "unknown" is a valid, honest answer; a made-up number is not.

5. Re-grade

Conclusions decay. The logic that graded a result last month may have had a bug that's since been fixed, or the population it was measured against may have grown. A loop that never revisits old verdicts under current logic will happily keep citing a wrong number forever. Schedule a periodic re-grade pass that reapplies today's logic to historical results and flags any verdict that flips — and report both halves of a verdict (did enough independent evidence accumulate, AND does the effect clear the real-world cost of acting on it), never just one.

The approval gate (the part that makes "unattended" safe)

Everything above runs without a human in the loop — except the step that does something irreversible, outward-facing, or that spends real money. That single step always routes through an explicit approval gate before it executes: a signed, scoped, time-limited permission slip that names exactly what surface (e.g. "publish content," "push to a production repo," "place a real order") and exactly what scope (which target) it authorises, expires on its own, and is logged whether it succeeds or fails. The rest of the loop can run at 3am with nobody watching; the approval-gated step cannot execute without that slip existing and matching.

Design rule: put the approval gate as far downstream as possible — research, verification, and even drafting the outward-facing action should all run freely; only the actual publish/push/ spend call blocks on approval. Gating too early turns "self-supervising" back into "someone has to babysit every step," which defeats the point.

Templates

Three ready-to-import Orchestrator flow templates are included in templates/, each a Workflow (ordered steps: [{tool_slug, params}], a min_tier, and one step in each flow flagged hil: true — human-in-the-loop / approval-gate required before that step runs):

Template	Stages	Approval-gated step
research-loop.json	research → verify → propose → approve → act(paper/draft) → learn → monitor	the act step — anything that would leave the sandbox
content-loop.json	draft → review → approve → publish → measure → re-grade	the publish step — anything customer-facing
infra-loop.json	diagnose → patch → verify-on-canary → approve → ship → watchdog → re-grade	the ship step — anything pushed to a production system

Import a template, point its steps at your own tools, and the approval-gated step will simply not execute until whatever approval mechanism you wire in (a Slack approval, an email link, a signed token — your infra's own equivalent of the gate above) has granted it.

When to use this skill

• You're about to turn a one-off "run this prompt" into something that runs on a schedule.
• Your current cron-based automation has ever silently stopped working and nobody noticed for days.
• You want "self-improving" agent loops (research → verify → execute → learn → monitor) without giving up a human veto on the one step that can't be undone.

What this skill does NOT claim

This is a pattern, not a product that "prints results while you sleep." Every stage above still requires the underlying task (the research method, the verification statistic, the execution logic) to be sound; a well-supervised loop around a null result is still a null result — it just fails safely and tells you so, instead of failing silently.

Upgrade

The hosted version of this pattern — pre-built manifest/watchdog/attribution tooling wired to your own infra, plus the approval-gate integration — is on the Our Tools roadmap; this skill is the portable, sanitised logic. No hosted product exists yet for this skill (draft).