# Dustoff > 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. - Skill: `joshukraine/dustoff` (Agent Skill) - Install (CLI): `npx skillmds@latest add joshukraine/dustoff` - Raw SKILL.md: https://api.skillmd.com/api/skills/joshukraine/dustoff/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: joshukraine (https://skillmd.com/u/joshukraine) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/joshukraine/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: ```text Tests: "> Linting: Boot: / 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. ### 3. Toolset / convention drift This is the check no off-the-shelf tool does: how far has the project's adopted tooling fallen behind the **current** conventions, given that `~/.claude` itself keeps evolving? Read the current standard, then compare the project against it. Keep every finding **concrete** — name the specific missing block or file and the skill/template that closes the gap. No vague "things may have changed." - **Read the current standard** under `~/.claude`: the bootstrap templates (`~/.claude/docs/prd-workflow/templates/CLAUDE.md` and `templates/prd/`), the handbook (`spec-driven-development.md`), and the skills directory (`~/.claude/skills/`). - **CLAUDE.md markers**: compare the project's `CLAUDE.md` against the current template. Flag marker sections the template has that the project lacks (e.g. a `## QA Publish Target` block), and conventions that have since changed. - **PRD structure**: if `docs/prd/` exists, check it against the current expected structure — `README.md` (nav hub), `ROADMAP.md`, `CHANGELOG.md` (deviation log), numbered feature files. Flag missing pieces (a PRD with no CHANGELOG predates the deviation-log convention). - **Skill/workflow evolution (heuristic, framed softly)**: use git history to date the last skill-driven activity and flag where it predates a current capability — e.g. "the last dependency PR (#84, ~5 months ago) predates the Dependabot-aware `/update-deps`; a fresh run is worth it." Frame these as _worth re-running_, not as asserted facts about exact dates you can't verify from inside the project. ### 4. Synthesize — the re-entry plan Fold everything into **one prioritized, housekeeping-first plan**. This is the whole point of the skill. Order strictly by what unblocks new development: 1. **Critical / broken** — failing tests, security advisories, a broken boot. These block new work and come first. 2. **Stale housekeeping** — dependency updates, README drift, convention catch-up from step 3. 3. **Reorientation** — where you left off (the last in-flight ROADMAP item or open issue) and the recommended next development step. Every item **names the action to take on it** — a skill invocation or an explicit manual step: ```text Re-Entry Plan — (dormant ~, ) ================================================================ Critical (do first — blocks new work): ✗ 3 failing tests in spec/models/order_spec.rb → investigate before anything else ✗ bundler-audit reports CVE-2026-xxxx in nokogiri → /update-deps (security) Housekeeping: ⚠ 4 open Dependabot PRs, deps ~5mo stale → /update-deps ⚠ README says Rails 7.1; Gemfile.lock shows 8.0 → /readme-refresh ⚠ CLAUDE.md missing '## QA Publish Target' block → review against current template ⚠ docs/prd/ has no CHANGELOG.md → adopt current PRD convention Reorientation: • Lifecycle: MVP-complete transition (all 5 phases marked, work is now issue-driven) • Last in flight: issue #42 "export to CSV" (branch exists, no PR) • Suggested next step: run the §6 MVP-transition checklist, then /plan-phase for new work • Deployed at fly.io — confirm the live app still boots (manual) ``` The plan is the deliverable. Present it in full — then move to step 5 to decide how to keep it. ### 5. Persist the plan — so it survives the session A long-dormant project's plan can run to a dozen items across several sessions; don't let it scroll off the terminal. After presenting the plan, offer to capture it. This is the skill's one write, and it's opt-in: - **Default offer — a tracking issue.** File the plan as a single GitHub issue (title like `chore: dust off `), with a tiered checklist body (from step 4) where each item is a `- [ ]` so progress is visible ("3 of 9") and checkable across sessions. Apply the `chore` label **if it exists** (`gh label list`) — don't assume it does. If it's absent, create it or file without a label rather than letting `gh issue create --label` error out; the title convention is what the refresh step keys on, not the label. Add it to the project board if one exists (`gh project list`, or per `CLAUDE.md`). - **Resume, don't duplicate.** Before creating, search for an existing open dust-off issue by the title convention (`gh issue list --search "dust off in:title" --state open`). If one exists, offer to **refresh** it — reconcile new findings, preserve already-checked items — rather than open a second. - **No `gh` or no remote.** Fall back to writing a `DUSTOFF.md` at the project root with the same checklist. Same survives-the-session benefit, no GitHub dependency. Ask whether to commit it (durable, shared with collaborators) or add it to `.gitignore` (a private scratch worklist) — don't leave it as a silent untracked file. - **Decline path.** If the user wants it terminal-only, that's fine — leave the plan on screen and stop. Whichever way it's captured, **stop there** — do not start executing the plan. Offer to kick off the top item (e.g. "Want me to start with `/update-deps`?") and let the user choose. The discrete new-work items (a discovered bug, failing tests with no obvious cause) become their own issues when you pick them up — via `/plan-phase` or the owning skill — and the tracking issue links to them. Dustoff doesn't file those itself. ## Tone - You're a senior developer giving an executive an honest re-entry assessment after a project sat idle. Lead with what's broken; don't bury bad news under qualifications. - Be concrete about drift — a named missing block beats "your config might be out of date." - Right-size every finding. You're flagging and routing, not solving. If you catch yourself running the full `/update-deps` analysis, you've crossed the line — flag it and move on.