v5.5.4 to v6.0.0

---

name: deepworkplan-status

description: Report Lite or Full Deep Work Plan status — format, approval, readiness, progress, checkpoint, blockers and Markdown/state consistency — without modifying anything.

documentation_url: https://deepworkplan.com

user-invocable: true

allowed-tools: Bash, Read, Grep, Glob

---

# 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`](../shared/context.sh) — resolve `dwp_dir`.

- [`../shared/dwp-paths.md`](../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. 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 %.

### 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); **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`.