メニュー
Autonomous overnight operation protocol for when you step away for 6+ hours with a work queue. Defines what to decide alone, what to stop for, agent launch strategy, question parking, QA standards, morning handoff format, and failure handling.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Keep a live interactive chat session coming back to itself, visibly, after a usage/session cap interrupts it, never a silent background process. Invoke with /qq-cap-resume, or say “keep this session alive,” “resume yourself after the cap,” “don’t go dark on me,” any time a long interactive burn needs to survive a 5-hour session cap or ride out to a weekly reset without leaving you staring at a dead thread.
The unbounded end of the AFK spectrum: spend whatever it takes for quality, budget isn’t the constraint. Stand up a self-healing, fully-autonomous “kitchen-sink max-effort” campaign for a big multi-day initiative: resilience first, creative meta strategy, workflows spawning workflows, audit-gated quality, a phone-glanceable status surface with a proud wins list, and a long living tasklist. Invoke when you say “go HAM”, “go-ham”, “go afk ham”, “qq-go-afk-ham”, “kitchen sink”, “blow me away”, “use all the quota”, or hand it a large ambitious build to run autonomously for hours or days. For the frugal end, use `qq-go-afk-lean`; for the adaptive middle, use `qq-go-afk-smart`.
The adaptive middle of the AFK spectrum: picks the right model task by task, moment by moment, instead of committing to either extreme. Stand up a calm, self-healing, fully-autonomous overnight worker for a well-scoped punch list: the top-tier model writes strict specs and does quality control, cheap and free models do the grunt work, one bounded task per cycle, each one deployed and live-verified, a phone-glanceable status surface, and a durable done log. Invoke when you say “go afk smart”, “go-afk-smart”, “qq-go-afk-smart”, “go smart”, “bounded overnight”, “delegate and verify overnight”, or hand it a finite, well-specified backlog (a punch list, a rollout, a sweep) to grind down autonomously while you sleep, without the kitchen-sink fan-out of go HAM. For the unbounded end, use `qq-go-afk-ham`; for the frugal end, use `qq-go-afk-lean`.
The moment a real, avoidable mistake happens, name it plainly, root-cause the general class of it rather than just this one instance, and fix it at a level that prevents a repeat, not a note that gets written and forgotten. Then, before starting work that looks like it could repeat that shape, check the log first. A second occurrence of the same mistake means the note wasn’t enough, and it needs to become a real check instead of a reminder. Invoke with /ww-mistake-ledger, or say “log this mistake,” “close the loop on this,” “add this to the mistake log,” “check the mistake log first,” right after a preventable error, or right before starting work that resembles one already logged.
Ask what would make this fail before you build it, not after. A one-question design-time gate, imagine it’s already broken three months from now, work backward to the most likely cause, and let the answer change the plan instead of just getting noted and ignored. Works on code, an automation, a process, or a decision. Invoke with /ww-premortem, or say “what breaks this in three months,” “pre-mortem this,” “why would this fail,” “before I build this,” at the moment you’re about to commit to an approach, not after you’ve already started.
Before filling a gap in what you know with a guess, check whether the guess is load-bearing. If getting it wrong would mean redoing real work, or building on a false premise, ask a real question with concrete options instead of assuming silently. If it’s genuinely low-stakes, state the assumption out loud and keep moving rather than stalling on it. Works on any ambiguous request, with or without an AI agent involved. Invoke with /ww-questioning, or say “wait, let me ask first,” “is this load-bearing,” “check before I guess,” “clarify before building,” whenever a request has more than one reasonable reading and you’re about to just pick one.
| name | ww-overnight-runner |
| description | Autonomous overnight operation protocol for when you step away for 6+ hours with a work queue. Defines what to decide alone, what to stop for, agent launch strategy, question parking, QA standards, morning handoff format, and failure handling. |
Part of Claude Code operator skills: a collection of skills for running a real Claude Code setup.
The problem: you hand off a multi-hour work queue and walk away, and everything downstream of that moment is a gamble. An agent that stops to ask permission on every judgment call burns the whole night waiting on you. An agent that never stops might quietly delete something, push to main, or send a message it shouldn’t have. Neither failure mode announces itself until morning, and by then it’s too late to redirect.
This is a real contract for working unattended for hours: what to decide alone, what to always stop for, how to launch and parallelize agents, where non-blocking questions get parked instead of asked, what QA standard applies with nobody watching, and what a clean morning handoff actually looks like.
This is a decision contract, not a process-survival mechanism. It governs what an agent decides on its own and how it reports back; it has nothing to say about surviving a 5-hour session cap, a closed laptop, or a reboot. If you also need the run to survive those, pair this with a resilience mechanism like the ww-keepalive skill (also in this repo): ww-keepalive keeps the process alive across interruptions, this skill governs what it does with that time.
Load this skill when:
Do NOT use for:
For a single task or short session where you say “plow ahead” / “keep going” / “use your best judgment”, run autonomously without the status-board or results-file ceremony. Just the contract below plus a closing recap. (A 6h+ queue uses the full protocol that follows.)
Autonomy contract. Treat the instruction as permission to continue through normal uncertainty. Turn routine questions into stated assumptions, pick the smallest reversible option, record why, and keep moving. Do not pause to ask which reasonable option you’d prefer. Pick one and note it.
Decision rules when choosing without you in the loop: reuse existing patterns before inventing; prefer local, reversible, low-blast-radius changes; keep scope tight to the request; validate with the smallest meaningful test first, then broaden.
Stop only for true blockers: missing credentials/secrets/paid access; destructive, irreversible, or production-mutating steps; branch ops, force-push, or deletion you didn’t request; high legal/safety/privacy risk a conservative local choice can’t reduce; a decision you reserved; or a verification failure that repeats where the next fix would be speculative. If blocked, leave a self-contained handoff: what’s done, what blocks, the exact input needed, the next file or command.
Close with a recap: Goal, key decisions and why, changes, validation and result, remaining risk. Keep it factual, never hide skipped validation or judgment calls. End with a one-line status marker (🟢/🟡/🔴, see QA settings).
Before you step away, confirm:
tonight-results.md at project root)tonight-results.md is open in your markdown viewer of choicereferences/agent-launch-details.md when you need the work-queue-size → agent-strategy table or the agent-type routing table.Agents combining tasks: When two adjacent tasks are closely related, a single agent will often handle both in one pass. This is efficient. Log the combined result as “Task N+M” in the results file. Do not treat it as scope creep.
Two-pass tasks: A complex task may get a structural pass (one agent) then a formatting or quality pass (a second agent). The second agent should read the results file and pick up exactly where the first left off. This is a valid pattern. Do not re-do the structural work.
Long parallel runs can exhaust a session’s usage window mid-task. If your platform exposes a usage-tracking command, check before substantial work and between waves. For Claude Code specifically:
npx -y ccusage@latest blocks --active --json
min(3600, secondsUntilWindowClears); chain wake-ups for longer waits). On wake, re-check the real window: a new active-block timestamp is stronger evidence than elapsed wall-clock.Create at project root or a shared operations/scratch directory:
QUESTIONS-FOR-YOU.md
Path convention: if working in a specific project, use that project’s root. For a system-wide overnight session that isn’t scoped to one project, pick one stable path in your own setup and keep using it every time, so it’s always the same place to check in the morning.
Stand up a working doc, Notion, a Google Doc, whatever surface you actually check from your phone, at session start. This is your phone check-in interface, so it needs to read like one, not like an engineering log. If you’re building it in Notion specifically, the notion-docs skill (also in this repo) covers the markdown quirks (tables, callouts, escaping) you’ll otherwise trip over.
Creation: create the page in whatever database or folder you use for working docs. Open it (or share the link) immediately after creation.
Update cadence: new round at the top after each phase, or whenever status color changes. Previous rounds become collapsed/toggled sections.
Last updated lives in the health callout. Bump the timestamp every time you touch the doc. Without it there’s no way to tell at a glance whether the session is still alive.### 🛡️ Guardrails {toggle="true"}
<callout icon="🚫" color="red_bg">
**Never**
- [hard-stop bullet]
</callout>
<callout icon="⏲️" color="yellow_bg">
**Budget**
- [budget bullet]
</callout>
After each phase (or color change), add a new round at the top:
# Round N — ...) to a collapsed/toggled section and indent its contentContext compaction can happen during a long overnight session. When resuming after compaction:
The problem: in-session task-tracking state does not persist across compactions. After resuming, it can show all tasks as pending, even completed ones. Do not trust it.
On resume:
tonight-results.md or equivalent). This is the ground truthThe results file is always the authoritative record. In-session task tracking is for launch coordination only.
Overnight runs use MAX QA. No exceptions.
references/qa-and-failure-handling.md when you need the full “always active” QA gate list (steelman, verification agent, QA swarm, TDD, completion-language ban, audit convergence, status-line format).For any build that produces visual output (marketing sites, dashboards, landing pages, email templates):
Desktop / tablet / mobile screenshots are mandatory at every audit gate. Standard breakpoints: 1440 / 768 / 390. Use a headless screenshot tool against the staging URL, save PNGs into <project>/content/screenshots/<gate>/<page>-<breakpoint>.png.
Screenshots get embedded in the status doc at each gate via whatever image host you use, so you can review from mobile. Never attach local file paths, they don’t render.
A browser MCP’s snapshot tool can be dangerous on many setups. Oversized images (>2000px) have crashed sessions. Prefer a standalone screenshot tool against a published staging URL. If you must use an MCP snapshot tool, scope it to a single element, never the whole page body.
If a screenshot returns oversized or fails, abandon that snapshot and move on. Do NOT retry the same element, that’s how sessions crash.
Read references/qa-and-failure-handling.md when running the per-agent pre-task/post-task checklists.
The results file (tonight-results.md or equivalent) must render cleanly in whatever markdown viewer you actually use.
The results file is the ground truth, not in-session task tracking. That state does not survive context compaction and should not be treated as authoritative. Any reconciliation between task-tracking state and reality should always defer to the results file.
references/qa-and-failure-handling.md when you need the before-retry checklist or the after-retry-fails write-up format.These are the things that go wrong during autonomous sessions. Avoid them.
Never delete files, database records, or git history during an overnight run unless:
No emails. No chat messages to real people. No SMS. No calendar invites. Exception: sending yourself a push notification through whatever tool you already use for that is fine. That’s a note to yourself, not outbound communication.
If code changes are ready to commit, create the commit but log it in results. Do not push. Write the commit message but note: “Ready to push, needs your review.”
If a task is taking longer than expected, checkpoint:
Steelman requires a fresh agent context when used overnight (spawn a separate planning agent, not self-review). Self-steelman introduces self-confirmation bias.
Two agents writing to the same file = race condition = corrupted output. If tasks share an output file, serialize them.
If a task would benefit from your input and the agent chose to proceed autonomously, LOG THAT DECISION. Silence is not a green light, it’s an absence. Autonomous choices should be explicit in results, not buried in the diff.
PRE-FLIGHT
[ ] Hard stops documented ("don't X")
DURING
[ ] Park blocking questions (don't guess on irreversible)
[ ] Never parallelize same-file writes
references/agent-launch-details.md when picking an agent type for a task, or when an agent naturally combines or two-passes tasks and you want to confirm that’s an expected pattern, not scope creep.references/questions-template.md when you are about to create or write into QUESTIONS-FOR-YOU.md and need the exact fill-in-the-blank format.references/notion-status-board.md when you are creating the kickoff round of a Notion-flavored status board, naming its page title, or adding a round 2+ update, and need the exact markup.references/morning-handoff-template.md when you are creating or writing into tonight-results.md and need the exact file structure and status emoji key.references/real-example.md when you want a worked example of the overnight protocol run end to end.references/quick-reference-card.md when you want a single condensed checklist covering the whole session lifecycle instead of re-reading each section’s own checklist.references/qa-and-failure-handling.md when verifying a UI build at an audit gate, running the per-agent pre/post-task checklists, or retrying a failed task.