loop-preflight

Loop preflight

loop-readiness reviews a plan's feedback mechanisms statically — it can confirm a gate script is described in the plan, but by its own rule it never executes anything, so it can't confirm the gate still actually runs. This skill fills that gap: it runs the plan's existing feedback mechanisms for real, once, before the loop starts.

A gate can be described accurately in the plan and still be broken — an unrelated change landing between when the plan was written and when the loop actually starts can silently break something the plan assumes still works (e.g. a hardcoded path getting renamed elsewhere). Only actually running the check reveals that; a static read of the plan cannot.

This is a standalone check. Run it whenever a loop depends on pre-existing feedback, whether or not loop-readiness was run first — loop-readiness's own report should point here when it finds feedback the plan treats as already in place.

Step 1: Identify

From the plan (or a list the user gives directly), identify the concrete commands that are pre-existing verification the plan depends on — gate scripts, test suites, lint/type checks cited as feedback. This does not include the loop's actual work (deploy steps, migrations, code changes) — only the checks that trigger these to feedback about plan-driven work already have to keep passing.

List the identified commands back to the user before running anything. Don't assume; confirm the list is right and complete.

Step 2: Guardrails, then run

Before running each confirmed command:

• Scope check — only run commands identified in Step 1 as pre-existing feedback. Never run anything else from the plan (a deploy step, a migration, a data write) even if it's nearby in the same file or the user's earlier go-ahead was general.
• Production check — if a command's path, arguments, or target look production-related (e.g. references something named prod, or a shared/live system), stop and confirm with the user specifically before running that one — even if they already agreed to run the batch as a whole. A general "yes, run them" from Step 1 isn't informed consent for a specific command that turns out to touch something live.