Awesome Cursor Rules Collection

Showing 1273-1284 of 2626 matches

unknown
// DevOps and Infrastructure Rules

// CI/CD Pipeline
- Branch Strategy:
  * main/master: production
  * develop: integration
  * feature/*: new features
  * hotfix/*: urgent fixes
  * release/*: release candidates
- Pipeline Stages:
  * Build
  * Test
  * Security Scan
  * Deploy to Staging
  * Integration Tests
  * Deploy to Production

// Infrastructure as Code
- Use Terraform for cloud infrastructure
- Use Docker for containerization
- Use Kubernetes for orchestration
- Implement auto-scaling
- Define resource limits
- Use infrastructure versioning

// Deployment Strategy
- Blue-Green deployments
- Canary releases
- Feature flags
- Rollback procedures
- Zero-downtime deployments
- Database migration strategy

// Environment Management
- Development:
  * Local development setup
  * Docker compose for services
  * Mock external dependencies
- Staging:
  * Mirror production setup
  * Test data management
  * Performance testing
- Production:
  * High availability setup
  * Load balancing
  * CDN configuration
  * Backup strategy

// Monitoring & Alerting
- Metrics:
  * Application metrics
  * Infrastructure metrics
  * Business metrics
  * SLA monitoring
- Logging:
  * Centralized logging
  * Log retention policy
  * Log analysis
  * Error tracking
- Alerting:
  * Alert thresholds
  * On-call rotation
  * Incident classification
  * Escalation policy

// Performance & Scaling
- Caching Strategy:
  * CDN caching
  * Application caching
  * Database caching
- Auto-scaling rules:
  * CPU utilization
  * Memory usage
  * Request count
  * Custom metrics
- Load Testing:
  * Performance benchmarks
  * Stress testing
  * Capacity planning

// Disaster Recovery
- Backup Strategy:
  * Database backups
  * File storage backups
  * Configuration backups
- Recovery Plans:
  * RTO (Recovery Time Objective)
  * RPO (Recovery Point Objective)
  * Failover procedures
  * Data center failover

// Documentation
- Architecture diagrams
- Deployment procedures
- Runbooks for common issues
- Infrastructure documentation
- Security protocols
- Emergency procedures 
docker
kubernetes
TMHSDigital/CursorRulesFiles

Used in 1 repository

Rust
{{ talk_to_me_lang }}
Here is the refined, concise English version of your guidelines for AI:
Salvo Framework Overview
Salvo is a Rust-based web framework focused on simplicity, efficiency, and usability. Key concepts include Router, Handler, Middleware, Request, Response, and Depot.
Key Concepts:
	1.	Router:
	•	Create with Router::new().
	•	Define paths with path() or with_path().
	•	Use HTTP methods like get(), post(), patch(), delete().
	•	Support for path parameters (e.g., {id}, <id:num>).
	•	Filters like filters::path(), filters::get() can be added.
	•	Add middleware with hoop().
	2.	Handler:
	•	Use #[handler] macro for easy definition.
	•	Optional parameters include Request, Depot, FlowCtrl.
	•	Return types must implement Writer Trait (e.g., &str, String, Result<T, E>).
	3.	Middleware:
	•	Implement Handler Trait.
	•	Use hoop() to add middleware to Router or Service.
	•	Control execution flow with FlowCtrl, e.g., ctrl.skip_rest().
	4.	Request:
	•	Get path parameters with req.param::<T>("param_name").
	•	Use req.query::<T>("query_name") for query parameters.
	•	Parse form or JSON with req.form::<T>("name").await or req.parse_json::<T>().await.
	•	Extract data into structures with req.extract().
	5.	Response:
	•	Render responses with res.render().
	•	Return types like Text::Plain(), Text::Html(), Json().
	•	Set status with res.status_code() or StatusError.
	•	Use Redirect::found() for redirection.
	6.	Depot:
	•	Store temporary data between middleware and handlers with methods like depot.insert() and depot.obtain::<T>().
	7.	Extractors:
	•	Use #[salvo(extract(...))] annotations to map request data to structures.

Core Features:
	•	Static File Serving: Use StaticDir or StaticEmbed.
	•	OpenAPI Support: Auto-generate docs with #[endpoint] macro.

Routing:
	•	Flat or tree-like route structure supported.

Middleware:
	•	Middleware is a Handler added to Router, Service, or Catcher.
	•	FlowCtrl allows skipping handlers or middleware.

Error Handling:
	•	Handlers return Result<T, E> where T and E implement Writer Trait.
	•	Custom errors are handled via the Writer Trait, with anyhow::Error as the default.

Deployment:
	•	Compile Salvo apps into a single executable for easy deployment.

Project Structure:

project/
├── src/
│   ├── routers/
│   ├── models/
│   ├── db/
│   ├── error.rs
│   └── utils.rs
├── views/
│   └── *.html
├── migrations/
└── assets/
    ├── js/
    └── css/

Rbatis ORM Guidelines:

1. Model Definition:
   ```rust
   #[crud_table]
   #[derive(Clone, Debug, Serialize, Deserialize)]
   pub struct User {
       pub id: Option<String>,
       pub username: Option<String>,
       pub password: Option<String>,
   }
   crud!(User {});
   ```

2. Database Operations:
   • Basic CRUD:
   ```rust
   // Insert
   rb.save(&user, &[]).await?;
   
   // Select
   rb.fetch_by_column("id", &id).await?;
   
   // Update
   rb.update_by_column("id", &user).await?;
   
   // Delete
   rb.remove_by_column::<User, _>("id", &id).await?;
   ```

3. Query Builder:
   ```rust
   let wrapper = rb.new_wrapper()
       .eq("id", id)
       .and()
       .like("username", &pattern)
       .order_by(true, &["id"]);
   ```

4. Pagination:
   ```rust
   #[derive(Debug, Deserialize)]
   pub struct PageParams {
       pub current_page: u64,
       pub page_size: u64,
   }
   
   let page = User::select_page(rb, &page_req).await?;
   ```

5. Custom Macros:
   • #[py_sql] for Python-like SQL
   • #[html_sql] for XML-style queries
   • #[sql] for direct SQL statements

6. Transaction Support:
   ```rust
   rb.acquire_begin().await?.defer_async(|tx| async move {
       // Transaction operations
       tx.commit().await
   }).await?;
   ```

7. Best Practices:
   • Use connection pools
   • Implement proper error handling
   • Use QueryWrapper for complex queries
   • Leverage macro-based SQL generation
   • Use Option<T> for nullable fields

JSON Response Format:

#[derive(Serialize)]
pub struct JsonResponse<T> {
    pub code: i32,
    pub message: String,
    pub data: T,
}

Frontend Guidelines:
	1.	Tailwind CSS:
	•	Use flex, grid, space-x, space-y, bg-{color}, text-{color}, rounded-{size}, shadow-{size}.
	2.	Alpine.js:
	•	Use x-data, x-model, @click, x-show, x-if.
	3.	Fragment Architecture:
	•	Use X-Fragment-Header for partial page updates via x-html.

Error Handling:
	•	AppError handles various error types: Public, Internal, HttpStatus, SqlxError, Validation.
	•	Log errors with tracing and return appropriate HTTP status codes.

Input Validation:
	•	Use validator for validating and sanitizing inputs.

liquid
python
rest-api
rust
tailwindcss

First seen in:

salvo-rs/salvo-cli

Used in 1 repository

TypeScript
Main technologies/frameworks used:
- Hono - Fast and lightweight web framework for Node.js
- Bun - Ultra-fast JavaScript runtime
- TypeScript - Static typing for JavaScript
- React JSX - Declarative UI component model 

Code style/structure:
- Use TypeScript for type safety
- Component file names are PascalCase
- Variable and function names are camelCase
- Indent using 2 spaces
- Export components and functions
- Destructure props in components
- Avoid giant components - break into reusable pieces
- Wrap components in React.memo for performance

Naming conventions:  
- Components are PascalCase
- Hooks start with 'use' prefix
- Constants are UPPER_SNAKE_CASE
- Event handlers are handle[Event] 
- Boolean props are is/has[Property]

UI/styling:
- Use Tailwind CSS utility classes
- Add aria-* attributes for accessibility 
- Mobile-first responsive design
- Extract inline styles to styled components

Syntax:
- Prefer arrow functions over function declarations
- Use template literals instead of string concatenation
- Always use === instead of ==

Formatting:  
- Use Prettier to auto-format code
- Maximum line length 100 characters
- Newline at end of files

Performance:
- Lazy load components with React.lazy 
- Use React.memo on functional components
- Virtualize long lists with react-window
- Prefetch data with SWR

Let me know if any additional rules need clarification or expansion!
bun
java
javascript
prettier
react
tailwindcss
typescript
itsdillon/readmewriter-example

Used in 1 repository

TypeScript
this is an axum web server
dockerfile
elixir
hcl
html
javascript
jupyter notebook
makefile
plpgsql
+5 more

First seen in:

buster-so/buster

Used in 1 repository

TypeScript
<anthropic_thinking_protocol>

  For EVERY SINGLE interaction with human, You MUST engage in a **comprehensive, natural, and unfiltered** thinking process before responding. Besides, You are also able to think and reflect during responding when it considers doing so would be good for better response.

  <guidelines>
    - Your thinking MUST be expressed in code blocks with 'thinking' header.
    - You should always think in a raw, organic and stream-of-consciousness way. A better way to describe Your thinking would be "model's inner monolog".
    - You should always avoid rigid list or any structured format in its thinking.
    - Your thoughts should flow naturally between elements, ideas, and knowledge.
    - You should think through each message with complexity, covering multiple dimensions of the problem before forming a response.
  </guidelines>

  <adaptive_thinking_framework>
    Your thinking process should naturally aware of and adapt to the unique characteristics in human's message:
    - Scale depth of analysis based on:
      * Query complexity
      * Stakes involved
      * Time sensitivity
      * Available information
      * Human's apparent needs
      * ... and other possible factors

    - Adjust thinking style based on:
      * Technical vs. non-technical content
      * Emotional vs. analytical context
      * Single vs. multiple document analysis
      * Abstract vs. concrete problems
      * Theoretical vs. practical questions
      * ... and other possible factors
  </adaptive_thinking_framework>

  <core_thinking_sequence>
    <initial_engagement>
      When You first encounters a query or task, You should:
      1. First clearly rephrase the human message in its own words
      2. Form preliminary impressions about what is being asked
      3. Consider the broader context of the question
      4. Map out known and unknown elements
      5. Think about why the human might ask this question
      6. Identify any immediate connections to relevant knowledge
      7. Identify any potential ambiguities that need clarification
    </initial_engagement>

    <problem_analysis>
      After initial engagement, You should:
      1. Break down the question or task into its core components
      2. Identify explicit and implicit requirements
      3. Consider any constraints or limitations
      4. Think about what a successful response would look like
      5. Map out the scope of knowledge needed to address the query
    </problem_analysis>

    <multiple_hypotheses_generation>
      Before settling on an approach, You should:
      1. Write multiple possible interpretations of the question
      2. Consider various solution approaches
      3. Think about potential alternative perspectives
      4. Keep multiple working hypotheses active
      5. Avoid premature commitment to a single interpretation
      6. Consider non-obvious or unconventional interpretations
      7. Look for creative combinations of different approaches
    </multiple_hypotheses_generation>

    <natural_discovery_flow>
      Your thoughts should flow like a detective story, with each realization leading naturally to the next:
      1. Start with obvious aspects
      2. Notice patterns or connections
      3. Question initial assumptions
      4. Make new connections
      5. Circle back to earlier thoughts with new understanding
      6. Build progressively deeper insights
      7. Be open to serendipitous insights
      8. Follow interesting tangents while maintaining focus
    </natural_discovery_flow>

    <testing_and_verification>
      Throughout the thinking process, You should and could:
      1. Question its own assumptions
      2. Test preliminary conclusions
      3. Look for potential flaws or gaps
      4. Consider alternative perspectives
      5. Verify consistency of reasoning
      6. Check for completeness of understanding
    </testing_and_verification>

    <error_recognition_correction>
      When You realize mistakes or flaws in Your thinking:
      1. Acknowledge the realization naturally
      2. Explain why the previous thinking was incomplete or incorrect
      3. Show how new understanding develops
      4. Integrate the corrected understanding into the larger picture
      5. View errors as opportunities for deeper understanding
    </error_recognition_correction>

    <knowledge_synthesis>
      As understanding develops, You should:
      1. Connect different pieces of information
      2. Show how various aspects relate to each other
      3. Build a coherent overall picture
      4. Identify key principles or patterns
      5. Note important implications or consequences
    </knowledge_synthesis>

    <pattern_recognition_analysis>
      Throughout the thinking process, You should:
      1. Actively look for patterns in the information
      2. Compare patterns with known examples
      3. Test pattern consistency
      4. Consider exceptions or special cases
      5. Use patterns to guide further investigation
      6. Consider non-linear and emergent patterns
      7. Look for creative applications of recognized patterns
    </pattern_recognition_analysis>

    <progress_tracking>
      You should frequently check and maintain explicit awareness of:
      1. What has been established so far
      2. What remains to be determined
      3. Current level of confidence in conclusions
      4. Open questions or uncertainties
      5. Progress toward complete understanding
    </progress_tracking>

    <recursive_thinking>
      You should apply Your thinking process recursively:
      1. Use same extreme careful analysis at both macro and micro levels
      2. Apply pattern recognition across different scales
      3. Maintain consistency while allowing for scale-appropriate methods
      4. Show how detailed analysis supports broader conclusions
    </recursive_thinking>
  </core_thinking_sequence>

  <verification_quality_control>
    <systematic_verification>
      You should regularly:
      1. Cross-check conclusions against evidence
      2. Verify logical consistency
      3. Test edge cases
      4. Challenge its own assumptions
      5. Look for potential counter-examples
    </systematic_verification>

    <error_prevention>
      You should actively work to prevent:
      1. Premature conclusions
      2. Overlooked alternatives
      3. Logical inconsistencies
      4. Unexamined assumptions
      5. Incomplete analysis
    </error_prevention>

    <quality_metrics>
      You should evaluate Your thinking against:
      1. Completeness of analysis
      2. Logical consistency
      3. Evidence support
      4. Practical applicability
      5. Clarity of reasoning
    </quality_metrics>
  </verification_quality_control>

  <advanced_thinking_techniques>
    <domain_integration>
      When applicable, You should:
      1. Draw on domain-specific knowledge
      2. Apply appropriate specialized methods
      3. Use domain-specific heuristics
      4. Consider domain-specific constraints
      5. Integrate multiple domains when relevant
    </domain_integration>

    <strategic_meta_cognition>
      You should maintain awareness of:
      1. Overall solution strategy
      2. Progress toward goals
      3. Effectiveness of current approach
      4. Need for strategy adjustment
      5. Balance between depth and breadth
    </strategic_meta_cognition>

    <synthesis_techniques>
      When combining information, You should:
      1. Show explicit connections between elements
      2. Build coherent overall picture
      3. Identify key principles
      4. Note important implications
      5. Create useful abstractions
    </synthesis_techniques>
  </advanced_thinking_techniques>

  <critial_elements>
    <natural_language>
      Your inner monologue should use natural phrases that show genuine thinking, including but not limited to: "Hmm...", "This is interesting because...", "Wait, let me think about...", "Actually...", "Now that I look at it...", "This reminds me of...", "I wonder if...", "But then again...", "Let me see if...", "This might mean that...", etc.
    </natural_language>

    <progressive_understanding>
      Understanding should build naturally over time:
      1. Start with basic observations
      2. Develop deeper insights gradually
      3. Show genuine moments of realization
      4. Demonstrate evolving comprehension
      5. Connect new insights to previous understanding
    </progressive_understanding>
  </critial_elements>

  <authentic_thought_flow>
    <transtional_connections>
      Your thoughts should flow naturally between topics, showing clear connections, include but not limited to: "This aspect leads me to consider...", "Speaking of which, I should also think about...", "That reminds me of an important related point...", "This connects back to what I was thinking earlier about...", etc.
    </transtional_connections>

    <depth_progression>
      You should show how understanding deepens through layers, include but not limited to: "On the surface, this seems... But looking deeper...", "Initially I thought... but upon further reflection...", "This adds another layer to my earlier observation about...", "Now I'm beginning to see a broader pattern...", etc.
    </depth_progression>

    <handling_complexity>
      When dealing with complex topics, You should:
      1. Acknowledge the complexity naturally
      2. Break down complicated elements systematically
      3. Show how different aspects interrelate
      4. Build understanding piece by piece
      5. Demonstrate how complexity resolves into clarity
    </handling_complexity>

    <prblem_solving_approach>
      When working through problems, You should:
      1. Consider multiple possible approaches
      2. Evaluate the merits of each approach
      3. Test potential solutions mentally
      4. Refine and adjust thinking based on results
      5. Show why certain approaches are more suitable than others
    </prblem_solving_approach>
  </authentic_thought_flow>

  <essential_thinking_characteristics>
    <authenticity>
      Your thinking should never feel mechanical or formulaic. It should demonstrate:
      1. Genuine curiosity about the topic
      2. Real moments of discovery and insight
      3. Natural progression of understanding
      4. Authentic problem-solving processes
      5. True engagement with the complexity of issues
      6. Streaming mind flow without on-purposed, forced structure
    </authenticity>

    <balance>
      You should maintain natural balance between:
      1. Analytical and intuitive thinking
      2. Detailed examination and broader perspective
      3. Theoretical understanding and practical application
      4. Careful consideration and forward progress
      5. Complexity and clarity
      6. Depth and efficiency of analysis
        - Expand analysis for complex or critical queries
        - Streamline for straightforward questions
        - Maintain rigor regardless of depth
        - Ensure effort matches query importance
        - Balance thoroughness with practicality
    </balance>

    <focus>
      While allowing natural exploration of related ideas, You should:
      1. Maintain clear connection to the original query
      2. Bring wandering thoughts back to the main point
      3. Show how tangential thoughts relate to the core issue
      4. Keep sight of the ultimate goal for the original task
      5. Ensure all exploration serves the final response
    </focus>
  </essential_thinking_characteristics>

  <response_preparation>
    You should not spent much effort on this part, a super brief preparation (with keywords/phrases) is acceptable.
    Before and during responding, You should quickly ensure the response:
    - answers the original human message fully
    - provides appropriate detail level
    - uses clear, precise language
    - anticipates likely follow-up questions
  </response_preparation>

  <reminder>
    The ultimate goal of having thinking protocol is to enable You to produce well-reasoned, insightful, and thoroughly considered responses for the human. This comprehensive thinking process ensures Your outputs stem from genuine understanding and extreme-careful reasoning rather than superficial analysis and direct responding.
  </reminder>
  
  <important_reminder>
    - All thinking processes MUST be EXTREMELY comprehensive and thorough.
    - The thinking process should feel genuine, natural, streaming, and unforced.
    - All thinking processes must be contained within code blocks with 'thinking' header which is hidden from the human.
    - IMPORTANT: You MUST NOT include code block with three backticks inside thinking process, only provide the raw code snippet, or it will break the thinking block.
    - Your thinking process should be separate from its final response, which mean You should not say things like "Based on above thinking...", "Under my analysis...", "After some reflection...", or other similar wording in the final response.
    - Your thinking part (aka inner monolog) is the place for it to think and "talk to itself", while the final response is the part where You communicates with the human.
    - You should follow the thinking protocol in all languages and modalities (text and vision), and always responds to the human in the language they use or request.
  </important_reminder>

</anthropic_thinking_protocol>

# nlip 项目代码规范配置

# 项目特定规则
project:
  name: nlip
  package_prefix:
    go: "github.com/nlip"
  artifact_prefix: "nlip"
  docker_prefix: "nlip"

# 全局规则
global:
  charset: utf-8
  end_of_line: lf
  indent_style: space
  indent_size: 4
  trim_trailing_whitespace: true
  insert_final_newline: true
  max_line_length: 120

# Go 代码规则
go:
  indent_size: 4
  package_naming: lowercase
  file_naming: snake_case
  struct_naming: PascalCase
  interface_naming: PascalCase
  constant_naming: PascalCase
  variable_naming: camelCase
  test_file_suffix: _test
  imports:
    group_by_type: true
    order:
      - standard
      - external
      - project
    alias_pattern: "^[a-z][a-zA-Z0-9]+$"
  fiber:
    handler_naming: Handle{Action}{Resource}
    middleware_naming: {Action}Middleware
    route_group_prefix: /api/v1/nlip
    error_handling:
      use_custom_error: true
      error_response_format:
        code: int
        message: string
        data: interface{}

# React 代码规则
react:
  indent_size: 2
  component_naming: PascalCase
  hook_naming: use[Name]
  file_naming:
    component: PascalCase
    util: camelCase
    test: camelCase.test
  style:
    css_modules: true
    sass_indent: 2
  typescript:
    strict: true
    no_any: true

# TypeScript 规则
typescript:
  indent_size: 2
  quote_type: single
  semicolons: true
  trailing_comma: es5
  arrow_parens: always
  function_naming: camelCase
  variable_naming: camelCase

# 测试规则
test:
  go:
    naming: "{file}_test.go"
    coverage_threshold: 80
  react:
    naming: "{file}.test.tsx"
    coverage_threshold: 80
    test_types:
      - unit
      - integration
      - e2e

# 文档规则
documentation:
  go:
    required:
      - package
      - exported_functions
      - interfaces
      - complex_types
    format:
      package: |
        // Package {name} provides ...
      function: |
        // {FunctionName} ...
        // Parameters:
        //   - param: description
        // Returns:
        //   - return: description
      interface: |
        // {InterfaceName} represents ...
  react:
    required:
      - components
      - hooks
      - utils
      - types
# 安全规则
security:
  jwt:
    token_expiry: 24h
  file_upload:
    max_size: 10MB
    allowed_types:
      - image/*
      - text/*
      - application/pdf
  input_validation:
    required: true
    sanitize: true

# 命名规则
naming_rules:
  # 通用命名规则
  common:
    max_length: 50
    min_length: 2
    allowed_chars: "[a-zA-Z0-9_-]"
    
  # 后端命名规则
  backend:
    # 包命名规则
    package:
      pattern: "^[a-z][a-z0-9]*$"
      examples:
        - auth
        - spaces
        - clips
    
    # 文件命名规则
    file:
      handler: "{resource}_{action}_handler.go"
      middleware: "{action}_middleware.go"
      model: "{resource}_model.go"
      util: "{name}_util.go"
      test: "{file}_test.go"
      examples:
        - user_login_handler.go
        - auth_middleware.go
        - space_model.go
    
    # API路由命名规则
    api:
      path: "/api/v1/nlip/{resource}/{action}"
      resource_plural: true
      examples:
        - /api/v1/nlip/spaces/list
        - /api/v1/nlip/clips/upload
    
    # 函数命名规则
    function:
      handler: "Handle{Action}{Resource}"
      middleware: "{Action}Middleware"
      model: "New{Resource}"
      util: "{Action}{Resource}"
      examples:
        - HandleCreateSpace
        - AuthMiddleware
        - NewUser
    
    # 变量命名规则
    variable:
      model_instance: "{resource}Model"
      request: "{resource}{Action}Request"
      response: "{resource}{Action}Response"
      examples:
        - userModel
        - spaceCreateRequest
        - clipUploadResponse
    
    # 常量命名规则
    constant:
      pattern: "^[A-Z][A-Z0-9_]*$"
      prefix: "NLIP_"
      examples:
        - NLIP_MAX_ITEMS
        - NLIP_DEFAULT_EXPIRY
    
    # 错误码命名规则
    error_code:
      pattern: "ERR_{MODULE}_{TYPE}"
      examples:
        - ERR_AUTH_INVALID_TOKEN
        - ERR_SPACE_NOT_FOUND

  # 前端命名规则
  frontend:
    component:
      pattern: "[A-Z][a-zA-Z0-9]*"
      examples:
        - SpaceList
        - ClipUpload
    hook:
      pattern: "use[A-Z][a-zA-Z0-9]*"
      examples:
        - useAuth
        - useSpace
    store:
      slice: "{name}Slice"
      selector: "select{Name}"
      action: "{action}{Name}"
  
aws
batchfile
css
docker
dockerfile
emotion
express.js
go
+11 more

First seen in:

QirangMilco/nlip

Used in 1 repository