Part 6 — What's Missing
The first five parts built the workspace. Part 6 audits it — because day-one decisions hide gaps that only surface once real work has run through them.
You only learn certain things by running real work through. Where the procedures shrugged at an input they should have caught. Where the rules were written for a situation that does not actually happen. Where you keep restating something on every turn because the workspace forgot to write it down. Where the Instructions have grown long enough that you cannot skim them anymore.
None of those gaps are visible on day one. They show up the third time you wish the workspace had handled something differently. Part 6 is the part you run when you have noticed enough of those moments to know the workspace needs a pass.
When you finish, the workspace you have been using has new files in it that close gaps you only noticed once it was in active use. The Instructions file has new ALWAYS read lines pointing at those files. If you wanted, the older lines have been grouped so the file reads at a glance again.
You name everything, same as before. Every change in this part comes out of one open question the prompt asks you up front.
What this part is actually for
The earlier parts asked forward-looking questions. Part 1 asked what this workspace is for. Part 2 asked what should always be true on every turn. Part 3 asked what kinds of repeatable work it does. Part 4 asked what needs focused attention. Part 5 asked what runs end-to-end. Part 6 asks the only question you couldn't answer until now: what's drifted.
The kinds of drift that show up are predictable in shape, even when the specifics differ wildly across workspaces.
There's a procedure that handles 80% of cases and quietly fumbles the other 20%. You've been catching it by hand and it never made it back into the file. A rule that almost never fires sits next to a missing rule the workspace keeps wishing existed. A helper asks too many clarifying questions; another asks none when it should. The Instructions has accumulated a few new pointers and the trunk no longer reads at a glance.
None of these are bugs in what you built. They are evidence that you used it. This part is the place where that evidence lands as actual edits to actual files.
How to run it
Open the prompts panel and paste the in-use audit prompt. The model reads what you already built, asks you in one sentence what's not working or what's missing now that the workspace has been in active use, and walks you through the rest. You name everything. The model proposes shapes; you decide what each new piece is called and where it fits in the layout you already named.
There is no requirement that earlier parts be in any particular state of completeness. If you stopped after the rules and have been using a slim workspace ever since, this part still works — it audits whatever is there. The walkthrough adapts to whatever it finds at the root.
What happens when you paste the prompt
Same shape as the earlier walkthroughs, applied to drift instead of greenfield work.
The prompt opens by re-reading your Instructions file and quoting it back to you, so you can see at a glance whether the trunk still reads cleanly or has grown crowded.
If they have, an opt-in regrouping step runs first. Same rule as everywhere else in the series: the model proposes a grouping conceptually, you name every group. Skip the regrouping if the trunk still reads fine.
Then the open question, one sentence: what's not working, or what's missing, or what keeps coming up that the workspace does not yet handle. Plain answers work. If the sentence is thin, the prompt offers a few short multiple-choice follow-ups to thicken it. Where in your work the thin spot showed up. What kind of fix you have in mind. Whether the gap is in something existing or something brand new.
From your answer, the prompt proposes a list of gaps in plain language — some new files, some edits to files you already have. Each item is a sentence about what it does or fixes, no filenames. You walk the list: drop one, rename one, add what's missing, or say it looks right. The list does not move forward until you say it does.
Then placement, item by item. For new files, the prompt asks where each one fits. One of the slots you already have, or a new one you choose to add. For edits to existing files, the prompt shows you the file, proposes the change, and waits. You read, accept, edit, or ask for a different angle. Nothing lands on disk without your explicit go.
When all the changes are written, the prompt shows you the new lines it wants to append to the Instructions for the new files, plus any lines that moved as part of the regrouping. You approve. The Instructions land in the shape you signed off on, and the underlying files are updated where you said.
When you're done
You have the new files sitting wherever you put them and the Instructions file extended (or regrouped) at the root. Open the Instructions in a text editor and you can read the whole thing in under a minute again. Open any of the files it points at and you can see exactly what changed and why.
Part 6 is not a one-and-done part. It is the part of the series you come back to whenever the workspace stops feeling like it fits. Run it again in three months, after another run of real work has surfaced the next set of thin spots. The shape of the prompt is the same. The answers will be different. The workspace stays alive by being audited, not by being finished.
You can hand off the execution. The accountability stays at your desk.