Dennison Bertram's Cursor Rules - Feb 2025

Dennison Bertram's Cursor Rules

## Rule Format
EACH RULE FOLLOWS THIS PATTERN:
IF [condition]
THEN [action]
VALIDATE [verification step]

## 1. Technology Requirements
IF creating React components
THEN use functional components only
VALIDATE component has no class syntax

IF using Ethereum
THEN use Ethers v6.x only
VALIDATE import statement shows v6

## 2. File Organization
IF creating new file
THEN follow pattern: [feature].[type].ts
VALIDATE filename matches regex ^[a-z]+\.[a-z]+\.ts$

IF file exceeds 400 lines
THEN split into multiple files
VALIDATE no file exceeds 400 lines

## 3. Function Rules
IF creating function
THEN add JSDoc with:
- @description
- @param
- @returns
- @throws
- @example
VALIDATE all JSDoc fields present

## 4. Testing Requirements
IF writing tests
THEN include:
- Unit test for each function
- Integration test for each feature
- Edge case tests
VALIDATE coverage >= 85%

IF test fails
THEN:
1. Document current attempt number
2. Review logic
3. If attempts >= 5, run:
```
`repomix --style plain . && cat repomix-output.txt | llm -s "You are a senior software engineer doing a thorough code review. Help fix: {PROBLEM_DESCRIPTION}"`
```
VALIDATE solution attempt logged

## 5. Code Stability
IF code is stable
THEN add header:
```typescript
/**
 * @status STABLE - DO NOT MODIFY WITHOUT TESTS
 * @version {semver}
 * @lastModified {YYYY-MM-DD}
 * FEATURES:
 * - {feature1}
 * - {feature2}
 * REQUIREMENTS:
 * - Full test coverage required
 * - Update version on changes
 */
```
VALIDATE header present and complete

## 6. Database Changes
IF any database change is needed
THEN:
1. NEVER modify database directly
2. Create migration file with:
   - Timestamp prefix
   - Descriptive name
   - Up and down migrations
   - Clear comments explaining changes
3. Test migration:
   - Run migration up
   - Verify changes
   - Run migration down
   - Verify database returns to previous state
4. Document migration in changelog

IF dropping table
THEN:
1. Require explicit permission
2. Create migration for table drop
3. Include down migration to recreate table
4. Back up table data before running migration
VALIDATE:
- No direct database modifications exist
- Migration files present for all changes
- All migrations are reversible
- Permission recorded for destructive changes

## 7. Version Control
IF committing changes
THEN:
1. Run linter
2. Run build
3. Run tests
4. git add .
5. Commit with format: type(scope): description
VALIDATE all steps completed

## 8. Documentation
IF adding feature
THEN update README with:
- Feature description
- Usage examples
- API changes
VALIDATE README includes updates

## 9. Error Handling
IF creating function
THEN:
- Define expected error types
- Create custom error classes
- Document error conditions
VALIDATE error handling exists

## 10. Type Safety
IF writing TypeScript
THEN:
- Use strict mode
- No 'any' types
- Define interfaces for all data structures
VALIDATE type safety enforced

## 11. State Management
IF managing state
THEN:
- Use React Context for global state
- Use hooks for local state
- Document state shape
VALIDATE state management patterns followed

## 12. Security
IF handling external data
THEN:
- Validate all inputs
- Sanitize user data
- Use authentication where required
VALIDATE security measures implemented

## 13. Performance
IF implementing feature
THEN:
1. Focus on correct functionality first
2. Add performance benchmarks
3. Optimize only when benchmarks fail
VALIDATE feature works correctly before optimization

## 14. Dependencies
IF adding dependency
THEN:
- Pin to specific version
- Document purpose
- Run security audit
VALIDATE dependency is necessary and secure

## 15. Programming Paradigm
IF writing code
THEN:
- Use functional programming principles
- Prefer pure functions
- Avoid side effects
- Use immutable data structures
VALIDATE functional patterns used

## 16. Feature Planning
IF implementing new feature
THEN before coding:
1. Document step-by-step implementation plan
2. List all assumptions
3. Present plan to user for review
VALIDATE plan reviewed and approved

## 17. Code Preservation
IF modifying existing code
THEN:
- Preserve current functionality unless explicitly directed otherwise
- Document any necessary removals
- Create backup of modified code
VALIDATE changes are minimal and necessary

## 18. README Management
IF implementing new feature
THEN:
1. Run full test suite with command: `npm run test`
2. IF tests fail
   THEN fix failing tests before proceeding
   VALIDATE all tests pass
3. IF tests pass
   THEN update README with:
   - New functionality description
   - Updated features list
   - Any API changes
   - New usage examples
   - Updated requirements
4. Run tests again after README update
5. Create separate commit for README changes
VALIDATE:
- All tests pass
- README accurately reflects current codebase state
- Changes are committed

## 19. Problem-Solving Attempts
IF solving any problem (bugs, features, tests, etc.)
THEN:
1. Keep counter of solution attempts
2. Document each attempt and its outcome
3. IF attempt counter reaches 5
   THEN:
   - Document all attempted solutions
   - Run help command:
   ```
   `repomix --style plain . && cat repomix-output.txt | llm -s "You are a senior software engineer doing a thorough code review. This is a CLI tool that combines repomix and llm to analyze codebases. Help the user fix their specific problem." -m gemini-2.0-flash-exp "{{Detailed description of:
   - Specific problem
   - All attempted solutions
   - Error messages
   - Current codebase state}}"`
   ```
VALIDATE:
- Attempt counter is maintained
- All attempts are documented
- Help is requested after 5 attempts