Loop Engineering

Drive one change from intake to ready through plan → approve → execute → verify → independent review → address → ready. This skill defines what each phase means and what evidence crosses its boundaries. It does not authorize tools, publication, scheduling, or delegation, and it does not prescribe where durable state is stored.

Project policy owns which change-delivery gates apply, external code-review independence, branch and delivery rules, and storage representations. Where policy is silent, use this skill's existing defaults: a human-approved plan before edits, required verification, mandatory independent review, append-only recovery, and a ready state only after convergence.

This skill does not assign priority between runtime-injected instructions and project mandates. Host entry guidance explains how to apply the active host's actual instruction hierarchy; it cannot redefine that hierarchy. Resolve conflicts using each instruction's actual source and priority, respect tool usage conditions, and report any project gate that cannot be satisfied within those boundaries.

The loop driver is the actor currently responsible for advancing a change against its approved plan and required evidence. When that driver delegates a contribution, it is the parent for that assignment. Launching a separately owned change does not make its launcher that change's driver. Receiving a result does not by itself transfer the loop, human decision authority, or operation grants.

Read-only work that changes nothing does not enter change gates. Implementation delegation, phase-deliverable review, and implementation pre-flight each need their own current qualification. An earlier available or unavailable route decides none of the others. Applicable host guidance owns actor and read routing; this skill keeps checkpoint evidence and progression. Driver execution never makes the driver its own independent reviewer.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Phase Progression

Every change advances against current evidence, never a claim inherited from an earlier phase.

The four rules below apply throughout a change and are needed before reference selection: whether this is change work, who owns it, whether checkpoint qualification is current, and what approval authorizes. They stay here under the unconditional-scope carve-out; checkpoint-specific evidence and procedures stay in their references.