devour

Every new session starts from zero. The agent can open fifty files and summarize each one, and still have no idea that changing a helper in one corner breaks a page in another. I kept typing the same word at the start of every session, so I turned it into a skill.

The brief I wrote for it was about a city. A local knows the streets, and also knows the rhythm: which roads jam at eight, which ones are empty at noon. Opening many files doesn't count. The agent has to be able to answer practical questions about a change, with evidence.

The most useful line in a map is a warning. Here is a small one for the site you are reading. Pick a file and see what it reaches. Every edge was checked against this repo's imports.

A list of folders tells you where code lives. A route tells you what happens. devour traces the important ones end to end, from what sets them off to what comes back. Here is the route an AI crawler takes when it asks this site who I am.

Architecture diagrams are frozen. Real systems have a clock: what runs before anything else, what is cached and for how long, what fires on a schedule. This layer is what turns knowing the layout into knowing how the system behaves.

One rule in the skill does a lot of work: a map that hides its blank regions is worse than no map. A stranger trusts a clean-looking map and walks straight into the part nobody checked. So the unknowns get their own section, each with the probe that would close it.

Before the agent can say it knows the codebase, it has to answer these eight with evidence. If it can't, it says the repo is partially devoured and lists what to probe next. That sentence is allowed. Rounding up is not.

The study ends in one file at the repo root, so the next session starts from a checkpoint. The rules keep it honest. It is one file, readable in one sitting. Every update is stamped with what was studied and against which revision. A later run reads it as claims to verify, and a refresh sorts every old claim into one of four buckets.

Two copies of the same model miss the same things. One Claude and one Codex miss different things. In collab mode each maps the code alone, then they trade written atlases through a conductor that never maps anything itself. They never chat live. A conversation would let them anchor on each other, and the whole point is that each builds a complete picture first.

MoroMail is my fork of the Mailspring desktop mail client. On 30 June I ran a collab devour on the whole repo, with Codex conducting. The two atlases disagreed in six places, and every disagreement was settled by going back to the code.

The conductor's summary was that Claude traced the application's nervous system better, and Codex caught more of the operational, security and rebrand landmines. One question stayed open: the native sync engine lives outside the checkout, so neither brain could see it. The map files that under Contested, where a person looks first.