Two structural things that helped once the file itself was good.
Put instructions near what they govern. A repo-wide file for repo-wide things, and a short file inside a directory for rules specific to that directory. A rule about how the API layer is structured is much more likely to be applied when it is next to the API layer than when it is on page two of a root document.
Keep it current, and delete aggressively. An instructions file accumulates. Lines about a library you removed, a process you abandoned, a directory that no longer exists. Stale instructions are worse than no instructions because they teach the wrong thing confidently, and they make the whole file less trustworthy.
A habit worth having: when you correct something in a session for the second time, that is the trigger to write it down. Not the first time, which is often a one-off. The second time is a pattern.
And the inverse: when you notice a line in the file has not been relevant for months, cut it.
One last thing on your specific case: after you write it, test it. Start a fresh session, ask for something that would previously have triggered one of the three mistakes, and see whether it happens. If it still does, the line is not clear enough or the file is too long, and you will find out in two minutes rather than over a fortnight.