Where would you look for it?
A file can belong to three sensible categories. It still needs one place to live.
Where does the lighting plan go: in Design, Technical, or Opening night?
All three answers are defensible. That is the problem with organising files by inventing a perfect set of categories. Real work is inconsiderate enough to belong to several of them.
A more useful question is: what will you be doing when you need this file again? For a small theatre production, you are likely to look for the production first. Within it, Lighting plan.md is a much stronger clue than a third layer of folders.
Give the work a home before giving it departments
A project folder can start almost embarrassingly small:
The Tempest/
Production notes.md
Lighting plan.md
Rehearsal changes.md
Programme copy.md
These files differ in subject and purpose, but they will be used, handed over and eventually put away together. That shared lifetime makes the production a useful boundary. Someone looking for the programme need not remember whether you classified it as marketing or publishing.
This is one advantage of keeping ordinary Markdown files: their homes can be ordinary folders. You can reason about where the work belongs without first deciding which application’s internal collection should own it.
The arrangement need not stay flat forever. If the production accumulates twenty rehearsal reports, a Rehearsals folder earns its place. A folder with one file in it may be useful too, but it deserves a reason beyond looking organised.
Names do work that folders cannot
Consider two versions of the same listing. One contains Notes.md, Notes 2.md and Updated notes.md. The other contains Rehearsal 2026-10-14.md, Lighting cues.md and Questions for the venue.md. The second tells you something before you open a document.
A date is useful when the date is part of the identity: meeting notes, a field visit, a daily log. It is less useful when it merely records the last time you renamed a living plan. A continuing lighting plan can remain Lighting plan.md; its current contents should make its status clear.
Use names that survive leaving their immediate surroundings. Programme copy.md is adequate inside one production. If you regularly send it to someone handling several shows, The Tempest programme copy.md saves them a small piece of detective work.
A second copy creates a second question
Copying the lighting plan into both Technical and Opening night resolves the filing debate today. Tomorrow it raises a worse one: which copy contains the latest change?
Keep one working home where practical. If another document needs to direct you there, a link can do that without creating another editable plan. A deliberate snapshot is different: it might record what was sent to the venue on a particular day. Name its purpose so nobody mistakes it for the working file.
In Clarity, a project is a Finder folder shown as a group. The project and file guide explains the difference between removing a group from the sidebar and deleting its folder. That distinction matters when tidying: a quieter sidebar and less material on disk are separate decisions.
Try the structure with the next three files you actually need. If you can put each away and predict where to find it tomorrow, leave the hierarchy alone for a while. You have rehearsals to get on with.
Find app controls and examples in the Clarity documentation
A little more room to think.
A free, local Markdown hub for Mac.
Mac app details