Cursor rule

1---
2description: 
3globs: 
4alwaysApply: true
5---
6<keyPrinciples>
71. When task is not >95% clear, start with a question (both in plan and act modes): "The task is not fully clear. Please clarify following points:" [list of crucial points for understanding the task]. After the user replies, implement the solution. 
8</keyPrinciples>
9<implementationOrActMode>
10    <programmingPrinciples>
11      - algorithm_efficiency: use the most efficient algorithms and data structures
12      - modularity: write modular code, break complex logic into smaller atomic parts. Whenever possible break into classes, files, directories, modules, functions, etc.
13      - file_management: break long files into smaller, more manageable files with smaller functions.
14      - import_statements: prefer importing functions from other files instead of modifying those files directly.
15      - file_organization: organize files into directories and folders.
16      - reuse: prefer to reuse existing code instead of writing it from scratch. 
17      - code_preservation: Preserve What Works. Don't modify working components without necessity.
18      - systematic_sequence: Complete one step completely before starting another. Keep systematic sequence of functionalities.
19      - design_patterns: apply appropriate design patterns for maintainability. Plan for future changes, extendable flexible, scalable, and maintainable code.
20    </programmingPrinciples>
21    <systematicCodeProtocol>
22      <step1>
23        <analyzeCode>
24          <dependencyAnalysis>
25            - Which components will be affected?
26            - What dependencies exist?
27            - Is this local or does it affect core logic?
28            - Which functionalities will be affected and how?
29            - What cascading effects will this change have?
30          </dependencyAnalysis>
31          <flowAnalysis>
32            - Before proposing any changes, conduct a complete end-to-end flow analysis of the relevant use case from the entry point (e.g., function call, variable initialization) to the execution of all affected code. 
33            - Track the flow of data and logic throughout all components involved to understand its full scope.
34          </flowAnalysis>
35        </analyzeCode>
36      </step1>
37      <step2>
38        <planCode>
39          - If needed initiate &lt;clarification&gt; process.
40          - Use &lt;stepByStepReasoning&gt; to outline a detailed plan including component dependencies, architectural considerations before coding.
41          - Use &lt;reasoningPresentation&gt; to explain all code changes, what each part does, and how it affects other areas.
42          <structuredProposals>
43            - Provide a proposal that specifies: 
44              1. what files, functions, or lines of code are being changed;
45              2. why the change is necessary (i.e. bug fix, improvement or new feature);
46              3. all of the directly impacted modules or files;
47              4. potential side effects;
48              5. a detailed explanation of any tradeoffs.
49          </structuredProposals>
50        </planCode>
51      </step2>
52      <step3>
53        <makeChanges>
54          <incrementalRollouts>
55            - One logical feature at a time
56            - But fully resolve this one change by accommodating appropriate changes in other parts of the code.
57            - Adjust all existing dependencies and issues created by this change.
58            - architecture_preservation: Ensure that all new code integrates seamlessly with existing project structure and architecture before committing changes. Do not make changes that disrupt existing code organization or files.
59          </incrementalRollouts>
60          <simulationTesting>
61            <simulationAnalysis>
62              - Simulate user interactions and behaviors by performing dry runs, trace calls, or other appropriate methods to rigorously analyze the impact of proposed changes on both expected and edge-case scenarios. 
63              - Generate feedback on all potential side effects.
64            </simulationAnalysis>
65            <simulationValidation>
66              - Do not propose a change unless the simulation passes and verifies that all existing functionality is preserved, and if a simulation breaks, provide fixes immediately before proceeding.
67              - If Simulation Testing Passes, do the actual implementation.
68            </simulationValidation>
69          </simulationTesting>
70        </makeChanges>
71      </step3>
72      <step4>
73        - Loop step1 to step3 and implement all changes
74        - Incorporate all the changes systematically, one by one.
75        - Verify the changes and test them one by one.
76      </step4>
77      <step5>
78        - Optimize the implemented code, after all changes are tested and verified.
79      </step5>
80    </systematicCodeProtocol>
81  </implementationOrActMode>
82