88. Why a Working Directory?

The lesson

Every long project — an application, a hardware build, a documentation set, a research effort — generates files. Source files, notes, plans, logs, downloads, drafts, backups. If you start working before deciding where all of that lives, the files scatter: some land in Downloads, some on the Desktop, some in whatever folder happened to be open at the time. Two weeks later you cannot say with confidence which copy of a file is the real one. A working directory is the cure, and it costs you about thirty seconds to create.

A working directory is simply one dedicated folder that the project owns completely. Everything the project produces goes inside it, and nothing unrelated is ever written there. The name should be descriptive and stable — for example `Jacques_Working_Directory` or a project-specific folder such as `TPEE_Dev_1` — because you, your tools, and your LLM sessions will all refer back to this exact path many times over the life of the project.

The most important benefit is context for the LLM. When you open a session and tell the model "the project lives at this path", the assistant can read the previous files, follow the naming patterns, respect the existing structure, and continue the work instead of starting from a blank slate each time. Without a fixed directory, every session begins with archaeology: hunting for the last version, re-explaining the layout, and hoping nothing important was saved somewhere else.

A dedicated directory also makes the project portable and safe to back up. One folder means one thing to copy, one thing to zip, one thing to point a backup tool or a git repository at. Contrast that with a project spread across five locations: backup becomes guesswork, and moving to a new machine becomes a small disaster. The Toptronic^® conventions even formalise this with a `WORKING_DIRECTORY_AND_PATH` entry, so every convention file and handover refers to the same anchor.

Structure inside the directory is the second half of the win. Once everything is in one place, you can impose an obvious layout — sources, docs, data, logs, and a history area — and that layout becomes a map that both humans and LLMs can navigate. Tools behave better too: linters, builds, and search run cleanly because they operate on a well-defined root instead of accidentally sweeping up unrelated files from a shared folder.

There is a safety dimension as well. If the LLM is ever instructed to modify, delete, or reorganise files, you want the blast radius contained. Work confined to a dedicated directory cannot touch your personal documents, your other projects, or system folders. That containment only works if the directory exists and is named in advance — which is exactly why you create it before the first prompt, not after the first accident.

A working directory also improves the quality of the project history. The Toptronic^® LLM Rules assume that history files, inventories, and handovers are written inside the working directory. When those records accumulate in one place, the directory itself becomes the project's memory: you can read the folder listing and reconstruct what happened, in what order, without opening a single file.

Finally, the discipline is cheap and the regret is expensive. Making the folder costs nothing; retrofitting one after files have spread everywhere costs a careful migration, a re-check of every reference, and usually one lost file. Professionals do this instinctively for the same reason they label their components drawers before starting a build: the sorting is trivial at the start and painful in the middle.

The habit to adopt is simple. Before you write the first prompt of any long project: create the working directory, give it a clear name, decide its internal structure, and state its path in your very first message to the LLM. Everything else in the following lessons — bounded work, memory systems, and handovers — assumes this folder exists.

Check yourself