/dustoff

name: dustoff
description: Assess a project that's been dormant for months and produce a prioritized re-entry plan — lifecycle stage, what's stale or broken, and how far the project's tooling has drifted from current conventions — delegating every fix to the skill that owns it, and optionally capturing the plan as a tracking issue that survives sessions.
disable-model-invocation: true

Dust Off

Take stock of a project that's been sitting untouched for months and produce a single, prioritized **re-entry plan** for getting it back into active development. Dependencies have fallen behind, tests may be broken, and the project's adopted conventions have probably drifted from the current `~/.claude` toolset. This skill assesses all of that and tells you, in priority order, what to do first — but it does not do the work itself.

It is **read-only with respect to the codebase**, and advisory. It inspects, reports, and recommends; it never updates dependencies, edits project files, marks ROADMAP checkboxes, or writes code. Its one deliberate write is optional and opt-in: capturing the finished plan as a tracking issue (or a `DUSTOFF.md`) so it survives the session — see step 5. The deliverable is a plan, and every item on that plan names the existing skill (or manual step) that acts on it.

**Where it sits in the workflow.** This is the _first_ thing you run when returning to a dormant project — before picking up an issue, before `/plan-phase`, before any new work. Its output feeds the normal cycle: a clean assessment hands off to `/update-deps`, `/readme-refresh`, `/plan-phase`, and `/resolve-issue` to actually execute the catch-up.

**Applicability.** Works in any repo. It reads both the **project** (the working directory) and the **current conventions** under `~/.claude` to measure drift between them. It degrades gracefully — no PRD, no README, no CI, or no `gh` are all handled, with the relevant phase noting what it couldn't check rather than failing.

**Not the same as:**

• `/checkpoint` — that's mid-stream orientation: a 2-minute hallway update that _assumes you already know where you are_ in an active push. This is the sit-down re-entry assessment for when you _don't_ — you've been away for months and need to re-derive the project's state, staleness, and lifecycle stage from scratch.
• `/update-deps`, `/readme-refresh`, `/plan-phase` — those _do_ the work (update dependencies, fix the README, create issues). This one only _flags_ the need and hands off. Delegate; don't duplicate.
• `/drift-check` — that checks a branch diff against the project spec before a PR. This checks the whole project's adopted _tooling and conventions_ against the current `~/.claude` standard at re-entry. Different drift, different scope.

The core guardrail

The output is a plan, not a fix — dustoff routes work to other skills, it doesn't perform it. (Capturing the plan as a tracking issue in step 5 is the one write it makes, and only when you approve it.) The one-line test for any step you're tempted to add or take: _"Does this belong to re-entry assessment, or am I about to re-implement `/update-deps` (or `/readme-refresh`, or `/plan-phase`)?"_ If it's the latter, stop — flag it as a plan item and hand off. The value of this skill is the synthesis, not the mechanics it would otherwise duplicate.

Your task

Work through the five steps below. Steps 1–4 are read-only; step 5 is the one optional, opt-in write (capturing the plan). Gather findings as you go and present a **single consolidated re-entry plan** at the end of step 4 — not a separate report per step. If the working directory isn't a git repository, say so and stop; there's no dormant project to dust off.

1. Orient — how dusty, and where in the lifecycle

• **Dormancy duration**: `git log -1 --format=%cd --date=short` for the last commit date; `git log -20 --format='%cd %s' --date=short` to see the cadence before it stopped (steady work that abruptly halted reads differently than a project that was always sporadic).
• **Read the project's own account of itself**: the project `CLAUDE.md`, `docs/prd/ROADMAP.md` (if present), and the `README`. Don't trust them as current — they're inputs to assess, not ground truth.
• **Determine the lifecycle stage** per the handbook (`~/.claude/docs/prd-workflow/spec-driven-development.md` §6 "PRD Lifecycle") and **state it explicitly with evidence**:
• **Greenfield** — building against the spec; ROADMAP checkboxes are the active work queue, many unchecked.
• **MVP-complete (transition)** — all ROADMAP phases marked complete; new work coming from issues; living docs starting to take over from the PRD.
• **Mature** — issue-driven; PRD is historical; living docs are authoritative.
• Evidence to cite: ratio of checked-to-unchecked ROADMAP items, whether work flows from the ROADMAP or from issues, presence of living docs (domain model, runbooks), and the CHANGELOG's activity.
• **No PRD?** Place the project from git history, the README, and any living docs instead. The lifecycle question still applies — it just measures against whatever authoritative reference exists.

2. Take stock — read-only health

Detect before you assume (the `/update-deps` and `/readme-refresh` approach): identify the package manager, the test/lint commands, the CI workflow, and the boot command from what the repo actually contains. Prefer a single project gate (`bin/ci`, `bin/test`, `script/test`, a `Makefile`/`Justfile` target) over guessing individual runners.

• **Health check** (report-only — never fix here): run the tests, the linter, and a boot check. Report results in the compact `/checkpoint` format:

  Tests:   <pass/fail counts, or "couldn't run — <reason>">
  Linting: <clean / N issues / couldn't run>
  Boot:    <boots OK / fails — <error> / not checked>

If a command isn't discoverable, say what you looked for rather than inventing one.

• **Open work**: `gh issue list --state open` and `gh