File Management and Project Structure
Session 4.4 · ~5 min read
The Cost of Chaos
Every content producer has done this: saved a file called final_draft.md, then final_draft_v2.md, then final_draft_FINAL.md, then final_draft_FINAL_actually_final.md. This is not a joke. It is the natural result of producing content without a file management system. And when AI enters the picture, the chaos multiplies. Now you have prompt files, output files, reviewed files, and multiple versions of each.
Professional content production requires organized files. Not because organization is virtuous, but because disorganization costs you time, causes errors, and makes your pipeline impossible to scale.
File structure is pipeline architecture. Every folder in your project maps to a stage in your production process. Inputs, prompts, raw outputs, reviewed outputs, finals. If you cannot trace a piece of content from source to publication by following your folder structure, the structure is wrong.
The Standard Project Structure
A production project needs five top-level folders, each representing a pipeline stage, plus a configuration folder for settings and credentials.
Naming Conventions
Consistent file naming is not a preference. It is a requirement. When you have 200 files in a folder, the only way to find what you need is predictable naming. Two rules eliminate most naming chaos.
| Rule | Bad Example | Good Example | Why |
|---|---|---|---|
| Date-prefix outputs | draft.md |
2026-04-02-draft-001.md |
Files sort chronologically, versions are distinct |
| Kebab-case everything | My Blog Post.md |
my-blog-post.md |
No spaces means no escaping in terminal commands |
| Version with numbers | prompt-final.md |
system-prompt-v03.md |
Numbered versions sort correctly, "final" is meaningless |
| Type prefix for prompts | blog.md |
prompt-blog-review.md |
Type is visible without opening the file |
Use leading zeros in version numbers (v03 not v3) so that file sorting works correctly. v10 sorts after v9 only if you use v09.
The README File
Every project root needs a README.md file. This file answers three questions for anyone who opens the project (including future you, six months from now): What is this project? What goes in each folder? How do I run the pipeline?
It does not need to be long. Ten lines is enough. But those ten lines prevent the confusion that accumulates when a project grows beyond what you can hold in your head.
Scaling the Structure
The five-folder structure works for single projects. When you run batch operations producing dozens of pieces, you add a layer: a content-type folder inside each stage folder.
For a project producing both blog posts and product descriptions:
outputs/raw/blog-posts/outputs/raw/product-descriptions/outputs/reviewed/blog-posts/outputs/reviewed/product-descriptions/
The structure grows with the project. Start simple. Add depth only when the flat structure becomes unwieldy. Premature complexity is as harmful as premature optimization.
Further Reading
- How To Use Git to Manage Your Writing Project by DigitalOcean
- Git-Based Content Workflow: Writing, Reviewing, Publishing
- Content Version Control: 5 Essential Tips for Authors
Assignment
Design the folder structure for your first real AI production project. Create it in VS Code. Include folders for: inputs, prompts, raw outputs, reviewed outputs, and finals. Create a README.md in the root that documents what goes where. Name three hypothetical files for each folder using the naming conventions above. This structure will be used for the rest of the course.