# Keep Going > Recover and continue after an interruption, rate limit, crash, disconnect, or gap, or when live off-thread work looks stalled and you are asked to check on it. Inventory off-thread work, inspect its REAL output, act only on evidence (resume / rerun / kill-and-restart), then continue the main task where it stood. Use when: asked to keep going, continue, resume, or pick up where you left off; after being cut off or interrupted ('what were you doing'); or asked to check on, poke, or judge whether off-thread work is stuck ('check the monitor', 'is it stuck', 'stop staring at it'). Infers intent from the conversation; arguments optional. After a usage limit lifts it continues rather than summarizing-and-stalling; it gates killing or re-firing side-effectful work. To retire finished off-thread work and reconcile the task ledger rather than resume, use /session-flow:reconcile. - Skill: `melodic-software/keep-going` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add melodic-software/keep-going` - Raw SKILL.md: https://api.skillmd.com/api/skills/melodic-software/keep-going/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: melodic-software (https://skillmd.com/u/melodic-software) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/melodic-software/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 1. **After an interruption**, a rate limit, crash, disconnect, or gap left work in an unknown state. 2. **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 → align on the recorded goal → 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 1. **Inventory off-thread work.** Enumerate everything running outside this thread, per the off-thread kinds in [`${CLAUDE_PLUGIN_ROOT}/reference/off-thread-work.md`](${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. 2. **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. 3. **Goal alignment, before any recovery ACTION.** When the resume follows 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`. Read its `Original goal` section, then test the planned next actions against it: **say in one sentence how the next action serves that goal.** If you cannot, that is drift, not a wording problem. Stop, and either re-derive an action that does serve the goal or ask the user whether the goal changed. **A handoff carrying no `Original goal` is itself a defect:** do not infer the goal from the process the file describes, which is the thing that drifted, ask the user for it in their own words before continuing, and carry their answer into the next save-point. This check sits between inspection and action deliberately: steps 1-2 only read, but step 4 resumes and restarts work, and restarting work that serves a drifted goal re-arms the drift before anything has tested it. One sentence, not a new stage. Its cost is nothing and its absence is the only signal that many sessions of faithful execution were aimed at the wrong thing. 4. **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. 5. **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, and continue it. 6. **Report.** One list: recovered, restarted, still-running, and lost / unrecoverable. ## Zone input (presence-gated, conservative) Step 5 continues the main task in **this** session, and that is only right when this session's context is still fit for the work. When the `context-guard` plugin is installed, resolve this session's zone word per its reader contract before continuing (the contract owns the snapshot path, staleness rule, and bands. Read them there; this skill consumes only the resulting word and inlines no band values). Never substitute your own estimate of the remaining window for the instrument's reading, a resumed session's sense of its own budget is exactly the guess the instrument exists to replace. Absent plugin, absent snapshot, or `unknown` → judge from response quality alone, conservatively. A degraded zone, or context-guard's evidence-degraded marker for this session, does not stop the recovery (steps 1-4 are reads and evidence-gated actions either way); it changes where the *continuation* goes: prefer routing the remaining work through `/session-flow:handoff` over pushing a long or judgment-heavy task through a degraded window. ## 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. Run the bundled checker instead of doing this arithmetic yourself: ```shell python3 "${CLAUDE_PLUGIN_ROOT}/skills/keep-going/scripts/check-usage-limit-reset.py" "" ``` Exit `0` means the reset has passed, treat the worker as resumable now. Exit `1` means the limit still holds, hand back by invoking `/session-flow:handoff` via the Skill tool and stop. Exit `2` means the message carried no parseable reset clause; say so plainly and ask the operator rather than guessing. Exit `3` means the reset clause parsed but the IANA timezone could not be resolved (rare when the bundled `tzdata` under `scripts/vendor` is present); report the timezone failure rather than treating the message as unparsable. In a single interactive session, if you are running, the answer is already GO. - Reset information reaches a session through the limit **message text** (e.g. `resets 3:45pm`) and the interactive `/usage` and `/rate-limit-options` views. Read the reset from the message; never invent a window. Verified 2026-09-06 against Claude Code 2.1.263 and [Manage costs effectively](https://code.claude.com/docs/en/costs#when-a-developer-asks-about-a-limit), which states that the limit message shows when the window resets and points at `/rate-limit-options` for the wait. Recheck when that page stops carrying that statement, or when a release note names another surface for the reset time. ## 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, run step 3's goal-alignment check when a handoff backs the resume, then go straight to step 5: 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 by invoking `/session-flow:handoff` via the Skill tool, 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.