Cursor Rules and Hooks: Instructions vs. Executed Checks
Cursor rules tell the assistant what to do; hooks execute verification commands automatically. This guide explains the difference, where each one fits, and how fenbs holds the approved workflow decisions both should reflect.
Updated 5 min read
Cursor rules are instructions in text: they tell the assistant what approach to take, which commands to run, and when to stop and ask. Cursor hooks are configured commands that execute automatically at specific points in a session, such as after a file is saved or after the assistant finishes a task. Both influence what the assistant does; they work in fundamentally different ways.
fenbs holds the workflow decisions that both should reflect: which checks a person approved as mandatory, which commands are the standard verification, and whether a check belongs in a rule or in a hook. The rule and the hook implement the decision; fenbs keeps the record of why it was made.
What rules do
A rule is a text instruction in a .mdc file. The assistant reads it as part of the context for a session. If the rule says "run npm test before marking a task done", the assistant follows that instruction — unless it decides not to, or the rule is not applied to the session, or the instruction is ambiguous.
Rules guide behavior through language. They are flexible and easy to write. They can explain reasons, list patterns, and give examples. Their limitation is that they rely on the assistant choosing to follow them. A rule is not a technical barrier; it is an instruction. That distinction matters when the cost of non-compliance is high.
What hooks do
Cursor hooks are configured in settings and execute shell commands at specific lifecycle events. As of October 2026, Cursor supports hooks that run after certain events. A hook runs a command mechanically, not by asking the assistant. If the hook runs npm test, the test runs regardless of whether the assistant was instructed to run it.
Hooks provide enforcement where rules provide guidance. A test hook catches failures that slip past an assistant that was confident. A formatting hook keeps code consistent without requiring the assistant to remember. Check Cursor's settings documentation (opens in a new tab) for the current hook configuration options and supported lifecycle events.
Where each one fits
The simplest split: use rules for style and approach decisions that benefit from explanation, and use hooks for mechanical verification steps that should run without exception. A rule that says "prefer getByRole over CSS selectors" benefits from being an instruction the assistant can weigh against the current situation. A hook that runs tsc --noEmit after every save catches type errors without needing the assistant to decide.
| When to use a rule | When to use a hook |
|---|---|
| The check requires judgment or context | The check should run mechanically every time |
| You want the assistant to explain its reasoning | The command output is the entire result |
| The pattern varies by file type or situation | The same command applies to every change |
| You want the assistant to stop and ask on failure | You want the build to fail immediately |
Using both together
The strongest setup uses both. The rule describes the style and guides the approach. The hook catches the mistakes that slip through. A TypeScript rule that says "run tsc --noEmit before marking a task done" is useful. A hook that runs the same check after every file save catches the errors earlier and removes a step the assistant might forget.
When a hook fails, the assistant sees the error output and can respond. The failure is a fact from the environment, not an instruction from the rule. That distinction matters: the assistant can address a hook failure using its judgment, but it follows a rule instruction because the instruction said to.
One practical heuristic: if the check has no judgment component — it either passes or it does not — it belongs in a hook. If the check requires the assistant to interpret the result and decide what to do next, it belongs in a rule. Most projects have both kinds, and the combination is stronger than either alone.
For a growing project, the right split tends to evolve. A check that starts as a rule instruction — "remember to run the linter before finishing" — may graduate to a hook once the team agrees it should never be skipped. Documenting when and why a check moved from rule to hook keeps the workflow legible for the next person who configures the project from scratch.
Record which checks are mandatory and which are guidance
When your team decides that a specific check must always run, record that as a Decision in fenbs: which check it is, whether it belongs in a rule or a hook, and why it is mandatory. The assistant reads those decisions before configuring a workflow for a new project. A check that looks optional to someone reading the codebase for the first time is clarified by its decision record. fenbs does not configure hooks; it keeps the workflow decisions that inform how they are set up.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to set up rules and hooks with fenbs
- Create a free account and add your project.
- List the checks that are mandatory for your workflow. Decide which belong in a rule (require judgment) and which belong in a hook (should run mechanically).
- Record those decisions in fenbs: the check, where it belongs, and the reason.
- Write the rule file for judgment-based checks. Configure the hook in Cursor settings for mechanical ones.
- Connect Cursor via Integrations and ask it to read the project context before setting up a new workflow.
For the rule patterns themselves, see cursor rules examples and cursor rules for AI projects. For how rules are activated by file pattern, see cursor rules globs. For organizing multiple rule files, see cursor rules hierarchy and cursor rules library.