/nonstop

name: nonstop
description: Autonomous work mode that lets Claude work continuously while the user is away. Activates pre-flight risk assessment, dangerous-ops approval, and a blocker decision framework. Use "/nonstop" to activate, "/nonstop off" to deactivate. Use this skill whenever the user says things like "go nonstop", "keep working", "don't stop", "I'm going AFK", "work while I sleep", "finish this without me", or wants Claude to work autonomously without interruption.

Nonstop Mode

A session-scoped autonomous work mode. When activated, Claude works continuously without stopping to ask the user, handling blockers intelligently.

Activation — `/nonstop` or `/nonstop on`

When the user triggers nonstop mode, **start the pre-flight sequence immediately**. Drop whatever else you are doing — do not wait for background agents, pending reads, or other in-progress work. The pre-flight is the priority now.

Complete the pre-flight **before doing any work**. The pre-flight exists because once the user walks away, there is no one to answer questions — every ambiguity must be resolved now.

Phase 1: Mental Simulation — Anticipate Every Blocker

Mentally simulate the entire execution path of the task from start to finish. This is not a generic checklist — it is a task-specific dry run.

**How to think:**

1. Break the task into concrete steps (what will you actually do, in order?) 2. For EACH step, imagine yourself executing it right now. Ask: "What could go wrong here? What would make me stop and ask the user?" 3. Think about the environment: what machines, services, credentials, permissions does this touch? 4. Think about dependencies between steps: if step 3 fails, can step 4 still run? 5. Think about the edges: what if the test fails? what if the build takes 30 minutes? what if a file doesn't exist?

**Surface to the user:**

• Anything that would make you stop and ask — surface it NOW
• Ambiguous requirements where you'd need to make a judgment call — clarify NOW
• Credentials, tokens, permissions you might need — confirm NOW
• Decision points with multiple valid paths — pick one together NOW
• External dependencies that might be slow or unavailable — plan a fallback NOW
• Any step where you're not 100% sure how to proceed — ask NOW

The goal: **after this phase, there should be ZERO reasons to stop and ask the user anything.**

Present your findings as: "Here's what I plan to do [ordered list], and here's what might block me [list with proposed solutions]. Can you confirm/clarify these before you go?"

Phase 2: Dangerous Operations Manifest

Present a **Dangerous Operations Manifest** — high-risk actions that MIGHT be needed during execution. Get explicit yes/no for each relevant category:

| Category | Examples | |---|---| | **Kill processes** | Kill others' GPU jobs, restart services | | **Delete files/dirs** | rm -rf, git clean, drop tables | | **Force push / rewrite history** | git push --force, git reset --hard | | **Deploy / release** | Push to prod, publish package, merge to main | | **Modify infra** | Change cloud resources, modify CI/CD, edit configs | | **Social / comms** | Post GitHub comments/issues/PRs, send Slack messages, reply to reviews | | **External APIs** | Call paid APIs, trigger webhooks, write to external DBs | | **Resource contention** | Claim GPU, take locks, use large disk/memory |

The key principle: **anything that leaves a trace in the outside world that others can see or that costs money** needs approval. Reading is always fine; writing/posting/sending is what needs a decision.

Only present categories that are relevant to the task. For each approved category, record the scope (e.g. "OK to kill MY GPU processes but not others'"). The user may also say "approve all" — that's fine, it's their call.

For anything NOT approved: do not attempt it. Create a task marked as blocked with the reason, and move on.

Phase 3: Permissions Check

Ask the user: **"What's your current permission mode? (check the bottom status bar)"**

• **Bypass permissions** → good to go, no prompts will interrupt.
• **Auto mode** → mostly fine. The auto classifier may block some operations; Claude will attempt alternatives when that happens.
• **Default / other** → warn: "Permission prompts will block me when you're not here. I recommend switching to auto mode (Shift+Tab to cycle) or bypass before you leave."

Phase 4: Confirm and Activate

Present the summary and ask the user to confirm. **Do NOT activate until the user explicitly replies.**

1. **Scope**: "Here's what I'll do: [list]. Anything to add or remove?" 2. **Workaround policy**: "If I hit a blocker, should I: (a) skip and continue, (b) attempt a workaround, or (c) stop and wait?" 3. **Fallback for unapproved ops**: "Dangerous ops you didn't pre-approve will be marked as blocked and skipped. OK?"

**STOP HERE. Wait for the user to reply.** Do not proceed until you receive an explicit confirmation (e.g. "go", "yes", "confirmed", "looks good"). The user triggering /nonstop is NOT confirmation — it starts the pre-flight, not the work.

Once the user confirms, activate:

mkdir -p ~/.claude/hooks/state && touch ~/.claude/hooks/state/nonstop.activate

This signals the stop hook to create a session-scoped flag on your next turn end. The hook knows your session ID and will handle the rest.

Say: "Nonstop mode ON. Go rest — I've got this."

During Nonstop Mode — Blocker Decision Framework

When you encounter something that would normally make you stop and ask the user, follow this decision tree:

Level 1: Can I solve it myself?

• Missing info → search the codebase, read docs, check git history
• Test failing → read the error, fix it
• Build error → diagnose and fix
• **If yes → solve it and move on. Don't stop.**

Level 2: Can I work around it?

• Permission denied → check if there's an alternative path (different API, different approach)
• External service down → skip that part, continu