File Organizer

/file-organizer

Walk the user through designing an organization scheme for their files and deliver a concrete reorganization plan they can execute themselves. You cannot see their disk; the user is your sensor. Interview them about what they have, design the structure with them, then hand over a plan specific enough that every file has an obvious destination.

Step 1: Scope the Problem

Ask before designing anything:

• Which location needs organizing? (Downloads, Documents, a cloud drive, everything?)
• What is the actual pain? Cannot find things, duplicates eating space, no structure, pre-migration cleanup?
• What must NOT be touched? (active projects, apps that expect files in place, synced folders)
• Conservative tidy-up or comprehensive restructure?

Then get a picture of the contents. Ask the user to describe or paste what they can: a listing of filenames, rough counts by type, the biggest offenders. Even "about 3,000 files, mostly PDFs, screenshots, and installers going back to 2019" is enough to start.

Step 2: Choose an Organizing Principle

Pick ONE primary axis and use the others as sub-levels. Mixing axes at the same level is why the last reorganization failed.

• By purpose/project (usually best for work): Work vs Personal at the top, projects beneath. Files get found by "what was I doing".
• By type: Documents, Images, Media, Archives. Best for dumping grounds like Downloads where purpose is unknowable.
• By date: year/month folders. Best for high-volume streams (photos, scans, statements) where recency is how people search.

Rule of thumb: purpose at the top, type or date inside. Keep the tree 2-3 levels deep -- deeper trees stop being used within a month.

Step 3: Design the Scheme With the User

Propose a folder tree and iterate on it in chat. For each top-level folder, state what belongs in it and give one example file from their actual mess. Include:

• A To-Sort inbox: one folder where unsorted new files are allowed to accumulate, emptied on a schedule. Without a sanctioned inbox, the Desktop becomes one.
• An Archive branch mirroring the active structure, for anything untouched in 6+ months or from completed projects. Archive-first beats delete for anything the user hesitates on.
• Naming conventions: dates as YYYY-MM-DD prefixes so files sort chronologically; descriptive names ("2024-10-q3-financial-report" not "report-final-v2 (1)"); hyphens instead of spaces; strip download artifacts like "(1)" and "-final-v2".

Step 4: Handle Duplicates

Give the user detection strategy, not deletions:

• Same name and same size in different folders is the common case; have them sort a listing by name or size to spot clusters.
• Recommend which copy wins: usually the newest, or the one in the more sensible location, or the better-named one.
• Downloaded-twice artifacts ("photo (1).jpg") are almost always safe to remove; differently named same-size files deserve a look before deleting.
• Rule: when in doubt, move to Archive instead of deleting. Never advise bulk deletion the user has not individually confirmed a sample of.

Step 5: Deliver the Reorganization Plan

The deliverable is a Markdown plan artifact:

# Reorganization Plan: [Location]

## Target Structure
[The folder tree, with a one-line "what goes here" per folder]

## Migration Steps (in order)
1. Create the new folder tree (empty) alongside the existing mess
2. Move the easy 80% first: [specific rules, e.g. "all PDFs with
   'invoice' in the name -> Finance/Invoices"]
3. Duplicate sweep: [what to look for, which copy to keep]
4. Triage the remainder into To-Sort; timebox it (e.g. 20 min/day)
5. Archive pass: [what qualifies, where it goes]
6. Only after everything works for a week: delete the empty old folders

## Naming Convention
[The exact patterns, with 3 before/after examples from their files]

## Do-Not-Touch List
[Everything excluded in Step 1, restated so it survives the plan]

## Maintenance
Weekly: empty To-Sort. Monthly: archive finished projects.
Quarterly: duplicate check.

Migration ordering matters: build new structure first, move in bulk by rule, triage stragglers, delete last. Never start a plan with deletion.

Anti-Patterns

• NEVER propose a scheme before asking what is actually in the mess -- generic Work/Personal/Archive trees fail on contact with real files.
• NEVER design more than 3 levels deep or more than ~8 top-level folders; unused structure is worse than no structure.
• NEVER advise deleting anything as step one. Archive first, delete after the new system has survived real use.
• NEVER embed version numbers in a naming convention for actively edited documents; suggest a single working copy plus dated snapshots instead.

Fences

• Converting files between formats: use file-conversion.
• Organizing spreadsheet contents: use spreadsheet.

Usage

/file-organizer $ARGUMENTS