Dustoff

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 pr list --state open. Call out open Dependabot PRs separately — they're the clearest dependency-staleness signal. (No gh or no remote? Note it and skip.)

• Deployment posture: detect a deploy target (fly.toml, Procfile, render.yaml, netlify.toml, app.json, Dockerfile, docker-compose.yml, .github/workflows/*deploy*). Report deployed-public vs. local-only. If deployed, flag that live status can't be confirmed from the repo alone — that's a manual check for the plan.

• Dependency staleness — flag, don't fix: a one-line summary is enough (bundle outdated/npm outdated counts, or simply the count of open Dependabot PRs). Do not run updates — that's /update-deps's job and it belongs in the plan, not here.