Goal Loops

Follow-up Tracker

A closed loop that watches what happens after something you just shipped and finishes itself once the outcome is confirmed. Use it to hear whether the thing misbehaves; if you are measuring a change against a metric and want a verdict, use the A/B Experiment Watch. Works best pasted right after finishing the task you want tracked.

Moderate setupShort cycleClosed loopVisible first run

Setup in Loopany

How a run flows

Before first run

Verify + define the finish

On cadence

A few times a day

Step 1 · Observe

Check for trouble

Step 2 · Report

Only what changed

Step 3 · Check

Settled?

Report

Latest observation

Metric

Checkout errors per hour

closed loop — it finishes itself once the goal is met

How this loop works — schedule, exit, notifications

Suggested schedule: A few runs per day (you set it)
Loop type: Closed loop — goal-bound; it finishes itself when the goal is met.
Exit condition: Finishes once the tracked outcome is confirmed.
Notifications: On by default — you're alerted on each run's outcome (completion or failure). Silence with notify: never.
Ease of starting: Some setup and context are needed before the first useful run.
When you see value: Reports what it observes from the first run, then stays quiet unless something goes wrong.

The prompt this runs

Look at what was just built or shipped in this session and set up a loop that tracks its aftermath. This one watches for trouble: it stays quiet while things behave, speaks up when they do not, and finishes once the outcome is confirmed. It does not score a change against a number - if you have a metric and a threshold and want a ship it or kill it verdict, use the A/B Experiment Watch instead. Before creating anything, verify a concrete way to observe the outcome exists on this machine - logs, metrics or MCP tools, a URL to check, or gh - and run it once as a smoke test; if nothing can actually be observed, say so and do not create a blind loop. Define a concrete finish condition and create the loop closed, with that condition as its goal. Propose a cadence that fits the thing being tracked (a few runs per day is a common default) and confirm it with me. On each run, observe through the verified path, report what you find (and a metric when one is natural), and finish the loop only when the condition is genuinely met; if things regress, report that plainly. Set up a modest dashboard at creation: an embed of the latest report, plus a metric chart when a metric was defined.

This is the exact intent appended to the bootstrap when you create the loop — your coding agent reads it, then proposes cadence and config and confirms with you before creating anything.