One Set of Rules
Oct 2026
As you may have already gathered, Flexibility has been an important theme that runs throughout the choices I make. Equally critical is that project decisions are grounded in a robust plan, informed by an Architecture that can survive evolving needs.
As I moved between Cursor, VS Code, Copilot and other tools, I wanted to retain the freedom to choose what suited the task, without the burden of porting a different set of rules into each one.
Over time, I had saved such rules in several places. That made sense as each tool entered my workflow, but it left me with some troubling questions: Was a specific rule global or repo-specific? How would I remember which instances of a rule to edit, if I wanted to make a change? What would happen if I wanted to move out of a particular tool altogether?
I wanted my architectural decisions to belong to the project, not to the particular tool I happened to be using that day.
The right approach was to migrate all the rules to a centralised AGENTS.md file, located at the root of each repository. Cursor, VS Code, Copilot, and the other tools I use already follow this shared system, so every tool could read the same set of guidelines for the project.
Global principles, Local needs
I took the decision to structure the file in two parts:
"Part A - Global" holds the principles I want to carry from one project to another.
"Part B - Repo-specific" captures what matters in that particular project including how it is organized, what its work involves, and which conventions to follow.
Keeping both in one file achieves a useful balance. The shared principles remain consistent, but each project also gets the guidance that fits its unique needs.
Finally, I assigned a canonical home for the 'Global' rules, carrying it across my repositories on any change, by using a small script to update the rest. That way, everything stays in sync!
Making a clean move
In my case, I had several months of rules that had evolved across repos, so the change itself was more involved than moving a few paragraphs. I had to sort out which instructions were shared, and which belonged to a particular project. Some old references still pointed to the previous files, and the surrounding documentation needed to explain the new arrangement. I also had to distinguish rules from things that still served another purpose.
For example, a Copilot prompt I kept was still useful as a shortcut for a documentation task. It did not need to disappear just because some of its repeated guidance had a better home. Getting that distinction right, updating the references, and making sure the project notes told the same story took careful cleanup.
Flexibility + Consistency
Now that it's all done, it may not be the most visible part of any project, but it is what makes the setup feel complete. And, the effort seems worth it.
I now have one source of truth for the guiding principles that matter across tools. With this setup, I can choose the AI agent or tool that fits the work, without wondering whether it has a different version of the project's expectations.
So, while the tools keep changing, and my preferences may also evolve over time, I don't need to start over or rebuild the same instructions. My ongoing projects can now retain their useful memory via consistent rules that guide all the tools I work with.
This project captures ideas, decisions, and lessons I’ve learned while building with AI. It aims to help non-technical users understand and use these tools effectively. I also use AI at times to improve or refine the content.
Readers should use the commands and instructions here with care. The creator accepts no responsibility for system damage, data loss or other consequences resulting from their use.