dustoff

Featured

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.

AI & Automation 422 stars 49 forks Updated 4 weeks ago MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
87
Recency 20%
90
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# 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 `g...

Details

Author
joshukraine
Repository
joshukraine/dotfiles
Created
12 years ago
Last Updated
4 weeks ago
Language
Shell
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Data & Documents Listed

resurrect-project

Investigate and revive a dormant code project — survey existing code as historical signal, interview the user on today's architectural intent, capture decisions, then scaffold a project page and a rewrite plan. Use when the user says "resurrect", "revive", "bring back", "rebuild", or "modernize" an old or dormant code project, references picking up an abandoned codebase, or asks to plan a rewrite of something that already exists. Adapts to host project — conforms to a wiki schema if one is present (CLAUDE.md + projects/ folder + log.md), otherwise emits portable markdown.

0 Updated 1 months ago
brandtam
AI & Automation Listed

refresh-claude-md

Use when the project's CLAUDE.md is stale or missing and must be regenerated from the current codebase — re-detect tech stack, commands, conventions, and structure, then update CLAUDE.md while preserving every human-authored customization. Adapted from the ECC codebase-onboarding skill.

7 Updated 1 weeks ago
pekral
AI & Automation Listed

arch-health

Proactive whole-codebase architecture scan — find shallow modules, leaky interfaces, misplaced seams, layer violations, and ball-of-mud hotspots; present them as a RANKED report; then grill through the one you pick and route it to /refactor or /prepare. Run it every few days to keep entropy in check, before the codebase becomes hard to change. Distinct from /refactor (cleans the current diff on demand) — this scans the whole tree and surfaces what to clean. TRIGGER when: the user wants an architecture health-check, "what's rotting here", "find the worst modules", "where's the tech debt", a periodic ball-of-mud scan, or deepening opportunities. DO NOT TRIGGER when: the user wants to clean up specific changed files (use /refactor), review a diff for bugs (use /code-review), or plan one known change (use /prepare).

2 Updated 1 weeks ago
mik2win