Last week, a guy posted a tidy little rules file trick on Reddit. This week he came back and admitted the comments were better than his post. That almost never happens on the internet, so I paid attention.
Here’s the setup. You keep a plain text file of instructions that you paste into any AI chat. It’s your standing orders for the model. The first version worked. The second version, built from the community feedback, works a lot better. This guide walks you through it.
Intro: The File That Ate Your Afternoon
If you’ve ever kept a rules file, you know how it goes. You start with four neat lines. A month later it’s fifteen lines, three of them contradict each other, and one says something about a project you finished in spring. The model reads all of it and follows about half.
The fix isn’t a smarter file. It’s a smaller one with a better system around it. Think of it like a junk drawer: the problem isn’t the drawer, it’s that nobody ever decided what belongs in it.
Why It Matters 🧭
Some people ask how this differs from ChatGPT memory or Gems. The simplest answer: memory decides what to keep on its own. A file is something you write, trim, and carry with you.
That last part is the big one. Switch from one chatbot to another and the file comes along. Nobody can quietly rewrite it overnight. Same idea as memory, except you’re the one holding the pen.
There’s also a quieter benefit. When the file is short, you actually know what’s in it. So when the model does something odd, you can check your rules in ten seconds instead of wondering which of your forty forgotten lines caused it. A lean file is easier to debug, and debugging is where most of the frustration lives.
How-To Steps 🛠️
- Split it in two. Make a short base file that barely changes. Then add a few project lines on top for whatever you’re working on right now. Base file stays stable. Project lines come and go. A good base is five to eight lines: how you like answers formatted, how blunt you want the model to be, and the habits you want everywhere.
- Watch for creep. Project lines multiply fast. Four becomes fifteen before you notice. When that happens, ask one question about each line: “Would I want this on every project?” If the answer is no, cut it or leave it in that project only.
- Make lines earn their promotion. Don’t move a line into the base file the first time it helps. Wait until it shows up in a second project. Before that, it’s usually a one-off wearing a costume. If you want to track this, put a tiny tally mark next to a line each time it proves useful somewhere new. Two marks, and it gets promoted.
- Add the two lines that earned a permanent spot. The original poster found these two survived everything:
- “If it’s unclear, list your assumptions before answering.”
- “If you’re not sure, ask before you build.”
Both stop the model from confidently sprinting in the wrong direction. The assumptions line is especially handy because you can spot a wrong guess in two seconds, before it turns into a page of wrong output.
- Ask one question at a time. If your rules tell the model to ask clarifying questions, tell it to ask one per turn. Five questions at once get you five half answers. One question gets you one real answer, and you’ll probably actually read it.
Tips & Tricks ✂️
- Try a quick example for an email project. Base: “Ask before you build.” Project lines on top: “When editing my writing, keep the facts and commitments. Don’t invent dates or promises.” Paste both above a draft and see what changes.
- Prune on a schedule. Once a month, read the file top to bottom. Anything you don’t remember adding is a candidate for deletion. Put a recurring reminder on your calendar, because “I’ll do it later” is how the file got fat in the first place.
- Keep a graveyard. Put cut lines in a separate scratch file instead of deleting them. Cutting feels easier when it isn’t permanent.
- Short beats clever. A plain sentence the model can’t misread beats a fancy instruction it half follows. “Keep answers under 150 words” works better than “be maximally concise yet comprehensive.”
- Test by removing. If you delete a line and nothing gets worse, it was never doing anything. Run a few of your usual prompts without it and compare the answers side by side.
Call to Action 🚀
Open your current rules file right now and run the “every project” test on each line. You’ll probably cut a third of it before your coffee gets cold.
Then tell me: what’s the one line in your file you would never delete? Drop it in the comments. I’m collecting the survivors!
Frequently Asked Questions
Q: What does a finished rules file look like in practice?
Start with a base rule that holds for all your writing, like ‘When editing my writing, preserve facts and commitments. Don’t invent dates, promises or reasons.’ Then add a project rule for the job in front of you, such as a late-delivery reply that explains the delay using only the facts you paste and leaves [CONFIRM DATE] wherever the date is still unknown. The base rule travels to your next task, and the project rule stays with this one.
Q: How do you decide whether a line is worth keeping?
Try the ten-second test: if you can’t say why a line is there in under ten seconds, cut it. One commenter calls it the junk drawer rule, and it stops the bloat that builds up when you keep adding lines just in case. Run it whenever the file starts feeling long, and you’ll usually find a few lines that only mattered once.
Q: Should you point the model to files by name or by hash?
One commenter suggests referencing content by hash instead of file name, so the model pulls the exact version it needs. Names can be vague or change over time, while a hash points to one specific piece of content. It takes a bit more setup, so it pays off most once you have a lot of files rather than a handful.
Update on the rules file trick: the comments made it way better
by u/AgentPouchHQ in PromptEngineering