Workflow Wednesday · AI Pro Writers Studio

Workflow Wednesday

My File System Was a Disaster. Here's the One I'm Building to Replace It.

I want to be upfront about something before I get into this: what follows is not a finished system I've been running for years and am now generously revealing to you. It's the system I'm actively building right now, because the old one finally broke under its own weight.

Here's what broke it. I went looking for a cover concept file from an earlier book. It wasn't in the book folder. It was in a "Graphics" folder from eight months ago that also had three other books' covers in it, none labeled clearly enough to tell them apart at a glance. The marketing copy for that same book was in a completely different folder tree, because I'd started using a new tool partway through and never went back to reconcile the old stuff. Fifteen minutes of searching for one file I knew existed. That's the tax you pay for not deciding on a structure up front, and I'd been paying it quietly for a long time.

So I sat down and asked the obvious question: what's actually going in these folders, and what's the smallest set of rules that keeps it findable six months from now when I've forgotten the details?

The core idea: Projects is the top, then everything nests by type

Books aren't the only thing I'm keeping track of. There are coding projects, there's a growing pile of AI prompts and skill files, there are short stories that don't need the full novel treatment, and there's a permanent junk drawer of half-formed ideas that aren't committed to anything yet. Trying to organize all of that around "books" was the first mistake, because a lot of my actual work isn't a book.

So the true top level is just **Projects**, full stop. Not around the tool that made something, not around the date, not around whether it's "writing stuff" or "marketing stuff." Whatever kind of thing it is, fiction or code or a stray idea, it lives inside its own project folder, not scattered across whatever pile happened to be open when I made it.

That gives you a tree that looks roughly like this:

```

Projects/

├── 01_Books/

│ ├── Series/

│ │ └── [Series Name]/

│ │ ├── 00_Series_Bible/ series-wide continuity, timeline, canon

│ │ ├── 00_Series_Branding/ shared cover style, fonts, palette

│ │ ├── Book_01_[Title]/

│ │ │ ├── Manuscript/

│ │ │ ├── Story_Bible/

│ │ │ ├── Cover_Art/

│ │ │ ├── Marketing/

│ │ │ ├── Social/

│ │ │ ├── Merch/

│ │ │ └── Metadata/

│ │ │ └── Old/

│ │ └── Book_02_[Title]/ ...

│ └── Standalones/

│ └── [Book Title]/ (same structure as above, one level up)

├── 02_Short_Stories/

│ └── [Story Title]/

│ ├── Manuscript/

│ ├── Cover_Art/

│ └── Marketing/

├── 03_Ideas/ loose concepts, not a real project yet

├── 04_Coding_Projects/

│ └── [Project Name]/

├── 05_AI_Prompts/

│ └── [skill files, prompt libraries, reusable machinery]

├── 06_Brand_Assets/ logo, fonts, brand guide for the whole imprint

└── 07_Templates/ reusable output templates

```

The first fork under Projects is project *type*, because a coding project and a book series don't share a shape and shouldn't be forced into one. Books split further into Series and Standalones, since a series has stuff that belongs to *all* the books in it, a bible, shared branding, and that needs to live one level up so I'm not hunting through Book 3's folder for a fact that's true of the whole world. Short stories get a lighter version of the same idea, three folders instead of seven, because a 4,000 word story doesn't generate a Merch folder. Ideas stays deliberately loose and flat, it's the holding pen for anything that hasn't earned real project status yet, book or otherwise, so a stray concept doesn't force me to invent a folder tree for something that might not survive the week.

Below the book level, every book folder has the same seven subfolders, in the same order, every time. That repetition is the whole point. I don't want to think about where something goes. I want the folder name to already answer the question.

What goes where, in formats

I'm settling on this split, mostly because it matches what each type of file is actually for:

- **Manuscript drafts** stay in .docx while they're being worked. It's still the format every editor, beta reader, and formatting tool expects without conversion.

- **Story bibles, character notes, series canon, and anything that's reference material rather than prose** goes in markdown. It's plain text, it's easy to search across a whole project with a simple tool, and it doesn't carry the formatting baggage of a Word file when all I need is the information.

- **Finished, reader-facing deliverables** go out as .epub and .pdf. Those are the formats that leave the building, so they get their own clearly final home instead of living next to twelve draft versions.

- **Graphics, covers, and social assets** are .jpg and .png. Source files if I have layered versions, exports for actual use.

None of this is exotic. The value isn't in the formats themselves, it's in not having five books that each made a different choice about where the "final" version lives.

## Local first, cloud as the safety net

I'm working local drive first, cloud as backup, not the other way around. The reasoning: editing against a synced cloud folder in real time can introduce lag and occasional sync conflicts on large files, and I'd rather not find that out in the middle of a chapter. So the working copy lives locally, and a cloud layer backs it up.

I haven't locked the exact backup mechanism yet, and I'd rather be honest about that than pretend I have. The two directions I'm weighing: a straightforward mirrored sync through a drive I already use for other parts of the business, which is low effort and gives me access from other devices, or a dedicated backup service that runs on its own schedule and isn't also my working folder. Likely I end up doing both, sync for accessibility and a separate backup for the "what if everything local dies at once" scenario.

There's a concrete technical reason to keep the working copy local rather than editing straight against a synced Google Drive or OneDrive folder, and it's not just about lag. Both services have a streaming or on-demand mode where the file you see in your file browser is really just a placeholder, a name and an icon, with the actual bytes only pulled down when something opens it. Agentic tools working directly on the file system, Cowork included, can struggle to read those placeholders, and on some setups editing a placeholder file has silently overwritten the real cloud copy with a truncated stub instead of the full content. That's not a risk I want anywhere near a manuscript. Keeping the folders truly local, and switching any Drive or OneDrive folder I do use to full "always keep on this device" mode rather than streaming, sidesteps the whole problem. If you've got a backup setup you trust, I'm genuinely curious what it is.

Where Cowork fits into this

This is the part that made getting the structure right feel urgent instead of just tidy. Claude Cowork works directly against files and folders on the desktop, which means it can navigate this exact tree and act inside it. A generated cover concept can land straight in `Cover_Art/`. A finished blurb can get filed into `Marketing/` on its own. Story Bible content in `Story_Bible/` becomes something an agent can pull as context without me first assembling a packet by hand.

None of that works if the folders are inconsistent. An agent filing things into a structure that changes shape every project just recreates the mess faster than I could make it by hand. The folder discipline is what turns "AI helps with my writing" into "AI can actually operate inside my business," and that's a bigger shift than it sounds like, and it's not limited to the books. The same logic holds for `04_Coding_Projects/` and `05_AI_Prompts/`, an agent working inside a consistent structure can file a script into the right project or a new skill file into the right prompt library just as cleanly as it can file a cover concept.

Teaching the structure its own rules

The folder tree handles where things go. It doesn't handle the rules for how things get made, so I'm adding a CLAUDE.md file into the mix. It's a plain markdown file that Claude reads automatically at the start of a session and treats as standing instructions, the kind of thing I'd otherwise have to repeat every single time. No em dashes, drafts stay in .docx, bibles stay in markdown, that whole list of house rules lives in one file at the root of `Projects/` instead of in my head. I'm considering a second one at the series level, for rules that are true of one world specifically and nowhere else.

Cowork projects also build up their own memory on top of that as we work, separate from whatever's written explicitly in CLAUDE.md.

Here's the honest limitation, since it was the obvious next question once I had two machines in the picture. Can that CLAUDE.md file, or the memory Cowork builds up, travel to a second machine through the same cloud backup holding everything else? Right now, not automatically. Cowork projects are stored locally on whichever machine created them, and there's currently no built-in cloud sync for that project data. Open the same folder on a laptop and Cowork doesn't already know what it picked up on the desktop.

The workaround is to treat CLAUDE.md like any other file in the project, it rides along inside the folder, backed up the same way the manuscript and the cover art are. Pull that folder down fully, not streamed, on the second machine, and the written rules travel with it. The accumulated project memory is a murkier case, and for now I'm assuming that has to rebuild itself on each machine rather than something that follows me around on its own.

What's still unresolved

I haven't migrated the existing chaos into this yet, that's a separate and frankly more annoying project. I don't have a naming convention locked for the files inside each folder, just the folders themselves. And a structure only works if I actually follow it every time instead of dropping something on the desktop because I'm in a hurry, which is a discipline problem, not a folder problem.

If you've got a system that's actually survived contact with a real backlist, multiple series, and the marketing sprawl that comes with them, I'd like to hear how you built it. This is very much a working draft.

5 comments

Workflow Wednesday