Llm Self Loop

---
name: llm-self-loop
description: 'Restructure Web-UI / human-triggered tasks into CLI + file-output loops the LLM can iterate alone, with structured logs and addressable scratchpads. Apply trap-or-abandon: if a step cannot be looped, improve the harness rather than babysit. Trigger on iterative grunt-work, "push a button in a web UI to trigger this", monitoring dashboards, or any workflow whose inner loop requires a human in the middle.'
---

The job: turn workflows that need a human in the inner loop into workflows the LLM closes itself. The two halves are *removing the trigger gate* and *opening observability*.

## Surface the gate first

Before proposing changes, name the trigger gate explicitly:

- *What action requires a human right now?* (button click, screenshot inspection, terminal interaction, web-form submission)
- *What signal does the human provide that the LLM cannot get on its own?* (visual confirmation, copy-paste, secret value, eyeball verdict)
- *Where does the result go?* (chat memory, screenshot, mental note)

Most loops have one or two gates that, removed, collapse the cycle to seconds. Pick the smallest gate first.

## Structural fixes

### Web-UI trigger → CLI trigger

If the workflow is gated by clicking in a web app, find or build the equivalent CLI command. Webhooks, REST endpoints, `gh` / `aws` / `gcloud` CLI subcommands, internal `just` targets — anything programmatically invokable. The LLM can then loop without leaving its session.

### Stdout-only output → file-based output

If the workflow's result lives in chat memory or a screenshot, redirect to a file the LLM can read back: structured JSON dumps, markdown reports, append-only logs with addressable offsets. *Why:* file outputs survive compaction, support diff, and are inspectable by future sessions without replaying context.

### Dashboards → structured logs

If verification requires eyeballing a Grafana / Datadog dashboard, surface the same metrics through a CLI query (PromQL, Datadog API, log aggregation tail). Anything that produces a `pass`/`fail`/`warn` verdict the LLM can read.

### Eyeball verdicts → contract assertions

If the human's role is "looks right to me", encode the criterion as a test, schema, or assertion. The contract becomes the loop's done-criterion (pair with `strict-validation-setup` for the bootstrap of those gates).

## Trap-or-abandon decision

After the structural fixes above, some steps still cannot be made autonomous — they involve genuine human judgment, external compliance, or capability the LLM lacks. For each remaining gate, apply this rule:

- **Trap** — if the step can be wrapped in a verification-and-iteration loop where the LLM proposes, the human approves once, and the LLM iterates until the contract passes, keep it. The human is at the *outer* loop, not the inner.
- **Abandon** — if a step requires the human in the *inner* loop and resists wrapping (e.g., new SOC2 review per iteration, real-time customer chat, hardware-mediated test), do not babysit. Either remove the step from the LLM's loop entirely (escalate to the human as a discrete handoff) or improve the harness so the step disappears (e.g., automate the SOC2 documentation pipeline).

Naming the rule: babysitting an unloopable step is the failure mode this skill exists to prevent. Pre-existing chat consensus: "what can't be looped — abandon firmly and improve the harness."

## What this skill does not do

- It does not author project rules — defer to `init` for AGENTS.md.
- It does not bootstrap strict-mode validation gates — defer to `strict-validation-setup`.
- It does not pick the test framework — defer to `test-driven` or the language's idiomatic tester.

## Posture

Surgical, not architectural. Remove one gate at a time. After each fix, re-evaluate whether the loop now closes — sometimes one trigger removal is enough. Resist the temptation to redesign the whole system.