Cursor Rules vs Commands: What Runs When
Cursor rules set standing instructions that apply to every session; commands are procedures you invoke for a specific task. Understanding the difference helps you put each kind of instruction in the right place and keep both effective. fenbs stores the reusable procedures and decisions both rely on.
Updated 7 min read
Cursor rules are standing instructions that load automatically and apply throughout a session. Commands (also called slash commands or composer commands) are procedures you invoke for a specific task — refactoring a function, running a check, or generating a boilerplate file. Both influence what the assistant does, but they work differently and belong in different places. Getting the distinction right keeps your rules focused and your commands useful. fenbs stores the reusable procedures and the team decisions that both kinds of instructions refer to, so they are available to every connected assistant.
A useful rule of thumb: if an instruction should apply all the time, it belongs in a rule. If an instruction is only relevant when you are doing a specific task, it belongs in a command. Mixing them — putting task-specific instructions in rules, or trying to use a rule to trigger an action — leads to rules that are too long and commands that duplicate standing instructions.
What Cursor rules do
A rule is a file in .cursor/rules/ that loads automatically when you open a matching file or start a session. It contains standing instructions: the naming conventions for this project, which error type to use, which imports are approved, how tests should be structured. The assistant reads these at the start and applies them throughout the session without you having to repeat them.
Rules are passive. They set the context. They do not trigger actions, run commands, or respond to specific requests. A rule that says "run tests before committing" is an instruction the assistant can remind you about, but it does not run the tests. Rules work best as persistent reminders for decisions that should always be in effect.
What Cursor commands do
A command is a reusable prompt template or procedure that you invoke on demand. It might say "add a unit test for the selected function", "refactor this file to use the async pattern", or "generate a migration for this schema change". Commands are active — you invoke them for a specific task, they run once, and they produce a result.
Commands are useful for multi-step procedures that happen often enough to save time but not often enough to belong in standing rules. A command for "add a new API endpoint following the project's controller pattern" runs when needed and guides the assistant through the specific steps, without those steps cluttering the always-on rule context.
How they work together
| Rules | Commands | |
|---|---|---|
| When it runs | Automatically, for matching files or all files | When you invoke it explicitly |
| What it contains | Standing instructions: conventions, constraints, approved patterns | Step-by-step procedures for a specific task |
| Best for | Decisions that should always be in effect | Tasks that happen often enough to be worth scripting |
| Changes over time | When a convention changes | When the procedure needs updating |
| Length | Short (5–20 lines per rule file) | Can be longer — it only loads when invoked |
A rule and a command can refer to the same convention from different directions. A rule might say "use the Result type for service errors". A command for "add a new service function" might include steps that explicitly follow the Result type pattern. The rule ensures every session knows the convention; the command makes it easy to apply correctly for new code.
When instructions belong in rules
Use a rule when the instruction must be in effect throughout the session and applies to all work in the relevant files. Good candidates: naming conventions, dependency direction, approved imports, test file location, build command, and architecture constraints. These are things that should be true every time the assistant touches the codebase.
- Architectural constraints: "services may not import from the data layer directly".
- Naming conventions: "React components must be named in PascalCase and have a corresponding .test.tsx file".
- Approved and banned patterns: "do not use any, always type explicitly".
- Test commands: "run npm test before saying a change is complete".
- Safety rules: "do not log sensitive fields; use the sanitize helper from lib/log.ts".
When instructions belong in commands
Use a command when the instruction is specific to one kind of task and would add noise if it were always active. Commands are also better for procedures that have multiple steps, because a standing rule that lists five sequential steps for a specific workflow will be read at the start of every session, whether or not that workflow is relevant.
- Boilerplate generation: "add a new API endpoint for the given resource, including controller, service, and test".
- Refactoring procedures: "migrate this class from the old error pattern to the new Result type, following the project checklist".
- Review checklists: "check this function against the team's security review list".
- One-off fixes: "update this file from the deprecated API to the current one".
Store commands and their source decisions together
In fenbs Skills and prompts, you can save both standing rules and reusable command templates, alongside the decisions they came from. When someone updates the project's error handling approach, they update the rule and the related command in fenbs at the same time. Every connected assistant reads both from the same current source, without anyone having to update two separate files in each project repo.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Common mistakes when mixing rules and commands
The most common mistake is putting task-specific procedures in a rule. A standing rule that walks through seven steps for adding a new API endpoint loads at the start of every session, whether or not you are adding an endpoint. It makes the rules context longer and can distract the assistant from the current task. Move that procedure to a command.
The second common mistake is writing commands that duplicate standing rules. If a rule already says "use the Result type for service errors", a command for adding a service function does not need to repeat that instruction at length — it can say "follow the project's error handling convention" and rely on the rule already being active.
How to do this with fenbs
- Create a free account and add a project for the codebase you are organizing rules and commands for.
- Add each approved standing rule as a skill or prompt in fenbs with a note that it is a rule (always-on). Add each reusable command separately with a note that it is a command (invoked on demand).
- Record the team's decisions about the boundary between rules and commands in Decisions and rules: for example, "architectural constraints and naming conventions go in rules; procedural workflows go in commands".
- When a new convention is added, decide together whether it belongs in a rule or a command before writing it. Record the decision in fenbs.
- Connect your AI tools from Integrations so they read the current rules and have access to the shared command library at the start of each session.
When neither a rule nor a command is the right answer
Some project knowledge does not fit in a rule or a command at all. The context of a current task — what was tried, what was approved, where the work currently stands — changes too quickly and is too specific to belong in a standing rule. That context belongs in your task and project notes. See cursor rules for AI projects for how to keep task context separate from coding conventions.