DeepWorkPlan — Status

Report the current state of one or more Deep Work Plans — progress, completed tasks, current task, checkpoint, blockers, consistency — without executing or modifying anything, and without loading the whole plan.

Shared resources (read these)

• ../shared/context.sh — resolve dwp_dir.
• ../shared/dwp-paths.md — plans at .dwp/plans/<plan>/.
• Guide (essential — read for this flow): none. Status is a read-only report; it does not load the methodology guide.

Parameter Support

• /dwp-status {plan_name} — check a specific plan.
• /dwp-status latest — check the highest numbered plan, or the most recently modified legacy plan.
• /dwp-status all — check all plans.
• No parameter → interactive scope selection (Step 1).

Normalize the PLAN_ prefix; validate that single plans exist under .dwp/plans/. If not found, show available plans and ask the user to choose.

Lite-aware status

For v2 plans report format, materialization, approval and promotion separately from execution progress. Read them from state.json; fall back to the README's Approval row when the field is absent, and to pending when neither is present. A ready pending-review Lite proposal is valid but not executable. Resolve inline task locators against unique README anchors and count only canonical task-index checkboxes, never fenced examples. Report a missing or duplicate anchor, pending approval, or promotion marker as a finding; do not repair it in this read-only flow.

Trust boundary (write scope)

This skill is read-only by contract. allowed-tools lists Bash (which Trust Hub treats as write-capable in general) — here it is used exclusively for read-only inspection. Status reads plan folders, progress checkmarks, and state.json, and reports; it performs no writes of any kind.

It MUST NOT: modify tasks, progress, state.json or source files; "fix" a plan while reporting on it; or write anywhere. If the status reveals an inconsistency, report it and point at refine/resume — do not repair it silently.

Workflow

Step 0 — Check for Parameters

all → scope "all", skip to Step 2. Otherwise resolve the supplied full name, ID, unique slug or latest with ../shared/plan_paths.py --plans-dir <dwp_dir>/plans resolve <selector>, set scope "single", then go to Step 2. No parameter → Step 1.

Step 1 — Ask for Scope

Use ../shared/plan_paths.py --plans-dir <dwp_dir>/plans list to list plans; the numbered folders appear in numeric order. latest is the highest plan ID when numbered plans exist, or the most recently modified legacy plan otherwise. Offer: a single plan (by ID or name), all plans, or latest. Accept an ID, name, all, or latest.

Resolve a single selection with ../shared/plan_paths.py --plans-dir <dwp_dir>/plans resolve <selector>; accept full names, IDs and unique slugs. If a slug is ambiguous, request the full name or ID.

Step 2 — Gather Status Information (compact projection first)

v6 plans first: a plan folder with a manifest.json contract pointer, contract.json or a contracts/ chain is v6 — its records are the journal, not state.json. Report from the shipped read-only commands, never by re-deriving by hand: python3 ../shared/ledger.py --plan <dir> inspect (events, one line each, torn tails reported); python3 ../shared/scheduler.py ready <dir> (next dispatch, read-only); python3 ../shared/resources.py --plan <dir> report / routing / hold (envelope posture, incl. any exhaustion hold); python3 ../shared/outcomes.py --plan <dir> receipt (recomputed outcome receipt — it changes when the records change). Do not run project or views.py render here — both write, and this flow stays read-only; the state.json already on disk is a v6 projection and may be quoted with its generated_at stamp, marked as derived. Status findings (torn tail, no approval event, projection disagreement) are reported with their suggested repair, never repaired. For a v7 plan, also run python3 ../shared/ledger.py --plan <dir> delegate observe (read-only) and report each delegation's task, transport, addon and state — a completed delegate is still asserted until a gate observes it. Then continue with the README index and consistency reading below (items 2–5 apply unchanged; item 1's state.json is a v6 projection).

For each (non-v6) plan:

1. State first. If state.json exists, read it: status, completed_count / task_count, checkpoint, blocked, updated_at/updated_by, and the per-task status list. This is the compact projection; it is enough for the summary.
2. README index. Read the README's goal, Plan Status line, task list ([x]/[ ], any (re-validate…) markers), **Standard:** line and pre-approval note. When there is no state.json, the README is the only source and the report says so.
3. Consistency check (../spec/PLAN_STATE.md §5): compare README checkboxes with state.json task statuses and completed_count; compare [x] tasks that carry a commit with git log --oneline -20; note a checkpoint whose task is [x], a blocked entry on a [x] task, or a task_count that differs from the number of task files. Every disagreement is a finding (which tasks, which direction, markdown is authoritative) — never an edit.
4. Targeted detail only. Read the last completed task's Completion & Log and the current [ ] task file's title/goal; run git status. Do not read every task file or every gate record.
5. Compute totals and progress %.

Enabled addons (any generation, read-only). Run python3 ../shared/config.py enabled --plan <dir> once per repository: it prints the addon keys the repository's .dwp/config.json (over ~/.dwp/config.json) enables, one per line, and any fail-closed warning on stderr (../spec/CONFIG.md). Report them as one line — addons enabled: none is an ordinary answer, never a finding; the methodology works alone. Never write the file from this flow.

Step 3 — Generate Status Report

Single plan: header with the resolved plan basename and its actual location; standard (and whether pre-approved for unattended execution); goal; progress (total / completed / pending / %); completed tasks; pending tasks; current status (last completed, next task, checkpoint note, uncommitted work, recent commits); enabled addons (one line); blocked (reason, since, needs) if set; consistency findings if any, with the suggested action (resume to reconcile, refine to fix structure); notes from the README; last task log summary; whether an Executive Report was requested/produced.

All plans: a one-line-per-plan summary (progress, status, blocked?, last activity), then the single-plan detail block for each.

Step 4 — Additional Information (optional)

Offer deeper detail for any plan: all task files and status, git diff for uncommitted changes, full last-task completion log, the gate records of one task, any blockers.

Step 5 — Quick Actions

Suggest: resume (/dwp-resume <plan>), execute (/dwp-execute <plan>), refine (/dwp-refine plan <plan>), or open a specific task file.

Status Classifications

Not started (all [ ], no commits) · In progress (mixed, recent activity) · Complete (all [x]) · Blocked (state.json.blocked set or the current task's log has a blocker note) · Stale (no activity for a long time — optional) · Inconsistent (any Step 2.3 finding — reported alongside the classification).

Important Notes

• Read-only: never executes or modifies plans; git status is reported, not committed. Cross-reference the README task list with state.json and git commits for accuracy; the markdown is authoritative when they disagree.
• Cheap by design: the compact projection plus the README index answer the question; task files and logs are read only for the targeted detail above.

Error Handling

• Plan folder doesn't exist → report; list available plans; ask to select.
• README missing, or README says Plan Status: materializing → report a partial materialization; read manifest.json (intended title and task_count) and the README task list when present and list which intended files exist and which are missing; suggest /dwp-refine (complete or discard) or /dwp-create. Never report it as executable.
• state.json unreadable or invalid → report it as a finding; fall back to the README; suggest /dwp-resume (which regenerates it).
• No plans exist → report "No plans found in .dwp/plans/"; suggest /dwp-create.