close-out-the-run — reconcile and leave a clean seam

The run is ending. Your job is to ensure the state is accurate and the handoff is clear.

The two triggers

Close out when:

1. Clean bounded autonomous work is exhausted (everything left is gated).
2. The resource you are spending is nearly gone.

Do not churn at the gated boundary

Attempting gated work unsupervised is the single worst way to end a run. It produces low-confidence output that a human must now audit. Stopping is the correct move. State it as a result, not an apology.

Reconcile durable records

Before stopping, check every item the run touched:

• Every item carries an accurate done state and a resolution title that says what actually happened.
• Repositories are committed and pushed, and anything the run shipped went through the whole ship loop in execute-unattended — landed on the branch consumers resolve, tagged, released where that was appropriate, and dogfooded — rather than being called done at the push. Work left sitting on an unmerged branch is a specific thing to look for: it is fully committed and pushed, so it reads as finished from the repository side while remaining unobtainable by anyone. “The tests passed” is weaker than having run the new behaviour once for real, so if the run stopped early at a step, name the step.
• Plans and notes agree with reality.
• Nothing is left orphaned or still flagged as pending when it is finished.

A historical record of a completion is worth keeping. A stale pending flag on finished work is a defect to fix. They look similar and are not the same.

Leave a clean seam

Pause any persistent goal or session-continuation mechanism. Do not leave it running against work you have decided not to do.

The final wrap

The wrap has a required shape:

1. What closed, what advanced, what shipped.
2. What the run consumed.
3. A GATED list: Every remaining item with the reason it could not be done autonomously (needs user input, needs a supervised session, needs a download, is a design/taste decision, needs a fresh session) and the concrete next action that would unblock it. Order this list cheapest-to-release first, and carry whatever ungate tier triage recorded — that ordering is what makes the list answerable in one sitting rather than merely readable. Say separately which items are attended-only and which are waiting on a recurring external condition; neither is a failure to unblock.

Why the gated list matters

It converts "I stopped" into a menu the human can act on in seconds. It is nearly free if triage recorded a gate reason per item.

Lessons

If the run produced a reusable workflow lesson, record it where your durable notes live and put the follow-up on the queue. Do not turn this into a ceremony performed on a schedule. It is worth doing only when something was actually learned.

When NOT to use this

This is the closing pass, not a progress update. A milestone wrap between items belongs to execute-unattended and should stay short; running the full reconciliation after every item turns the run into bookkeeping. Nor is this the place to score what is left — that is triage-for-autonomy, and the gate reasons it recorded are what you are reporting here.

Branding (🏃)

When you begin working under this skill, lead your first substantive reply with "🏃 run-to-completion:" so the user can see which plugin just became active — whichever of the plugin's skills loaded.