To plan file renaming with AI, provide an inventory, define a naming rule, and ask for an old-to-new mapping before changing anything. Review ambiguous dates, missing version information, and duplicate target names. A tidy-looking list is only useful if each proposed name still identifies the right file.
This guide uses seven fictional files in one folder. The inventory and proposed mapping are an original editorial exercise, not a live AI benchmark. No files are renamed by following the prompt alone.
1. Define what each part of the filename means
For a fictional Atlas project, use this convention for ordinary working documents and images:
YYYY-MM-DD_atlas_topic_vNN.extension Example: 2026-10-04_atlas_brief_v01.pdf
- Date: the verified document or capture date, not today’s date and not an inferred download date.
- Project: atlas for every file in this exercise.
- Topic: a short, approved label such as brief, notes, or item-007.
- Version: two digits copied from verified version information.
- Extension: preserve the existing extension exactly; renaming is not format conversion.
Lowercase topic labels and underscore separators are choices for this project, not universal requirements. Decide the vocabulary before generating a large batch. For instance, meeting-notes and minutes may sound interchangeable but should not alternate randomly if you expect to search by topic.
The pattern fits this small collection because every eligible item has a known date and version. For a mixed archive where those fields are often unknown, choose a different convention rather than filling gaps with invented values.
2. Give AI an inventory with verified facts
Use a stable row ID and the exact current name. In a real collection spanning multiple folders, include each full source path and intended destination folder. Two files called notes.docx in different folders are different inventory entries.
Here is the fictional input. All seven files stay in their current folder. Dates and versions below are supplied facts for the exercise; they are not inferred from the file contents.
- F1 — Atlas brief final.pdf: date 2026-10-04; topic brief; version 01.
- F2 — Atlas brief copy.pdf: date 2026-10-04; topic brief; version 01. Relationship to F1 is unknown.
- F3 — Notes 03-04-2026.docx: topic notes; version 01. Date could mean March 4 or April 3; no locale is supplied.
- F4 — Workshop notes.docx: date 2026-10-05; topic notes; version 02.
- F5 — Cover approved.png: date 2026-10-04; topic cover; version 01.
- F6 — 2026-10-04_atlas_cover_v01.png: already follows the convention. Relationship to F5 is unknown.
- F7 — Item 007.jpg: date 2026-10-04; topic item-007; version 01. The identifier 007 must retain its leading zeros.
An inventory usually gives the model enough information to propose names without uploading file contents. Replace confidential names with consistent placeholders if the real labels are unnecessary for the exercise.
3. Request a proposal with explicit hold states
Create a file-renaming proposal for the inventory below. Rule: YYYY-MM-DD_atlas_topic_vNN.extension. Use only the verified date, topic, and version supplied. Preserve each extension exactly and preserve identifier 007. Return every row ID, exact old name, proposed name if determinable, status, and reason. Use READY, HOLD, or UNCHANGED. HOLD any ambiguous date, missing required fact, duplicate proposed target, or target occupied by another existing file. Treat names that differ only in letter case as a collision for this Windows-oriented plan. If multiple rows collide, flag every affected rename. Do not infer that copy means duplicate, final means latest, or approved means version 02. Do not append numbers to hide conflicts. Do not delete, merge, overwrite, move files, or generate an execution command. Inventory: [Paste the verified inventory and all existing destination names here.]
The destination inventory matters even when a file is not being renamed. A proposal that checks only its own new names can miss a name already occupied in the folder.
4. Inspect the mapping before accepting it
Applying the stated rules gives the following expected review result. “Candidate” means a name can be constructed; a HOLD row is not approved for renaming.
| ID | Candidate name | Result |
|---|---|---|
| F1 | 2026-10-04_atlas_brief_v01.pdf | HOLD: same target as F2 |
| F2 | 2026-10-04_atlas_brief_v01.pdf | HOLD: same target as F1 |
| F3 | Not determined | HOLD: date ambiguous |
| F4 | 2026-10-05_atlas_notes_v02.docx | READY |
| F5 | 2026-10-04_atlas_cover_v01.png | HOLD: occupied by F6 |
| F6 | 2026-10-04_atlas_cover_v01.png | UNCHANGED: already correct |
| F7 | 2026-10-04_atlas_item-007_v01.jpg | READY |
The result is two READY, four HOLD, and one UNCHANGED. F6 does not need a rename, but its existing name blocks F5. Neither F1 nor F2 can be selected as the winner from the supplied facts.
Resolve F1 and F2 by checking what the files actually represent. If they are separate revisions, confirm the correct versions. If they are different documents, assign meaningful, approved topic labels. A duplicate name proposal does not prove duplicate content, and a collision is not a reason to delete a file.
For F3, ask the owner or check a reliable source for the date. For F5, establish its relationship to F6. Leave unresolved files as they are, then regenerate and recheck the complete proposal after any correction.
5. Check names against the destination environment
Microsoft’s file and path naming documentation describes reserved characters and names, warns against assuming case sensitivity, and explains that Windows shell names should not end in a space or period. For example, a colon in a date-style name is unsuitable, and NUL.txt remains reserved despite its extension.
Check the full destination path as well as the final filename: applicable length limits can depend on the file system and application. Cloud storage and shared workspaces may add their own restrictions. A model’s statement that a name is “Windows compatible” is not a substitute for checking your actual destination.
6. Test a small batch and keep the mapping
Before applying approved changes, keep a recoverable copy and save the reviewed mapping outside the batch. Close files being edited. Try a small set of READY rows on copies first, confirm the renamed files open, and check any documents or workflows that refer to the old names.
Keep an execution record of which changes actually succeeded. The proposal alone is not a reliable undo log if only part of a batch completed. Stop when a target unexpectedly exists or a file differs from the reviewed inventory; refresh the plan instead of overwriting.
Once the pilot is correct, apply the remaining approved rows with a tool that previews changes and reports failures. Keep HOLD rows excluded. If your inventory itself contains inconsistent IDs or missing fields, the guide to cleaning spreadsheet data with AI offers a separate review workflow before you generate names.