I have had a tough time with Cursor rules lately. Particularly with GPT-5, which seems to have a more cavalier “attitude” about them. Sonnet is pretty good, but it is also not quite perfect. So I’ve developed a process of improving my rules, so that they apply more consistently.
When you identify a failure in the application of a rule, first inquire about why. And really inquire, don’t let the model try to fix the issue that resulted from ignoring the rule yet. Tell the agent to identify the reason why the rule was not applied, but not to change any code. The model should analyze the issue, and provide you with a decent (quite good to excellent in the case of Sonnet) explanation of why.
Once you are sure that the explanation makes sense, is logical, and that resolving that issue would fix the problem, instruct the agent to fix the rule that did not get applied, according to the prior analysis. Often, this will work, and the rule will get applied more regularly. A lot of the time, it boils down to application mode. Often, rules get stuck in “Apply Manually” which means you have to explicitly reference them as context for your prompt. However, for “Apply Intelligently” or applying according to globs, will still often not apply, and some models are more cavalier about applying them than others.
If the rule still will not apply consistently, push the agent/model to analyze the issue more deeply. Read and analyze its own analysis yourself, and see if it really does make sense. This is where you may discover the real issue, OR, if you probe and query the agent more, the agent itself, will often discover that it had incorrect assumptions of its own, that lead it to thinking certain changes to the rule would improve application. Once the agent notices other reasons why it may not have applied, it will often recommend additional improvements, which you can have the agent itself apply to the rule.
Occasionally, and I don’t know how this happens, the agent will state that its actually crating a MEMORY. Memories are a Cursor feature. I did not think that they could be created by the agent previously, however, the last couple actually did seem to get created. I have noticed that once a memory is crated, which will often pertain to that key realization the model had, that will often have a profound effect on the application of the actual cursor rules. (So, basically, try and guide the agent to the point where such a realization occurs and it decides to create a memory…)
Rule refinement and optimization is an important process to help keep the agent operating more consistently, and performing more complex tasks correctly. Committing, for example, is the key example that inspired me to write this. We have a series of lefthook pre-commit checks in our repos. These perform db migration script evaluations, formatting, linting, compiling, security checks and a few other things. So, there are a number of reasons why the actual git commit command will fail with validation errors. The agent+sonnet in my case, kept making the assumption that it was prettier formatting causing the problem.
I then realized that prettier was actually probably the ONLY pre-commit check that would re-stage any formatted files on its own. It was when I mentioned that, that the agent, well model actually, as it was after a short thinking stint by claude-4-sonnet 
that it suddenly realized it had made a mistake thinking the issues were formatting (and, thus, not really major issues)…and then it delved in and explored all the lefthook config, and made a bunch of realizations about how it was operating, updated my rules, then created a memory.
Ever since, the commit process is humming along smoothly, with no more lagging files after fixing pre-commit validation issues. So, refine your rules! Have the agent refine them, and push for the agent to reach those “epiphany” moments, and get those memories created. It will help the agent perform more consistently, reliably, and overall faster (fewer resolution/correction cycles.)