If you've used Claude, Cursor, or any AI coding assistant on a real project for more than a few days, you've probably hit this wall: every new chat starts from zero. It doesn't remember what you decided last week, doesn't know which files are off-limits, doesn't know you already tried an approach and rejected it for a good reason. You end up repeating yourself constantly, and every so often the assistant "helpfully" undoes a decision you made three sessions ago because it simply never knew about it.
I ran into this enough times that I stopped treating it as an annoyance and started treating it as a missing piece of process. The fix I landed on is a two-prompt system built around a small folder of memory files that live inside the project itself.
The two-prompt idea, in plain terms
Prompt one runs once, right when a new project folder is created. Its only job is to get the AI to set up a .ai-memory/ folder with a handful of starter files — a README explaining the memory system itself, a PROJECT.md for what the project is, a CURRENT-STATE.md for what's actually built so far, a RESTRICTIONS.md for anything that must never be touched, and a few others for tasks, changelog, and architecture. Think of it as the assistant writing its own onboarding notes before any real work begins.
Prompt two is the one you use for everything after that — every single time you ask for a new feature, a bug fix, a change, anything. Its job is different: before touching any code, it has to actually read the memory files, compare your new request against what's already there, and only then decide what to do. And critically, once the work is done, it has to update those same memory files so the next session — even a completely fresh one, maybe on a different day, maybe even a different AI tool — picks up exactly where this one left off.
That second prompt is the one doing the real work, so that's the one worth breaking down properly.
Why "don't start coding immediately" is the most important line in it
The instinctive behavior of most AI coding assistants is: you describe a requirement, they start writing code. That's usually fine for a five-minute script. It's a genuinely bad habit on a project that already has history, existing architecture, and rules about what can't be changed.
So the prompt deliberately forces a pause before any code gets written, and asks the assistant to work through five questions in order:
- What am I actually being asked for?
- What already exists that's related to this?
- Which specific files does this touch?
- What actually needs to change?
- Does this conflict with anything already decided or restricted?
That fifth question is the one doing the most protective work. Without it, an assistant will happily implement a request that quietly contradicts an architectural decision made two weeks ago, simply because nobody told it about that decision in this conversation. With a RESTRICTIONS.md file to check against, it has a chance to catch that before writing a single line.
Guardrails that matter once it does start coding
Two instructions in the prompt exist specifically to stop scope creep and collateral damage:
- Preserve everything unrelated to the requirement. An AI assistant, left unchecked, will often "improve" things nobody asked it to touch while it's in the neighborhood. This line exists to keep the blast radius of a change limited to exactly what was requested.
- Never modify protected or restricted files. This is what makes RESTRICTIONS.md worth maintaining in the first place — it's not useful as documentation if the assistant isn't explicitly told to check it and respect it before every change.
The part everyone skips: updating the memory afterward
This is the piece that makes the whole system self-sustaining instead of a one-time setup you forget about. After implementation, the prompt requires:
- Testing or validating whatever was built
- Updating CURRENT-STATE.md to reflect what's actually true now, not what was planned
- Updating TASKS.md and CHANGELOG.md
- Touching ARCHITECTURE.md or DECISIONS.md — but only if something actually changed at that level, not as a routine habit
- Writing a HANDOFF.md note if the work is left unfinished, so whichever AI session picks it up next knows exactly where things stand
Without this step, the memory folder rots. It becomes accurate for the first few days and then quietly drifts out of sync with the real codebase, and at that point it's actively misleading — worse than having no memory at all, because now the assistant is confidently wrong instead of honestly uncertain.
One line I'd underline twice
"Do not invent information or claim that something was tested if it was not tested."
This is the guardrail against the most common failure mode of all: an assistant writing "tested and working" in a changelog because that's the expected shape of the sentence, not because anything was actually run. Once a false "tested" entry gets into your memory files, every future session trusts it, and you've built a system that lies to itself. This single instruction is what keeps the memory trustworthy enough to actually rely on.
The prompt itself
This is the one I actually use, requirement pasted in at the bottom each time:
Read the project memory first, especially:
.ai-memory/README.md
.ai-memory/PROJECT.md
.ai-memory/CURRENT-STATE.md
.ai-memory/RESTRICTIONS.md
Then analyze my requirement below against the existing project.
Do not start coding immediately.
First determine:
1. What I am asking for
2. What already exists
3. Which files are relevant
4. What needs to change
5. Whether the change conflicts with any existing restriction or architectural decision
If the requirement is clear and safe, implement it.
Preserve all existing functionality that is unrelated to my requirement.
Do not modify protected/restricted files or functionality.
After implementation:
* test/validate the changes
* update the relevant .ai-memory files
* update CURRENT-STATE.md with the new actual state
* update TASKS.md
* update CHANGELOG.md
* update ARCHITECTURE.md or DECISIONS.md only if actually necessary
* update HANDOFF.md if the work is incomplete or another AI may need to continue it
Do not invent information or claim that something was tested if it was not tested.
My requirement:
[PASTE YOUR REQUIREMENT HERE]
Where this actually pays off
The value doesn't really show up on day one. It shows up three weeks in, when you open a brand-new chat window, paste this prompt with a new requirement, and the assistant already knows what was restricted, what was already tried, and what state the project is genuinely in — without you having to re-explain any of it. At that point the memory folder has effectively become the project's institutional knowledge, and the AI is just the current session reading from it, the same way a new developer would read a wiki before touching a codebase.
If you're running AI-assisted development on anything longer-lived than a weekend script, this pattern is worth setting up once. It's a small amount of structure for a large amount of consistency.
