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