scratch-cleanup
Skill5 starsChanged 10 days agoMITView on GitHub
Sweep a dusty .scratch/: file research into docs/, remove finished efforts, and report the work still open.
In this repository57 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- architecture-satisfactionSkill
- autopilotSkill
- browser-testSkill
- chatter-scoutSkill
- closeoutSkill
- codebase-designSkill
- code-reviewSkill
- code-smells-auditSkill
- commitSkill
- dependency-auditSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- fix-ci-failuresSkill
- fix-github-issuesSkill
- fix-nightwatch-issuesSkill
- fix-posthog-issuesSkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- harness-toolsSkill
- housekeeperSkill
- implementSkill
- implement-specSkill
- improve-codebase-architectureSkill
- laravel-herd-worktreesSkill
- panelSkill
- prototypeSkill
- prSkill
- prune-testsSkill
- releaseSkill
- repository-cleanupSkill
- researchSkill
- resolve-review-commentsSkill
- resolving-merge-conflictsSkill
- retroSkill
- run-afterSkill
- scratch-statusSkill
- setupSkill
- sweepSkill
- tddSkill
- teachSkill
- to-questionnaireSkill
- to-specSkill
- to-ticketsSkill
- triage-github-prSkill
- triageSkill
- ui-designSkill
- upgrade-planSkill
- verifySkill
- wait-whatSkill
- wayfinderSkill
- which-skillSkill
- wizardSkill
- writing-for-agentsSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 21
done: every artifact (map, decisions, spec, tickets/issues, requests) is closed or wontfix, every cited commit is on default_branch, and …
- Very specific: line 50
Stage: every changed path by explicit path (git add -- <path> …).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Scratch Cleanup
.scratch/ is an inbox, not an archive. Everything in it ends one of three ways: filed (research that belongs in docs/), removed (an effort whose work is all done), or kept (work still open, listed in the report). Nothing changes on disk until the user approves the plan.
The stale threshold is $ARGUMENTS days; 30 when empty.
1. Inventory and judge
From inside the repository, run ../scratch-status/scripts/scratch-state.sh --days <threshold> once.
The script walks .scratch/, checks git tracking (tracked and untracked_files) and last-change dates (last_change), resolves status and blockers in both frontmatter and legacy Status: dialects, verifies every cited ticket commit against default_branch (git merge-base --is-ancestor, merged PRs via gh api, git cherry, and commit subject match), and sorts .scratch/ into three buckets:
efforts: each.scratch/<slug>/directory, classified as:- done: every artifact (
map,decisions,spec,tickets/issues,requests) is closed or wontfix, every cited commit is ondefault_branch, andmismatchisnull. - mismatched: has an unreadable status (
unreadable_effortsormismatch) or a contradiction (e.g.,specstillready-for-agentwhile every ticket is closed, or a closed ticket whose cited commit is missing). Goes in the plan as a question, never a removal. - open: has any open file, with
stale: truewhen its newest file is older than--days. Anyclaimed_byin a stale effort is a stale claim to release in step 3 (the session is gone); leave its status alone.
- done: every artifact (
research: findings files under.scratch/research/or loose.mdfiles ending in What this unblocks.unclassified: everything else outside an effort (wizards, loose notes, questionnaires, and.DS_Storeentries markedjunk: true, which go in the plan as deletions with no question).
Done when scratch-state.sh has returned the bucketed inventory and effort judgements.
2. Plan
Build the plan for every bucket:
- Research: pick a destination under
docs/. Match an existing topic folder (docs/<topic>/) when one fits the subject; otherwise usedocs/research/<same-filename>. When two folders fit, or none fits and the subject clearly belongs to a topic that does not exist yet, list the choice as a question. Find every inbound link (rg -n --fixed-strings '<old path>'across the repo,.scratch/included) so the move can rewrite each one. - Done effort: read its spec, map, and closed decision tickets for lasting decisions: choices that are hard to reverse, still true in the code today, and whose reasons live nowhere else. List each as a one-line ADR candidate. Then list the effort for removal (separating tracked paths from
untracked_files). - Mismatched effort: state
mismatchin one line and what would settle it. - Unclassified: one line per non-junk file saying what it looks like and a proposed fate (file, remove, or keep).
Show the plan in one message, with these sections in order: File (research moves and link rewrites), ADR candidates (numbered, so the user can pick by number), Remove (committed paths), Remove: cannot recover (untracked paths, with a note that git holds no copy), Questions (mismatched efforts, unclear destinations, unclassified files), and Keep (the report table from step 4). Ask for approval with a structured question (harness-tools), otherwise in chat. The untracked removals need their own explicit yes, separate from the rest of the plan.
Done when the user has approved, trimmed, or rejected each section, and has answered every question.
3. Apply
Apply only what the user approved, in this order:
- ADRs first, while the source files still exist: write each picked candidate as an ADR through the
domain-modelingskill's format and location (docs/adr/in a single-context repo). - File research:
git mvfor tracked files,mvfor untracked ones, creatingdocs/folders as needed. Rewrite every inbound link found in step 2 to the new path. - Remove:
git rm -r -- <path>for committed efforts and files;rmfor approved untracked ones and.DS_Store. - Release stale claims found in step 1.
- Stage every changed path by explicit path (
git add -- <path> …); leave the commit to the user.
Done when rg -n --fixed-strings finds no reference to any moved or removed path, and git status --short shows only the approved changes.
4. Report
End with the table of everything that stayed in .scratch/, one row per effort or kept file:
| Effort | Open work | Blocked by | Last change | Stale | Next |
.scratch/<slug>/ | open ticket or decision files, by number | open blockers, or the question the user left open | date | yes/no | the skill that moves it forward (/implement <ticket>, /wayfinder <map>, /to-tickets <spec>) |
Under the table, give one line each for: files filed (old → new path), ADRs written, paths removed, claims released. Then suggest /commit for the staged changes.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

