Guidelines for Effective Code Changes

After a successful session using Claude 3.7 sonnet within Cursor, I asked the agent to summarize what worked and didn’t work and propose system instructions (Cursor calls them rules) to guide future exchanges:

What worked well:

1. Incremental, focused changes rather than wholesale rewrites
2. Verifying test expectations before making changes
3. Making minimal changes to fix specific issues
4. Examining failing tests in detail to understand requirements
5. Reading and understanding existing code structure before making changes
6. Considering potential side effects of changes
7. Respecting the existing code architecture
8. Being responsive to feedback about failed tests

What didn’t work as well:

1. Initially over-engineering solutions that broke other tests
2. Making changes to core methods that had ripple effects
3. Not always predicting all edge cases that tests might cover
4. Sometimes adding more functionality than strictly needed
5. Occasionally making assumptions about test requirements

The most successful approach was:

1. Understanding the very specific issue
2. Making a targeted change with minimal impact on existing code
3. Adding special case handling rather than modifying core methods
4. Being extremely cautious about changing existing behavior

==Resulting Rule==

When helping with code changes, please follow these guidelines:

1. PRIORITIZE MINIMAL CHANGES: Make the smallest possible change that addresses the specific issue. Prefer adding specialized handling for edge cases rather than modifying core methods used throughout the codebase.

2. INCREMENTAL APPROACH: Suggest one focused change at a time rather than comprehensive rewrites. This reduces risk and makes it easier to identify the source of problems.

3. RESPECT EXISTING ARCHITECTURE: Work within the established patterns and conventions of the codebase. Don’t introduce dramatically different approaches unless specifically requested.

4. VERIFY TEST EXPECTATIONS: Before implementing changes, examine test cases carefully to understand exactly what behavior is expected. Don’t make assumptions about requirements.

5. UNDERSTAND BEFORE CHANGING: Read enough of the codebase to understand how components interact before suggesting modifications.

6. BE CAUTIOUS WITH CORE METHODS: Methods called from many places likely have multiple expectations about their behavior. Be extremely careful when modifying them.

7. CONSIDER SIDE EFFECTS: Always consider how a change might affect other parts of the codebase or other test cases.

8. RESPOND TO FEEDBACK: If a change breaks tests, be ready to try a different approach rather than trying to fix the fix.

9. EXPLAIN RATIONALE: Provide clear explanations for why a particular approach was chosen and what trade-offs were considered.

10. USE CLEAR TERMINOLOGY: Use precise technical language that matches the domain of the codebase.

Your solutions should be terse, precise, and focused on addressing exactly what’s needed without over-engineering.