# Park Long Waits

> Park and resume work automatically when an external experiment, training run, deployment, build, download, queue job, review, remote process, or other operation leaves no useful action until it produces a result. Use proactively during long-running goals, when the user asks Codex to babysit or monitor slow work, or when repeated polling would waste agent turns. Keep active Goal mode active, checkpoint state, attach a completion-aware waiter or condition-triggered monitor, remain quiet while the operation is unchanged, wake the same task only when a result is actionable, and then continue the goal. Do not use merely because the overall task is long, while productive work remains, or for deterministic work that can continue now.

- Skill: `ben-lau1/park-long-waits` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ben-lau1/park-long-waits`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ben-lau1/park-long-waits/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Ben-Lau1 (https://skillmd.com/u/ben-lau1)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ben-lau1/park-long-waits

---


# Park Long Waits

Reduce idle agent turns by separating productive work from elapsed wall-clock time. Use native wait, Scheduled, reminder, monitor, or thread-wakeup tools to resume; a skill cannot wake itself.

## Decide Whether to Park

Evaluate the next meaningful action, not the total task duration.

1. Continue immediately when useful analysis, implementation, validation, documentation, or authorized parallel work remains.
2. Use an event-based or session wait when an active tool, process, or subagent can wake the task on completion without repeated model turns.
3. Park when no useful action is available and the earliest meaningful check is at least 60 minutes away.
4. Park earlier only when the user explicitly requests it or a native follow-up is clearly cheaper than keeping an active session.
5. Never replace deterministic work with waiting, and never launch a background process only to simulate sleep.

Do not use shell `sleep`, frequent polls, repeated status commentary, or repeated no-change goal turns as a wake mechanism.

## Keep Active Goals Active

Do not pause, complete, or block an active Goal merely because its next useful action depends on an external result. Parking is a wait state inside the goal, not a Goal status transition.

1. Checkpoint the goal and the external operation.
2. Register one completion-aware waiter or condition-triggered monitor tied to the stable operation identifier.
3. Configure the waiter to keep checking without waking the agent while the observed state is unchanged.
4. Wake the same task only when the operation completes, fails, becomes ambiguous, or otherwise reaches a predeclared actionable state.
5. After registering and verifying the waiter, yield without changing Goal status. On wake, revalidate live state and continue the existing Goal.

Never ask the user to pause Goal mode as part of this workflow. Never use `complete` or `blocked` as a substitute for waiting.

## Choose the Resume Mechanism

Prefer mechanisms in this order:

1. Attach a native completion-aware wait primitive to an already-running process, job, or subagent. Prefer event-driven commands such as a provider's `wait`/`watch` operation over timer polling.
2. Create a condition-triggered background monitor that probes the stable job identifier and wakes this same task only for a predeclared actionable result. Keep unchanged checks silent and apply backoff inside the monitor.
3. If condition-triggered wakeup is unavailable, create a one-time follow-up at the earliest credible completion time. Recheck live state on wake and reschedule with backoff when it is still running.
4. If neither a completion-aware wait nor a scheduling/thread-wakeup tool is available, write the checkpoint and clearly state that autonomous resumption is unavailable in this environment. Do not ask the user to pause the Goal and do not claim the task will wake itself.

Keep the follow-up in the current chat so it inherits task context. Reuse or update an equivalent existing schedule instead of creating duplicates. Keep the computer and app requirements of local scheduled work in mind.

## Checkpoint Before Yielding

Record enough state for a cold resume:

- objective and verifiable definition of done
- last confirmed state, evidence, and observation time
- operation identity, such as job ID, process/session ID, URL, branch, artifact, or log path
- exact read-only probe to run after waking
- success, still-running, failure, and needs-input conditions
- absolute next-check time with timezone
- retry count, maximum retries, and backoff rule
- authorized next action and any permission boundary that still applies

Put this checkpoint in the scheduled prompt or other durable task state. Do not rely on an informal ETA alone.

## Schedule Conservatively

- Schedule the earliest time when a new observation could change the next action.
- When a credible completion estimate exists and there is no actionable intermediate milestone, schedule at or just after that estimate. Do not insert hourly checks only to watch progress.
- Prefer event completion over time estimates when an observable signal exists.
- When completion time is uncertain, choose an interval proportional to the expected remaining time and never check more often than hourly unless the user requests it. Use one hour only as the fallback minimum, not as a required first check.
- Back off after unchanged checks by doubling the previous interval, capped at 4 hours unless the task justifies a longer checkpoint.
- Stop after three unchanged unattended checks unless the user asked for persistent monitoring.
- Use read-only checks by default. Do not broaden permissions or task scope for an unattended run.
- Treat creating the follow-up as part of an explicitly requested babysit, monitor, finish, or long-running workflow. Otherwise avoid creating unrelated future work.

After the waiter or monitor is registered, verify its identity, target task, probe, and trigger conditions; then yield and stop agent-side polling. Leave any active Goal active. Do not mark a goal complete or blocked merely to silence it.

## Resume Safely

On each wakeup:

1. Read the checkpoint and recheck live state before reasoning from it.
2. If complete, cancel or disable the follow-up, continue the authorized workflow, and verify the final outcome.
3. If still running, update the evidence and schedule the next backed-off check.
4. If failed, diagnose only within the user's scope; continue with an already-authorized recovery or request input.
5. If the state is ambiguous, report the ambiguity instead of assuming success.
6. If retry limits are reached, stop the monitor and provide a concise status with the exact next manual check.

Never emit a wakeup-only message with no state check. Never leave a recurring monitor active after completion.

## Durable Follow-Up Prompt

Use this compact shape when the scheduling tool needs a prompt:

```text
Resume the current task from this checkpoint.
Objective: <outcome and done criteria>
Last evidence: <state and timestamp>
Operation: <stable identifiers and locations>
Probe: <exact read-only check>
Decision: if complete, continue and verify; if running, update evidence and
back off; if failed or ambiguous, stop or ask according to the stated scope.
Schedule state: attempt <n>/<max>, next cadence <duration>.
Wake condition: <terminal or otherwise actionable states only>.
Keep unchanged checks silent. Do not expand permissions, duplicate schedules,
or report without checking.
```