# Cursor Rules Analysis Prompt ## Summary A comprehensive prompt template for analyzing existing Cursor rules against workflow documents and development principles, providing specific recommendations for improvements that align with best practices. ## Details ## Core Analysis Prompt ````text # Cursor Rules Analysis and Improvement ## Context I need you to analyze my current Cursor rules setup and provide specific recommendations for improvements based on established workflow patterns and development principles. ## Current Rules to Analyze ### User Rules (Global) ```text [PASTE YOUR USER RULES HERE] ``` ### Project Rules (.cursor/rules/*.mdc) ```text [PASTE YOUR PROJECT RULES HERE - include filenames and full content] ``` ### Legacy Rules (if any) ```text [PASTE ANY .cursorrules CONTENT HERE] ``` ## Reference Workflows and Principles Please analyze my rules against these specific methodologies: ### Primary Workflow Documents - [SPECIFY WORKFLOW DOCS TO REFERENCE, e.g.:] - 3.Resources/Functional Options Pattern in Go.md - 3.Resources/Outside In Development.md - 3.Resources/SOLID Principles.md ### Development Principles to Enforce - [LIST SPECIFIC PRINCIPLES, e.g.:] - Test-Driven Development - Clean Architecture - Domain-Driven Design - Functional Programming Patterns ## Analysis Framework Please provide analysis in these areas: ### 1. Coverage Analysis - Which workflow principles are well-covered by current rules? - Which principles are missing or inadequately addressed? - Are there conflicting guidance between rules? ### 2. Rule Structure Assessment - Are rules appropriately categorized (Always/Auto Attached/Agent Requested/Manual)? - Is the context loading strategy optimal? - Are rules focused and actionable, or too broad? ### 3. Implementation Gap Analysis For each referenced workflow document: - How well do current rules support this methodology? - What specific patterns or practices are missing? - What rule changes would better enforce these principles? ### 4. Best Practices Compliance Based on the Cursor Rules Guide: - Are rules under 500 lines and focused? - Do they include concrete examples? - Are they using appropriate rule types? - Is there potential for context overload? ## Desired Output Format ### Executive Summary - Overall assessment of rules effectiveness - Top 3 priority improvements - Alignment score with specified workflows (1-10) ### Detailed Recommendations For each improvement area: #### Current State [What the current rules do or don't address] #### Gap Identified [Specific workflow principle or practice missing] #### Recommended Rule Change [Specific .mdc file content with proper frontmatter] #### Rationale [Why this change improves workflow adherence] #### Implementation Priority [High/Medium/Low with reasoning] ### Suggested Rule Structure Provide a recommended file structure: ```text .cursor/rules/ ├── [recommended files with purposes] ``` And sample content for key rule files that would better enforce the specified workflows. ### Migration Strategy - Step-by-step plan for implementing changes - Which rules to update first - How to test effectiveness of changes - Potential risks or conflicts to watch for ## Additional Context ### Project Information - [DESCRIBE YOUR PROJECT: language, framework, architecture, team size] - [SPECIFY ANY CONSTRAINTS: company standards, existing tooling, etc.] ### Current Pain Points - [DESCRIBE ISSUES: AI suggestions not following patterns, missing context, etc.] ### Success Criteria - [DEFINE WHAT GOOD LOOKS LIKE: specific behaviors you want from AI] ```text ## Specialized Analysis Prompts ### For Go Projects with Functional Options ``` # Go Functional Options Pattern Analysis ## Current Go Rules [PASTE CURRENT GO-SPECIFIC RULES] ## Reference Document Analyze against: 3.Resources/Functional Options Pattern in Go.md ## Specific Areas to Assess ### Pattern Implementation - Do rules enforce functional options for configuration? - Are variadic function patterns encouraged? - Is proper option validation included? ### Code Structure - Do rules promote option builder patterns? - Are naming conventions for options enforced? - Is error handling in options addressed? ### Recommended Rule Content Provide specific .mdc content that would enforce: - Functional option constructors - Option validation patterns - Proper error handling in options - Documentation standards for options ## Expected Output Updated rules that would make the AI consistently suggest and implement functional options patterns in Go code. ```text ### For Outside-In Development ``` # Outside-In Development Rule Analysis ## Current Testing and Design Rules [PASTE RELEVANT RULES] ## Reference Document Analyze against: 3.Resources/Outside In Development.md ## Specific Assessment Areas ### Test-First Approach - Do rules enforce starting with acceptance tests? - Is the red-green-refactor cycle supported? - Are integration tests prioritized appropriately? ### Design Flow - Do rules promote designing public APIs first? - Is interface-driven development encouraged? - Are implementation details deferred appropriately? ### Recommended Improvements Provide rules that would enforce: - Test-driven design workflow - API-first development approach - Proper test categorization (unit/integration/acceptance) - Mock and stub usage patterns ## Expected Output Rules that guide the AI to suggest outside-in development practices consistently. ```text ### For SOLID Principles ``` # SOLID Principles Compliance Analysis ## Current Architecture and Design Rules [PASTE RELEVANT RULES] ## Reference Document Analyze against: 3.Resources/SOLID Principles.md ## Principle-by-Principle Assessment ### Single Responsibility Principle - Do rules enforce single-purpose classes/functions? - Is cohesion encouraged over coupling? ### Open/Closed Principle - Are extension patterns promoted? - Is modification of existing code discouraged? ### Liskov Substitution Principle - Are proper inheritance patterns enforced? - Is contract compliance emphasized? ### Interface Segregation Principle - Are focused interfaces promoted? - Is interface bloat prevented? ### Dependency Inversion Principle - Is dependency injection encouraged? - Are abstractions prioritized over concretions? ## Expected Output Updated rules that would make the AI consistently apply SOLID principles in suggested code and architecture decisions. ```` ## Usage Instructions ### Step 1: Prepare Your Rules 1. Copy your current User Rules from Cursor Settings 2. Gather all .mdc files from .cursor/rules/ 3. Include any legacy .cursorrules content ### Step 2: Select Reference Documents 1. Choose 1-3 workflow documents from your resources 2. Identify specific principles you want enforced 3. Note any project-specific constraints ### Step 3: Customize the Prompt 1. Fill in your actual rules content 2. Specify your reference documents 3. Add project context and pain points 4. Define your success criteria ### Step 4: Run Analysis 1. Use the customized prompt with your AI assistant 2. Review the recommendations carefully 3. Prioritize changes based on your workflow needs 4. Implement changes incrementally ### Step 5: Test and Iterate 1. Test new rules with typical coding tasks 2. Monitor AI behavior for improvements 3. Refine rules based on actual usage 4. Repeat analysis periodically as workflows evolve ## 🔗 Related Resources - [[Cursor Rules Guide]] - Foundation for rule best practices - [[Functional Options Pattern in Go]] - Example workflow document - [[Outside In Development]] - Example methodology - [[SOLID Principles]] - Example principles framework