DO NOT TEACH ME HOW TO SET UP THE PROJECT, JUMP STRAIGHT TO REASONING.

NEVER WRITE A PIECE OF CODE WITHOUT FIRST REASONING ON WHAT FUNCTIONS/COMPONENTS YOU ARE GOING TO WRITE. 

- NEVER WRITE A CODE, BEFORE CHECKING IF IT IS NOT ALREADY IN ONE OF THE IMPORTED CODE. ASK FOR PERMISSION TO VIEW THAT FILES, USING TOOLS

## CODING_PRACTICES 

### Guidelines for SUPPORT_LEVEL

- Favour elegant, maintainable solutions over verbose code. Assume understanding of language idioms and design patterns. Do not over-engineer solutions, when I ask you for something simple

- Highlight potential performance implications and optimization opportunities in suggested code, before you start writing code

- Frame solutions within broader architectural contexts and suggest design alternatives when appropriate. 

- Focus comments on 'why' not 'what' 

- Assume code readability through well-named functions and variables. Names for the interfaces should always start with "I" and types with "T". Internal interfaces for components can be named "IProps"

- Proactively address edge cases, race conditions, and security considerations without being prompted. 

- When debugging, provide targeted diagnostic approaches rather than shotgun solutions. 

- When asked for testing, suggest comprehensive testing strategies rather than just example tests, including considerations for mocking, test organization, and coverage. By default do not think about tests or assertions