A memory that outlives the chat
The set of plain files that give a project a memory outside the chat, so an agent starts every session already knowing what was decided. This is context-system, a skill I built: a foundation that wins, a build graph, a progress log, and the one file I add only when security is the point.
Part of my methodology series. If you have not read the overview, start there. This piece goes deep on one part of it: the memory.
The overview explains why a project needs a memory that lives outside the chat. This piece is that memory, in detail.
What the context system is
The center of my method is a set of plain markdown files that live in the repo, in a context/ folder. They are the project’s memory. Before any code gets written, the agent reads them, so it starts every session already knowing the decisions, the stack, the rules, and what has been built. I turned building them into a repeatable skill, context-system, so I can stand a good one up fast instead of rebuilding it by hand on every project. The files it produces, roughly:
foundation.mdthe locked decisions and the reasoning behind them. The top authority.architecture.mdthe stack, the shape, what lives where.code-standards.mdhow code is written here, so every session writes it the same way.build-graph.mdwhat depends on what, so you can always answer “what is safe to build next.”progress-log.mdwhat has actually been built, newest first.
A good context system is the difference between a codebase that stays coherent for months and one that rots. A bad one is worse than none, because it lies to the agent with confidence. So the files earn their keep or they get cut.
I did not invent the idea whole. I first saw a version of it from a teaching channel I learned a lot of my programming from, back in 2020 and 2021, and I have reshaped it across many projects since into something that fits how I actually work. It is mine now, built as a skill, not a fork of anyone’s code.
The foundation wins
One file sits above the rest. foundation.md holds the load bearing decisions, the stack, the data model, the shape of the thing, each written down with why it was chosen. The rule that makes it work is a single line: when the code and the foundation disagree, the foundation wins. No agent gets to quietly re-decide a settled call three sessions later. It cites the foundation instead of re-litigating it.
That one rule kills most of the drift. A model left alone will pick a different library than the one you already use, or reinvent an approach you settled last week, because last week is gone. A foundation that wins gives it a place to look first, and a reason not to argue with itself.
Build graph, not a to-do list
Once the context exists, most people reach for a checklist: a list of tasks in order, ticked off top to bottom. I stopped doing that on purpose.
A checklist pretends the work is a straight line. Real software is a web. Task C does not need to wait for task B; it needs the two specific things it actually depends on, and it does not care about the rest. So instead of a list I keep a dependency map: what requires what. Not a timeline, not an order, just the edges.
The map answers a better question than a list does. A list answers “what is next,” which is often wrong. The map answers “what is unblocked right now,” which is always useful. It matches how software is really built, in slices that fan out from a keystone, and it means I can pick the highest leverage thing that is genuinely ready instead of marching through an order that stopped being true two decisions ago.
Progress log, not a project checklist
For tracking what is done, I keep a running log, not a ticked checklist.
The difference sounds small and is not. A checklist records state (“this box is checked”). A log records momentum (“on this date, this was built, here is what to watch for”). When the person reading the project next is a fresh agent with no memory, momentum is worth far more than state. The log tells it not just that the thing exists, but why it was done that way and what nearly went wrong, which is exactly the context a checkbox throws away.
It matters even more on a team. Two people building in parallel can each append to a log without stepping on each other, and each reads the other’s entries to catch up in a minute. A shared checklist just becomes an argument about who ticked what.
So the rule I hold, and the one my context system enforces, is simple: after any real work, before you stop, write one entry. What, where, why, and the gotcha. It is as mandatory as reading the context first, because the next session depends on it.
When a security.md earns its place
One file I do not always write is a dedicated security.md. Most projects do not need a separate one. The security rules belong inside the files that already exist, the invariants in architecture.md, the handling rules in code-standards.md, so they are read in the flow of building instead of in a document nobody opens.
A separate security.md earns its place only when the security surface is the point of the project, when the rules are numerous and specific enough that folding them into the general files would bury them. That is a judgment call, and getting it right is the subject of the security case study, where I take this exact method into a project whose whole job is security, and the separate file finally becomes the spine rather than clutter.
The one thing that carries over
Everything here is one idea wearing different clothes: give the project a memory that lives outside the chat, put the decisions in it, and make every session read it first. The models will keep getting better at writing code. They will not, on their own, remember what your project already decided. That part is on you, and it is the part that decides whether what you build holds together. If you want to see how the whole loop runs on top of this memory, the overview has the map.