# Deepworkplan Resume

> Resume an interrupted Deep Work Plan from its recorded progress state. Use when the developer wants to continue a plan in .dwp/plans/ that was paused or interrupted mid-execution.

- Skill: `dailybothq/deepworkplan-resume` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dailybothq/deepworkplan-resume`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dailybothq/deepworkplan-resume/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dailybothq (https://skillmd.com/u/dailybothq)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dailybothq/deepworkplan-resume

---


# DeepWorkPlan — Resume

Safely continue an interrupted plan from where it stopped — no duplicated work,
strict order, continuing from the first `[ ]` task.

## Shared resources (read these)

- [`../shared/context.sh`](../shared/context.sh) — resolve repo root, branch, and
  `dwp_dir`.
- [`../shared/dwp-paths.md`](../shared/dwp-paths.md) — plans at
  `.dwp/plans/PLAN_{name}/`.
- [`../shared/adaptation.md`](../shared/adaptation.md) — the two repository
  archetypes (relevant for orchestrator/child-DWP awareness).
- [`../execute/SKILL.md`](../execute/SKILL.md) — the execution rules this flow
  resumes into (team-agents, orchestrator task types, Dailybot golden rule).

## Parameter Support
- `/dwp-resume {plan_name}` — resume directly (skip the menu).
- `/dwp-resume latest` — resume the most recently modified plan.
- No parameter → interactive selection (Step 1).

Normalize the `PLAN_` prefix; validate `.dwp/plans/PLAN_{name}/` and its
`README.md`. If not found, show available plans and ask the user to choose.

## Workflow

### Step 0 — Check for Parameters
If a parameter was given, resolve the plan (or `latest`), validate folder +
README under `.dwp/plans/`, and skip to Step 2. Otherwise go to Step 1.

### Step 1 — Identify Plan
List `PLAN_*` folders in `.dwp/plans/`; mark the most recently modified as
`latest`. Present a numbered menu (number / name / `latest`) and validate the
choice.

### Step 2 — Assess Current State (CRITICAL)

This step implements the **DWP Resume Protocol**
(`../spec/DWP_SPECIFICATION.md` §5.3) — the named six-step ritual any resuming
session performs:

1. Read the plan README fully (objective; which tasks are `[x]` vs `[ ]`).
2. Run `git status`, `git log --oneline -10`, and `git diff` (if uncommitted
   changes exist). In a workspace without git, read `state.json`'s `checkpoint`
   instead (`../spec/PLAN_STATE.md` §4.4).
3. **Reconcile the state layer (when present):** compare `state.json` against
   the README checkboxes. On any desync the **markdown wins** — regenerate
   `state.json` from the README (and git log), note the reconciliation in
   `PROGRESS.md`, then continue (`../spec/PLAN_STATE.md` §5). If
   `state.json.blocked` is set, surface it: that is why the plan stopped.
4. Find the resumption point — the **first unchecked `[ ]` task**.
5. Check for partial work: if `git status` shows uncommitted changes, review them
   against the current `[ ]` task; read that task's Completion & Log for notes.
6. **Smoke-test before building:** run the repo's cheapest standing check (from
   `AGENTS.md` Quick Commands) to confirm the world still works before adding to
   it. A failing smoke test is investigated first.

### Step 3 — Report Resumption Status
Report: completed `[x]` tasks; pending `[ ]` tasks; the task to resume from; git
state (uncommitted changes, recent commits, last commit); the current task file
and any completion-log notes; partial-work findings; and the plan to finish the
task. Location: `.dwp/plans/PLAN_{name}/`.

### Step 4 — Handle Partial Work
If uncommitted changes exist, classify them: valid partial progress (incorporate
and complete), incomplete (finish remaining work), or unclear/unrelated (ask the
user before proceeding). If none, proceed directly.

### Step 5 — Resume Execution
1. **NEVER redo `[x]` tasks** — trust the README, cross-check git commits.
2. **NEVER skip `[ ]` tasks** — strict order; complete each fully.
3. **Continue from the first `[ ]` task** — open its file, read fully, address any
   logged blocker first.
4. **Complete the current task** — follow its Execution Checklist; run all
   validations; on failure, log in Completion & Log, leave `[ ]`, report and wait;
   on pass, update the log, mark `[x]`, and commit.
5. **Continue** to the next `[ ]` task until done or paused.

> From here, the standard **Execute** rules apply
> (`../execute/SKILL.md`): the per-task significance Dailybot report, the
> plan-completion **milestone** golden rule, and — for orchestrator plans —
> orchestrator task types (`create_child_dwp` / `integration_checkpoint` /
> `execute_child_dwp`), manifest checks, and team-agents parallel groups (real
> team agents, not subagents) with sequential fallback. Resume from the first
> `[ ]` task using those same rules, including hub-vs-individual-repo navigation
> per `../shared/adaptation.md`.

### Step 6 — Handle Blockers
If a task log shows a blocker, read it, fix the issue, re-run validations; on
pass: mark `[x]`, commit, continue; on fail: log again, stop, request help.

### Step 7 — Progress Reporting
After resuming and completing a task: `✓ Resumed and completed: Task N` with
files changed, validation result, commit, and the next task. On blocker: `✗ Task
N blocked` with the blocker, action taken, status, and next step.

## Important Notes
- Trust the task list (`[x]` done / `[ ]` pending); verify with git; read
  completion logs; never duplicate work; never skip; assess partial work
  carefully; stop on blockers.

## Error Handling
- Invalid plan structure → report; ask to fix or proceed with caution.
- Missing task file → report; ask whether to skip or create.
- Unclear git state → report findings; ask before proceeding.
- Unresolvable blocker → log in Completion & Log; report; wait for guidance.