Picture this: you open a fresh session, ask your coding agent to run the tests, and it immediately does the one thing you told yesterday’s session never to do. You’re not mad at the agent. You’re mad because you know you typed that exact warning less than 24 hours ago, and now you have to type it again, in slightly different words, hoping this time it sticks.
That’s the moment a Reddit user in r/PromptEngineering got tired of. Their setup was a system prompt full of conventions plus a doc they pasted in whenever they remembered. Everything else lived in their head, and they paid for that twice every session: once in tokens spent re-explaining, and once in the stretch where the agent confidently broke a rule from three sessions ago. It got worse once they started switching machines. Work laptop, personal laptop, a borrowed one here and there. None of the agents knew what the others knew, so the re-explaining scaled with the number of places they worked. By the time they posted about it, they were basically running a one-person onboarding program for a new hire who showed up every single morning with total amnesia.
Why It Matters 🤯
Every new agent session starts from zero. It doesn’t matter how good the model is if the context that matters lives only in your memory. You end up doing the same job over and over: reminding it which folder is auto-generated, which command has to run before tests, which shortcut bit you during the last refactor. That’s not intelligence work, that’s data entry, and it’s exactly the kind of thing a plain text file can carry for you.
Think about how much of that re-explaining is genuinely repeatable. “Don’t touch the migrations folder directly, always go through the CLI” isn’t a one-off comment, it’s a standing rule that should survive every session forever. Same with “the staging API key lives in the vault, never in .env,” or “this repo uses tabs, not spaces, because of a legacy linter config nobody wants to touch.” Once you notice how many of your corrections are actually permanent rules in disguise, the fix stops looking optional. You’re not asking the agent to be smarter. You’re asking it to stop forgetting things a junior teammate would only need to hear once.
How-To Steps 🛠️
- Make one plain .md file per project. Not a wiki, not a folder tree, just one file. If you’re tempted to split it into categories right away, resist. A single flat file is easier to paste into a prompt and easier to keep honest.
- Write one fact per line, phrased as an instruction, with a date and where it came from. Something like: “2026-07-14 | run docker compose up before the integration tests | found the hard way during the auth refactor.” The date matters more than it looks. Six months from now you’ll want to know if a rule is still fresh or quietly stale.
- At the end of a session, don’t ask for a summary, ask for the diff: “What did you learn about this project today that isn’t already in the file? Give me lines, not prose.” Summaries drift over time. Short instruction lines don’t. A summary tries to be complete and ends up vague. A diff only adds what’s new, which is exactly what you want to review before it goes in the file.
- Paste in only the lines relevant to the current task, not the whole file. Keep the context window lean. If your file grows past a couple hundred lines, grep it for the task at hand instead of dumping the entire thing at the top of every prompt.
- Delete lines without sentiment when they stop being true. A stale rule is worse than no rule at all, because the agent will follow it with total confidence. Set yourself a reminder to skim the whole file once a month and prune anything that no longer matches how the project actually works.
Tips & Tricks 💡
The part worth stealing even if you never automate any of this: run it by hand first. Update the file yourself for a week before you build anything on top of it. You’ll find out fast which facts actually earn a permanent line and which ones were a one-time fluke.
A couple of small habits make this stick. Keep the instruction lines short enough to scan in a few seconds each, one clause is usually enough. If a rule needs three sentences to explain, it’s probably two rules, or it belongs in real documentation instead of a memory file. And resist the urge to write vague, feel-good entries like “be careful with the database.” Specificity is what makes a line worth keeping: “never run migrations against prod without a manual snapshot first” tells the agent exactly what to do. “Be careful” tells it nothing.
One open question from the original poster is worth flagging too. Some facts are only true on one machine, like “the dataset lives on the external drive.” Written into a shared project file, that line becomes wrong the second you switch computers. Tag machine-specific facts separately, or keep a tiny second file for local-only truths, so your project notes stay portable and your machine notes stay honest.
Call to Action 🚀
You don’t need new software to try this today. Open a blank .md file, write down the three rules you’ve re-explained most this month, and hand it to your next session instead of your memory. Small habit, fewer repeated arguments with your own agent.
Captain YAR out.
i kept re-explaining the same project rules to every new agent, so now i keep one plain .md file with one fact per line
by u/Danare_113 in PromptEngineering