Make a messy workspace navigable, nothing moved till you approve.
A proposed naming convention, folder structure, index, and cleanup plan, shown as a plan first so you see every move.
Inside: The current-state read, the proposed structure, and an approve-per-batch cleanup.
Install it in one line, or paste it in.
~/.claude/skills/ and runs automatically when it is relevant.Connect your context. Set it to your motion.
it reads the actual tree, sizes, and dates, so the cleanup plan is grounded in what is really there.
the new README links into the rest of your context, not just this folder.
it can tell what is genuinely stale from what is just quiet.
This was built for an operator whose workspace grew faster than its structure. Set these to your setup:
The convention and structure are proposals, not decrees. Set the rules; the skill applies them consistently and shows you the result.
| Set this | What it is | Default / Example |
|---|---|---|
| WS_HOME | the workspace being organized | a git repoa shared drivea folder |
| NAMING | the convention to adopt | lower-kebab-casedate-prefixed for logs |
| STRUCTURE | the folder scheme | by typeby projectby lifecycle |
| INDEX | the front door | a README that maps the whole tree |
| ARCHIVE_RULE | what gets set aside | untouched > 180 dayssuperseded files |
| PROTECT | what must never move | anything you name here is off-limits |
Everything the skill does, in full.
Takes a workspace you have lost the thread of, a repo, a drive, a folder, and proposes a way to make it navigable: a naming convention so files are predictable, a folder structure so things have a home, an index or README so there is a front door, and a cleanup plan for what to archive or merge. It shows you the entire plan as a proposal. Nothing moves, nothing is renamed, nothing is deleted until you approve it, move by move.
- 1Read the current state
Inventory what is actually there: the files, the rough types, the obvious duplicates, the folders that became junk drawers. If the real tree is connected, ground this in dates and sizes. If not, work from your listing, and say so.
- 2Propose a naming convention
One convention, applied consistently, beats five clever ones. Propose a single scheme, lower-kebab-case, date-prefixed logs, type or project prefixes, and show it against your actual filenames so you can see the before and after.
- 3Propose a folder structure
A home for each kind of thing, shallow enough to navigate and deep enough to separate. Show the proposed tree next to the current one. Every file in the plan has exactly one obvious destination.
- 4Draft the index
A README that maps the workspace: what each folder holds, where to put a new file, what the conventions are. The index is what keeps the structure from decaying the week after you build it.
- 5Plan the cleanup, do not perform it
List what to archive, merge, or delete, each with a reason and its current path. This is a plan, presented for approval. Nothing is touched. You approve moves in batches, and a protected path is never in the plan at all.
- Nothing is moved, renamed, or deleted without your explicit approval, batch by batch. The default action is to propose, never to execute.
- Every proposed move shows its source path and destination. No file changes location invisibly.
- Nothing is ever deleted outright when it can be archived instead. Destructive moves are the last resort and always named as such.
- Protected paths are excluded from the plan entirely. What you mark off-limits is never proposed for a move.
WORKSPACE PLAN · /projects (proposal, nothing moved yet)
NAMING CONVENTION (proposed)
lower-kebab-case; logs get a YYYY-MM-DD prefix
before: Final_v2 NOTES.docx after: onboarding-notes.md
STRUCTURE (proposed tree)
/projects
/active (current work)
/reference (facts, specs, playbooks)
/archive (superseded, kept for history)
README.md (the map)
CLEANUP PLAN (approve per batch, nothing runs yet)
ARCHIVE Final_v2 NOTES.docx (superseded, 210 days untouched)
MERGE notes.md + notes-copy.md (near-duplicate; keep notes.md)
KEEP /billing (PROTECTED, excluded from all moves)
DO THIS FIRST
Adopt the naming convention on /active. It makes the rest self-sorting.
(this is a plan. approve moves in batches; nothing has changed.)
Where an operator takes this next.
The plan is proposed. Here is where an operator takes it once the manual version proves out.
The plan makes it navigable once; the checks are what keep it that way.
Connect the actual repo or drive so file dates and sizes ground the plan instead of relying on what you remember is in there.
Once you approve a batch, let a scheduled Claude task perform just those moves and log what changed, so approval and execution are not two separate manual steps.
Wire a lightweight check that flags when a new file lands outside the proposed structure, so the README does not go stale the month after you build it.
One skill is the on-ramp.
A single skill does one job. Chained into a playbook, or run as a full build, it becomes a system. Here is where this one plugs in.