Feature Request: Per-Project “Rules Validator” Script for Shell Commands and LLM Context
Overview
I’d like to propose a new feature for Cursor: the ability to define a per-project “rules validator” script that runs before any shell command is displayed for confirmation or before certain LLM-driven actions are finalized. This would enhance control over Cursor’s behavior, ensuring it adheres to project-specific rules and preferences more reliably.
Problem
Currently, I’ve set up rules in Cursor to enforce the use of a specific package manager (e.g., pnpm) for all shell commands, explicitly listing the commands it should use. However, Cursor frequently ignores these rules and defaults to a different package manager (e.g., npm) until I manually intervene and remind it. This inconsistency disrupts workflows and requires constant oversight.
Additionally, when the agent processes code or responds to requests, it sometimes loses track of the original context or intent, leading to irrelevant or suboptimal suggestions. There’s no flexible, project-specific way to enforce guardrails or validate its actions before they’re presented.
Proposed Solution
1. Pre-Shell Command Validator Script
Add support for a user-defined script (e.g., in JavaScript, Python, or Bash) that runs before any shell command is displayed for confirmation. This script would:
- Take the proposed shell command as input.
- Allow simple checks (e.g., regex or keyword matching) to flag or modify commands that violate project rules.
- Example: If I never want npm in my project, the script could reject commands containing npmand suggest pnpm instead, or halt the process with an error message.
Use Case Example:
- Input command: npm install lodash
- Validator script: Checks for npm, rejects it, and suggests pnpm install lodash (or auto-corrects it).
- Outcome: Ensures consistency with my project’s package manager without manual reminders.
2. Expanded Context-Aware Validation (Optional Enhancement)
Extend the validator script concept to integrate with a CursorContext object (or similar API) that provides:
- Access to the current session’s code, user request, and LLM intent.
- The ability to fire off secondary LLM requests in a separate session to validate or refine the agent’s behavior.
This would allow the script to enforce more abstract or context-dependent rules, like ensuring the agent’s response aligns with the original request. The script could:
- Analyze the proposed response or command.
- Query an LLM (e.g., “Does this command align with the user’s request to optimize for performance?”).
- Return feedback or a corrected suggestion to the primary agent.
Use Case Example:
- User request: “Optimize this function for speed.”
- Agent proposes: A command or code snippet that’s unrelated to performance.
- Validator script: Detects the mismatch via a secondary LLM call, returns a rejection or refined suggestion, keeping the agent on track.
3. Per-Project Flexibility
- Store the validator script in a project-specific file (e.g., .cursor/validator.js).
- Allow users to toggle it on/off or customize it per project, making it adaptable to unique workflows.
Benefits
- Consistency: Enforces project-specific rules (e.g., package managers, coding conventions) without relying solely on Cursor’s internal rule engine.
- Flexibility: Script-based approach accommodates simple keyword checks or advanced LLM-driven validation.
- Context Retention: Helps the agent stay aligned with user intent, reducing off-topic responses.
- User Control: Empowers developers to tailor Cursor’s behavior to their exact needs.
Implementation Suggestions
- Expose a simple API for the validator script (e.g., validateCommand(command: string): { valid: boolean, message?: string, suggestion?: string }).
- For the enhanced version, provide a CursorContext object with properties like userRequest, currentFile, and an llmQuery() helper.
- Add a UI toggle in project settings to enable/disable or select the validator script.
Closing Thoughts
This feature would make Cursor more reliable and customizable, especially for projects with strict conventions or complex requirements. A simple pre-command validator would solve my immediate pain point with package managers, while the context-aware extension could unlock powerful ways to keep the agent focused and aligned with user goals. I’d love to hear your thoughts on feasibility or refinements!