Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →joshukraine/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.
Passed 5 of 13 test cases with the skill, and 8 of 13 without it.
and 1 more in the full report
3 fixed2 passed either way12 still failing5 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
When saving the re-entry plan as a GitHub tracking issue, how do you handle label assignment?
| Checked | Without skill | With skill |
|---|---|---|
| The response checks if the chore label exists in the repository before passing it to gh issue create. | Missed | Passed |
The instructions your model reads when the skill loads.
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 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.
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.
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).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.~/.claude/docs/prd-workflow/spec-driven-development.md §6 "PRD Lifecycle") and state it explicitly with evidence:
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.
/checkpoint format:test cases passed, vs 8 / 13 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.