MDC Rules Generator

Cursor provides four distinct ways to provide persistent instructions to the AI Agent. Rules are included at the start of the model context to ensure consistent guidance.

1. Project Rules: Stored in .cursor/rules within your codebase. They are version-controlled and can be scoped to specific files or applied intelligently.
2. User Rules: Global to your specific Cursor environment; used by the Agent in Chat.
3. Team Rules: Managed via the Cursor dashboard (available on Team/Enterprise plans). These apply across all repositories for the team and take precedence over Project and User rules.
4. AGENTS.md: A simple markdown file used for agent instructions as an alternative to the .cursor/rules folder structure.

User Rules are global preferences defined in Cursor Settings → Rules. These apply across all projects and are used by the Agent (Chat) to set preferred communication styles or coding conventions.

Note: User Rules are not applied to Inline Edit (Cmd/Ctrl+K). They are only used by Agent (Chat).

Please reply in a concise style. Avoid unnecessary repetition or filler language.

Follow these security practices:

• Vulnerability Scanning: Regularly scan images using tools like Trivy or Clair.
• Network Security: Limit network exposure and use network policies to isolate containers.
• Input Validation: Validate all input data to prevent injection attacks.
• Secure Communication: Use HTTPS for all API communications and implement rate limiting to prevent abuse.
• Data Protection: Encrypt sensitive data both at rest and in transit.

Avoid monolithic .vimrc files by breaking down configurations into smaller, manageable files and using the source command to load them. This improves maintainability and allows for splitting by feature (e.g., plugins, settings, mappings) or file type.

Recommended pattern:

" ~/.vimrc
source ~/.vim/config/plugins.vim
source ~/.vim/config/settings.vim
source ~/.vim/config/mappings.vim

Prevent vulnerabilities in your environment:

• Shell Injection: Sanitize user input when executing shell commands via :!.
• Information Disclosure: Do not store sensitive data like API keys or passwords directly in .vimrc. Use environment variables or encrypted files instead.
• Input Validation: Use regular expressions to validate user input in scripts.
• API Security: Always use HTTPS and validate SSL certificates when communicating with external APIs.

Maintain a clear separation of concerns in your project root to ensure efficient builds and easy orchestration. A recommended structure includes:

• Dockerfile: For building the image.
• docker-compose.yml: For multi-container setup.
• .dockerignore: To specify files to exclude from the build context.
• app/: Application source code.
• config/: Configuration files.
• data/: Data files (though volumes are preferred for persistence).
• scripts/: Management, build, or deployment scripts.

Keep Dockerfile and docker-compose.yml at the project root. Use descriptive names for multiple Dockerfiles, such as Dockerfile.web or Dockerfile.api.

When configuring Vim, avoid these frequent mistakes to ensure stability and consistency:

• Inconsistent Indentation: Avoid mixing tabs and spaces.
• Global Settings Leakage: Avoid applying file-type settings globally. Use setlocal within ftplugin files to ensure settings only apply to specific file types.
• Global Variable Overuse: Minimize the use of global variables to prevent conflicts and unexpected behavior.
• Encoding and Line Endings: Ensure files are encoded in UTF-8 and be mindful of line endings (LF vs CRLF) when working across different operating systems.
• Unicode Handling: Be aware of how Unicode characters may impact Vim's behavior.

Cursor is moving away from legacy rule formats. Follow these migration paths:

• .cursorrules (Legacy): This file is still supported but will be deprecated. Migrate to Project Rules or AGENTS.md.
• .mdc rules: While functional as of version 2.2, all new rules should now be created as folders in .cursor/rules to improve readability and maintainability.

To ensure the AI Agent follows your guidelines accurately, follow these best practices:

• Keep it concise: Aim for rules under 500 lines.
• Modularize: Split large, complex rules into multiple, smaller, composable rules.
• Be specific: Avoid vague guidance; write rules like clear internal documentation.
• Provide context: Include concrete examples or reference specific files (e.g., using @filename).
• Reuse: If you find yourself repeating the same prompt in chat, turn it into a rule.

Use the following commands to debug Vim scripts and troubleshoot configuration issues:

• :messages: View error messages and other debugging information.
• :echo: Print the values of variables and expressions.
• :debug: Step through Vim scripts line by line.
• Logging: Manually log errors and debugging information to a file for persistent troubleshooting.

To maintain security and efficiency, avoid these common mistakes:

• Secrets Management: Never hardcode passwords or API keys in a Dockerfile or within images. Use tools like HashiCorp Vault or Kubernetes Secrets.
• Privilege Escalation: Avoid running services as the root user.
• Bloated Images: Do not install unnecessary packages. Use .dockerignore to exclude unnecessary files from the build context.
• Command Form: Avoid the shell form of CMD or ENTRYPOINT. Use the exec form (["executable", "param1", "param2"]) to ensure proper signal handling and prevent shell injection.
• File Operations: Use COPY instead of ADD unless specifically required, as COPY is more predictable.

For straightforward use cases that don't require complex metadata, you can use an AGENTS.md file. This is a plain markdown file placed in your project root or subdirectories. It is an alternative to the structured .cursor/rules system.

Key Features:

• Simplicity: No metadata or complex configuration required.
• Nested Support: You can place AGENTS.md in subdirectories for granular control. Instructions from nested files are combined with parent instructions, with more specific (nested) instructions taking precedence.

Example Directory Structure:

project/
  AGENTS.md              # Global instructions
  frontend/
    AGENTS.md            # Frontend-specific instructions
    components/
      AGENTS.md          # Component-specific instructions
  backend/
    AGENTS.md            # Backend-specific instructions