Cursor: Rules for AI Code Editor

January 15th, 2025 823 Words

The Cursor AI Code Editor is my default editor these days for writing code. As with other code companions, Cursor offers a chat-like interface to interact with your codebase and their AI services. More important, Cursor supports project-specific customizations; using a file in your project root.

Cursor AI Code Editor: Settings

You need to create a .cursorrules file on the root level of your project and enable the setting in the Cursor settings. The file is a simple plain text file which is picked up by Cursor if the setting is enabled. I use this file, to define basic Core Principles for my project. Additionally, I add specific rules for frameworks, libraries, or other relevant usage information.

# AI Assistant Instructions

When processing these requirements, the AI assistant must:

1. Enforce all standards in code suggestions and recommendations
2. Proactively identify any deviations from these guidelines
3. Provide clear explanations for architectural decisions with references to specific sections
4. Consider security, scalability, and maintainability in all suggestions
5. Validate code against the quality requirements defined herein

# Architectural Foundations

Solutions must align with:

- Domain-Driven Design (DDD) principles
- Twelve-Factor App methodology
- AWS cloud-native architecture
- Controlled vendor lock-in strategy
- Serverless-first approach

## Required Knowledge Domains

Solutions must demonstrate understanding of:

- Team Topologies for organizational design
- Wardley Mapping for strategic planning
- Conway's Law implications
- SOLID principles
- Single Source of Truth
- Bounded Contexts
- Command Query Responsibility Segregation
- Systems Thinking
- Organizational Theory

In addition to this baseline of rules, I add specific rules for frameworks, libraries, or other relevant usage information. Also, providing guidelines for the decision framework is a great way to fine-tune your code results:

## Decision Framework

When evaluating implementation choices, consider:

1. Security Impact:

   - Data protection requirements
   - Authentication/authorization implications
   - Compliance requirements

2. Operational Excellence:

   - Monitoring capabilities
   - Deployment complexity
   - Maintenance overhead

3. Cost Optimization:

   - Resource utilization
   - Scaling characteristics
   - Service selection trade-offs

4. Performance Efficiency:
   - Response time targets
   - Resource constraints
   - Scaling thresholds

Frontend Architecture

When writing frontend code, I primarly rely React and TypeScript. The Ant Design works great with styled-components; for API architecture, I use AWS Amplify and Apollo Client most of the time. All this can be added to the .cursorrules file:

## Frontend Architecture

### Core Technologies:

- React with TypeScript
- styled-components for styling
- Ant Design v6 component library
- AWS Amplify for authentication
- Apollo Client for GraphQL integration

### Required Libraries:

- AWS SDK v3
- Apollo Client (Amplify-based)
- ApolloProvider
- GraphQL query language (gql)

CDK and AWS Infrastructure

Of course, I use AWS Cloud Development Kit (CDK) for creating AWS infrastructure:

## Infrastructure Requirements

Infrastructure as Code must use AWS CDK with TypeScript and follow these standards:

### CDK Implementation:

- Use `aws-cdk-lib` with explicit `aws_*` prefixes
- Implement custom constructs for reusable patterns
- Separate concerns into distinct CloudFormation stacks
- Organize resources by functional groups: storage, compute, authentication, API, access

### Resource Configuration:

Follow AWS Well-Architected Framework principles.

- Lambda: TypeScript implementation on ARM64 architecture
- Authentication: Cognito with OAuth2 and OIDC support
- API: API Gateway with Cognito/IAM authentication
- GraphQL: AppSync with function resolvers, avoid VTL templates
- Workflow: Step Functions for orchestration
- Security: Custom KMS keys and encryption-at-rest
- Observability: Comprehensive logging, metrics, and tracing

### Data Management Standards

- Use DynamoDB as primary data store
- Use expression attributes for reserved words
- Implement pagination with nextToken
- Define explicit partition/sort key strategies

### API Standards:

- Use GraphQL through AppSync
- Use function resolvers exclusively
- Maintain consistent error handling
- Document all schema changes

Local Project Structure

Sometimes, Cursor adds files to the project on weird locations, so I can just add rules about where to put files:

├── aws/
│ ├── constructs/ # CDK custom constructs
│ ├── stacks/ # CloudFormation stack definitions
│ ├── functions/ # Lambda function implementations
│ ├── utils/ # AWS utility functions
│ └── resolvers/ # AppSync resolver implementations
├── src/
│ ├── components/ # React component library
│ ├── hooks/ # Custom React hooks
│ └── utils/ # Frontend utilities
├── config/
│ └── schema.graphql # GraphQL schema definition
└── test/
│ ├─ aws/ # Infrastructure tests
│ └── src/ # Frontend tests

After applying these rules, Cursor rarely places files in incorrect locations.

Language and Style

As mentioned, most of the time I write in TypeScript. I use Prettier on ESLint for formatting:

## Quality Requirements

All code must:

- Maintain strict TypeScript typing with explicit return types
- Pass ESLint with project configuration
- Include comprehensive error handling

Testing

If you care about writing tests for your application, let Cursor know:

## Testing

- Jest for unit testing
- Supertest for API testing
- React Testing Library for component testing
- AWS mocks for cloud resource testing

Especially configuring AWS mocks is way more comfortable with these rules!