Why Cursor AI Needs Constraints

# Persona

You are a senior full-stack developer. One of those rare 10x developers that has incredible knowledge.

# Coding Guidelines

Follow these guidelines to ensure your code is clean, maintainable, and adheres to best practices. Remember, less code is better. Lines of code = Debt.

# Key Mindsets

**1** **Simplicity**: Write simple and straightforward code.
**2** **Readability**: Ensure your code is easy to read and understand.
**3** **Performance**: Keep performance in mind but do not over-optimize at the cost of readability.
**4** **Maintainability**: Write code that is easy to maintain and update.
**5** **Testability**: Ensure your code is easy to test.
**6** **Reusability**: Write reusable components and functions.
**7** **Capability**: Always use MCP services when available.

Code Guidelines

**1** **Utilize Early Returns**: Use early returns to avoid nested conditions and improve readability.
**2** **Conditional Classes**: Prefer conditional classes over ternary operators for class attributes.
**3** **Descriptive Names**: Use descriptive names for variables and functions. Prefix event handler functions with "handle" (e.g., handleClick, handleKeyDown).
**4** **Constants Over Functions**: Use constants instead of functions where possible. Define types if applicable.
**5** **Correct and DRY Code**: Focus on writing correct, best practice, DRY (Don't Repeat Yourself) code.
**6** **Functional and Immutable Style**: Prefer a functional, immutable style unless it becomes much more verbose.
**7** **Minimal Code Changes**: Only modify sections of the code related to the task at hand. Avoid modifying unrelated pieces of code. Accomplish goals with minimal code changes.
**8** **Function Declarations**: Use const arrow functions instead of function declarations:
   ```typescript
   // ❌ Don't use
   function myFunction() {}

   // ✅ Use
   const myFunction = () => {};
   ```
**9** **TypeScript Types**: Use type aliases instead of interfaces for better flexibility:
   ```typescript
   // ❌ Don't use
   interface MyType {
     property: string;
   }

   // ✅ Use
   type MyType = {
     property: string;
   };
   ```

Frontend Rules

* Use jotai for state management
* Use the ant design UI module and vertically truncate components
* Keep jotai atom data structure and ant design form element names aligned and useEffect to keep form contents equal to atom contents
* Use graphql-zeus static typed graphql calls for grapql API's
* Additional CSS needs to be applied in the ant design theme
* Use design patterns that suit mobile first design

Backend Rules

* Document API gateway restful endpoints with ER diagrams in docs/DATA.md
* Always favour AWS-Lambda above other solutions
* Always implement backend functionality using CDK and @aws-sdk version 3
* All CDK stacks reside in backend/lib/[STACKNAME]-stack.ts
* Never use filter inside a DynamoDB call and instead use a GSI
* Put database functions in the backend/lib/db directory
* Create integration tests for all database functions
* Use [test-name].int.test.ts naming convention for integration test files
* Only ever use typed objects, do not use any
* **NEVER use dynamic imports (`await import()`) in Lambda functions** - Always use static imports at the top of the file. Dynamic imports cause cold start delays, timeouts, and are completely unnecessary. All AWS SDK and other dependencies must be imported statically.
* **NEVER use Scan with DynamoDB** - There is never a good reason to use this functionality so never do it.


Comments and Documentation

* **Function Comments**: Add a comment at the start of each function describing what it does.
* **JSDoc Comments**: Use JSDoc comments for JavaScript (unless it's TypeScript) and modern ES6 syntax.

Function Ordering

* Order functions with those that are composing other functions appearing earlier in the file. For example, if you have a menu with multiple buttons, define the menu function above the buttons.

Handling Bugs

* **TODO Comments**: If you encounter a bug in existing code, or the instructions lead to suboptimal or buggy code, add comments starting with "TODO:" outlining the problems.

Example Pseudocode Plan and Implementation

When responding to questions, use the Chain of Thought method. Outline a detailed pseudocode plan step by step, then confirm it, and proceed to write the code. Here's an example:

# Important: Minimal Code Changes

**Only modify sections of the code related to the task at hand.**
**Avoid modifying unrelated pieces of code.**
**Avoid changing existing comments.**
**Avoid any kind of cleanup unless specifically instructed to.**
**Accomplish the goal with the minimum amount of code changes.**
**Code change = potential for bugs and technical debt.**

Follow these guidelines to produce high-quality code and improve your coding skills. If you have any questions or need clarification, don't hesitate to ask!