This will just kill your context window.
After you finished a feature, refactor it. Ideally, itâs just 1 folder.
I have this in my AGENTS.md (cursor auto-reads this), parts are Flutter specific:
REFACTOR TRIGGER: ârefactorâ
When you see this phrase, automatically apply comprehensive simplification:
1. **Clutter Cleanup**: Remove dead code, consolidate duplicate logic
2. **State Management**:
- Count providers in the target directory (>3 is usually overengineered)
- Identify family providers with session keys/IDs (red flag)
- Look for global state being used for local UI interactions
- Convert to simple StatefulWidget when appropriate
- Create single Helper class for truly global operations only
- Pass state as props instead of provider dependencies
- Remove session management and use widget instance isolation
- Follow âuse as few providers as possibleâ guideline
3. **Code Simplification**: Make UI readable, donât overengineer, apply DRY but avoid over-abstraction
4. **Constants & Theme**: Move magic values to `lib/const.dart`, extract styles to Theme (ask if uncertain)
5. **Verification**: Ensure no functionality broken
Whenever I type something like âRefactor @directorydirectory/â, it applies those rules.
1 Like
I usually have 12-14 rules attached, each relatively large. This is one of the largest, most are probably half this size. My context window usage ranges from 30-50% most of the time.
Remember, this stuff becomes an embedding, so its vectorized. The embedding form is usually not as large as the raw text.
In any case, Iâve never killed my context. Not all rules apply to everything. I attach these intelligently in many cases, or just strait up manually for others, so they generally attach only when needed. When I get to a step that involves unit or integration testing, Iâll include those, and drop others.
I thought I would add something else here. Yes, I suspect my context usage is higher with more stringent rules than without. HOWEVERâŚdoes it cost more?
How often does the average Cursor user have to spend more and more tokens fixing issues created by the agent and llm? How much does that cost? How much does it add up over time?
With good rules, the agent and llm are able to do better, the first time around. Maybe they can give you a one-shot result that is acceptable. Maybe it takes a few small prompts to optimize things. Does that cost more, or less? Remember, context is cached, so after its been sent to the llm once, cache reads usually cost a tenth as much as normal tokens (or less).
So which is actually cheaper? Get good work faster in fewer prompts but with more tokens up front? Or use less context in each prompt but maybe have to spend a lot more time and make a lot more requests to resolve poor quality code issues, or worse?
I have no concrete data. However, I also have far fewer issues using the agent and getting good results with one or a small few prompts, than I did before I had these bigger rules (where I might have to spend some hours fixing big issues the agents createdâŚhas happened more than once.)
2 Likes
From my side I use Cursor without auto-mode locally for sensitive parts and for unrestricted coding within a VM (either on my machine as a passthrough VM of same OS, or as Background Agent.
In both VM scenarios I give Agent full access to a local database where it can do what it needs without breaking my dev or live production environment. That way I can restore a snapshot and checkout branch fresh.
It depends a lot on the programming language but even more on the framework as todays best frameworks have an AI assistance built-in. That can range from providing directly latest docs in context saving amount, language & framework related best practices / rules that prevent AI from doing things the logical but wrong way, application and environment integration, testing helpers etc⌠This small addition can make or break the implementation with AI over long term.
The âremove dead codeâ definitely going to my rules too, thanks!
1 Like