keep-going

Keep going

Purpose

After an interruption — a rate limit, a crash, a disconnect, or just a long gap — work started off the main thread may be paused, dead, or silently finished, and the main task's position is easy to misremember. The same recovery also applies live, mid-session, when off-thread work looks stalled and someone asks you to check on it. This skill recovers or verifies the off-thread work from its real state, reconciles the main thread, and continues. Scope is general: the recovery is the same whatever caused the interruption, so the cause is not diagnosed here.

Two failure modes this skill exists to prevent: summarizing and stalling once a usage limit has lifted instead of continuing, and killing live-but-slow work on a hunch instead of on evidence.

Where /session-flow:handoff deliberately pauses a session, keep-going is the resume counterpart — it picks the work back up after any pause, planned or not.

Two ways in — same flow

After an interruption — a rate limit, crash, disconnect, or gap left work in an unknown state.
A live-session poke — nothing was necessarily interrupted, but off-thread work looks stalled and you are asked to check ("check the monitor", "poke it", "is it stuck", "stop staring at it"). Verify against real output before acting; it may be alive and progressing.

Either way the flow is identical: inventory → inspect the real state → act on evidence → continue.

Intent comes from the conversation, not the arguments

Infer what to resume or check from the conversation and the real off-thread state, not from an argument. Arguments only narrow the target; their absence never blocks. When the conversation makes the referent clear, do not stop to ask "what should I keep going on?" — that stall is itself the thing this skill removes.

Steps

Inventory off-thread work. Enumerate everything running outside this thread, per the off-thread kinds in ${CLAUDE_PLUGIN_ROOT}/reference/off-thread-work.md — an open-ended set (background tasks, shells, monitors, scheduled jobs, dynamic workflows, subagents), not a fixed catalogue.
Inspect real state — never assume. Read each item's actual state from the source of truth, per that doc's inspect-real-state invariant: do not infer "it probably finished" or "it probably died" — only the artifact tells you which.
Recover per item — act on evidence. Classify against the real output and act:
- Progressing (even if slow) → leave it; report it is alive and moving. Do not kill work that is making progress.
- Resumable → resume it. Prefer a real resume over a restart when the mechanism supports one (a workflow resume reuses the cached prefix instead of redoing work).
- Dead but safe to redo → restart it (subject to the autonomy policy below).
- Unrecoverable → surface it plainly; do not fake a recovery.
Reconcile the main thread. Restate where the primary task actually stood — grounded in a fresh read of any plan / checklist / task artifact backing it, not a prior turn's claim — then continue it. When the interruption followed a /session-flow:handoff, read that file rather than trusting memory — and when the handoff's path was lost (a /clear without copying the resume prompt), recover it first with /session-flow:find-handoff.
Report. One list: recovered, restarted, still-running, and lost / unrecoverable.

Active-verification protocol — evidence before action

For any "is it stuck / check the monitor / poke it":

Read the real output first — monitor status, subagent transcript/output, task output, shell logs. Judge from the artifact, never from "it has been a while."
Progress-vs-elapsed is a suspicion-raiser only. Slow relative to elapsed time tells you to look closer; it never by itself authorizes a kill. Confirm "dead" or "stuck" against the actual output.
When the evidence is ambiguous, treat the work as alive. Killing live-but-slow work that was actually progressing is the failure mode to guard against.

Autonomy policy — resume freely, gate side effects

Auto-resume safe, idempotent, read-only, or clearly incomplete work without asking. Recovery should not stall on confirmation for work that cannot double-fire.
GATE before RE-FIRING anything with external side effects — a push, a PR comment, a sent message, a deploy, a mutation — and before KILLING or RESTARTING off-thread work whose death you cannot prove from step 2. When the inspection cannot prove the action did NOT already land, or cannot prove the work is actually dead, stop and ask. Double-firing a side effect, or killing live work, is worse than pausing.

After a usage limit lifts — GO, don't summarize

If you are executing again, the block is already over: continue the work. Do not produce a summary and stop — summarize-and-stall is the failure mode. Report only at the end or on a hard block.
The time-vs-reset check belongs to the orchestration case: when step 2 inspects a worker or subagent that is itself limited, compare the current time against the reset its limit message states, to decide whether that worker can proceed now. In a single interactive session, if you are running, the answer is already GO.
Reset information available in-session is the limit message text only (e.g. resets 3:45pm) and the interactive /usage view — there is no environment variable, file, or API that exposes it. Read the reset from the message; never invent a window.

Still blocked (limit not yet reset) — hand back, don't busy-wait

While a limit still holds you cannot make progress in this session. Compose with /session-flow:handoff to drop a resume artifact so nothing is lost, then stop. Automatic wake-and-continue at the reset time is an external scheduler's job — a desktop scheduled task or a cloud routine launched to resume from that handoff — not this skill's; keep-going hands back cleanly and stops.

Nothing-off-thread case

If the inventory finds no off-thread work, say so and go straight to step 4: reconcile the main thread from its real state and continue. The interruption may have hit mid-turn on the main thread alone — recovering that is still the job.

What this skill does NOT do

Does not diagnose the interruption type. A short limit, a weekly limit, or a crash all take the same recovery, so the cause is not classified. (Reading a stated reset time to gate a blocked worker is not diagnosis — it does not change the recovery method.)
Does not kill or restart live-but-slow work on a hunch. Action follows real output, and kill/restart is gated like any side effect.
Does not summarize-and-stall after a limit lifts — it continues.
Does not build or arm its own scheduler. Still-blocked work is handed back via /session-flow:handoff, not parked on a self-armed wakeup.
Does not trust remembered state. Every status claim is grounded in a fresh read of the real artifact.

Gotchas

"Probably done" is one failure mode; "it has been a while, kill it" is the other. A resumable job that looks finished may have died at 90%; a side-effect that looks unsent may have landed just before the cutoff; live-but-slow work that looks hung may be one step from done. Read the artifact before you decide.
After a limit lifts, the pull is to summarize and hand back. Resist it: if you are running, continue, and report at the end.