# Fill The Wait

> When a long-running operation (install, build, test run, deploy, model download) is in flight, pick up an independent in-lane task to advance in parallel rather than idling. Use whenever a wait of ~30 seconds or more is forced by a backgrounded command and there's an independent in-lane task ready to start.

- Skill: `jcdavis131/fill-the-wait` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jcdavis131/fill-the-wait`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jcdavis131/fill-the-wait/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: jcdavis131 (https://skillmd.com/u/jcdavis131)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/jcdavis131/fill-the-wait

---


# Fill The Wait

A blocking wait is dead time only if you let it be. A 30s+ install, build, test, or deploy is a window to advance an independent lane.

## The move

1. **Recognize the wait.** You dispatched a command that won't come back for a while (install, build, test, deploy, big fetch). Don't sit idle.
2. **Pick an independent in-lane task.** It must be:
   - **In your lane** (see `lane-discipline`).
   - **Independent** of the running op's output — you can't fill a wait with the task that needs the wait's result.
   - **Small enough to make progress in the wait window** — if the wait is 30s, pick a 30s-task; if it's 10m, you can take a real task.
   - **Non-conflicting** — doesn't edit the same files the running op is building/testing.
3. **State it.** "While the install runs, I'll instrument the training script." This makes the parallelism visible and explains the second `◼` on the board.
4. **Update the board.** A second `◼` for the fill task is correct here (see `progress-board`'s backgrounded-op rule).
5. **Reap the original op when it returns.** Don't get so deep in the fill task that you miss the original op's completion/failure. Check its result, then decide: finish the fill task, or return to the original lane.

## Good fill tasks

- Instrumenting / wiring a script that the running op doesn't touch.
- Writing docs, an OKF bundle, or a review that's independent of the build.
- A sibling SME review lane (see `sme-fanout`).
- Reading a sibling file to plan the next task (see `match-conventions`) — a read is always safe and never conflicts.

## Bad fill tasks

- Anything that edits the files the running op is building or testing → race condition.
- Anything that needs the running op's output → not independent.
- A task in another agent's lane → `lane-discipline` violation.
- A destructive op → if it fails, you're now juggling two failures (see `background-failure-triage`).

## When NOT to fill the wait

- The wait is short (< ~30s). The context-switch cost exceeds the gain.
- There's no independent in-lane task ready. Idling is fine; inventing work to fill a wait creates low-value churn.
- The running op is fragile and needs you to watch it (a deploy you might need to roll back).

## Pair with

- `progress-board` — the second `◼` is the visible signal that you're filling the wait.
- `cost-transparency` — a 5m wait is a 5m fill window; a 30s wait isn't worth a fill task.
- `background-failure-triage` — if the running op fails while you fill, triage at the next boundary, don't panic-abort the fill.