Organizing Cursor Rules & Commands Across Projects with Symlinks

madhu kiran — Mon, 06 Oct 2025 15:40:52 +0000

The Challenge

Working with Cursor AI across multiple projects, I wanted to:

Share custom AI rules that work well for my workflow
Reuse common commands and tools configurations
Experiment with different prompt templates without committing them
Keep project-specific customizations separate from team configurations
Maintain consistency across all my development work

The problem? I didn't want these personal configurations committed to version control, but I also didn't want to maintain separate copies in each project.

My Solution: Centralized Cursor Configuration

I created a central directory for all my Cursor configurations:

~/cursor-config/
├── rules/
│   ├── base-rules.md              # Base AI behavior rules
│   ├── java-rules.md              # Java-specific rules
│   ├── react-rules.md             # React-specific rules
│   └── solid-principles.md        # SOLID design principles
├── commands/
│   ├── github-pr-review.md        # PR review commands
│   ├── test-helpers.md            # Testing utilities
│   ├── refactor-patterns.md       # Refactoring templates
│   └── code-analysis.md           # Code analysis prompts
└── tools/
    ├── project-setup.sh           # Project initialization scripts
    ├── sync-dependencies.sh       # Dependency sync utilities
    └── code-formatters.json       # Formatting configurations

Symlinking Per Project

For each project, I symlink only the relevant files. Here's how I set up different types of projects:

Java Project :

cd ~/work/backend-app1

# Link base rules
ln -s ~/cursor-config/.cursor ./

React/Frontend Project:

cd ~/work/backend-app2

# Link base rules
ln -s ~/cursor-config/.cursor ./

Gitignore Configuration

In each project's .gitignore:

# Cursor AI - personal configs not to commit (symlinked from central config)
.cursor

This way, team-shared Cursor configurations stay in the repo, while my personal ones (symlinked) remain local and don't get committed.

Why This Works Brilliantly

Single source of truth: Update a rule or command once, all projects benefit immediately
Experiment freely: Test new AI instructions without cluttering repos
Context-aware: Cursor automatically discovers and uses these files
Mix and match: Combine base rules with project-specific customizations
Team-friendly: Personal preferences don't interfere with committed team configs
Zero maintenance: No copying, no syncing, no outdated versions

Benefits I've Experienced

Organized structure: .cursor/rules, .cursor/commands, .cursor/tools keep everything categorized
Faster onboarding: New projects get my full Cursor setup in seconds
Consistent AI behavior: Same quality assistance across all codebases
Easy iteration: Refine prompts based on what works, propagate instantly
Clean repos: Personal tooling doesn't pollute project history
Flexibility: Different projects can use different combinations of rules/commands/tools
Discoverability: Clear directory structure makes it obvious what's available

How to Set This Up

**Create your central config directory
Create your base rules / commands / tools:
Create symlinks to your central config:
Add symlinked files to .gitignore:
Repeat for all your projects!

The Bottom Line

Symlinks turned my scattered Cursor configurations into a coherent, maintainable system. One source of truth, infinite flexibility, zero overhead.

The .cursor/rules, .cursor/commands, and .cursor/tools structure provides:

Clear separation of concerns: Rules for AI behavior, commands for reusable prompts, tools for automation scripts
Easy navigation: Anyone (including future you) can quickly find what they need
Scalability: Add new rules, commands, or tools without cluttering the project root
Team compatibility: Team-committed configs and personal symlinked configs coexist peacefully

Sometimes the simplest Unix tools are still the most powerful ones. Who knew a 50-year-old feature would be the perfect solution for organizing AI coding assistant configurations?

Tip for Faster Debugging with Local Files with File Access MCP

madhu kiran — Mon, 15 Sep 2025 04:43:54 +0000

You can make debugging and troubleshooting much faster by exposing local files through an MCP (Model Context Protocol) file server. This allows tools like Cursor to directly query logs, config files, or any other resources without manually opening and searching through them.

Example: Pointing to a Logs Directory

{
  "mcpservers": {
    "logs": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/logs/"
      ]
    }
  }
}

With this setup, you can ask questions like:

“Has this record synced successfully?”

“Show me the last error message.”

“What’s the current status of this process?”

Generalizing for Any Files

You’re not limited to logs — you can point the MCP server at any directory you want. For example, if you want quick access to configuration files:

{
  "mcpservers": {
    "configs": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/configs/"
      ]
    }
  }
}

Now you can interact with configs conversationally, such as:

“What’s the current value of the timeout setting?”

“Show me the database connection string.”

“List all modified config files in this directory.”

✅ Key Benefits:

Faster debugging and issue resolution.

No need to manually grep or open files repeatedly.

Works with any directory: logs, configs, traces, or even custom data files.

DEV Community: madhu kiran