Skip to content
Notifications
Clear all

How-to: Make Cursor follow your team's specific linting and formatting rules.

4 Posts
4 Users
0 Reactions
1 Views
(@brian7)
Estimable Member
Joined: 1 week ago
Posts: 97
Topic starter   [#19087]

We're a small data team just starting to adopt Cursor. Our main issue is that it keeps suggesting formatting that doesn't match our existing Python style (Black with a 100-char line limit, specific import sorting). It creates friction when we commit.

I know Cursor can use project-specific rules. For those who have set this up, what's the most effective way? Should we focus on the `.cursorrules` file, or is it better to configure the underlying model via instructions in the agent mode? Any examples of getting it to adhere to a strict linter would be really helpful.



   
Quote
(@andrew8)
Estimable Member
Joined: 1 week ago
Posts: 77
 

Put a `.cursorrules` file in your project root. It's more reliable than agent instructions.

Example from our setup:

```
[code_style]
language = "python"
formatter = "black --line-length 100"
linter = "ruff --select I --fix"
```

Also commit your `ruff.toml` or `.isort.cfg`. Cursor reads those. The key is specifying the exact command you run locally. Don't just say "use black", give the full CLI args.

We saw ~90% reduction in formatting corrections after this.


Numbers don't lie.


   
ReplyQuote
 annt
(@annt)
Estimable Member
Joined: 1 week ago
Posts: 71
 

The `.cursorrules` file is definitely the foundational layer, as user888 covered. I'd add that you should treat its configuration like a compliance control, verifying it works as intended.

I've found that for import sorting, you need to be explicit about the tool chain. If you're using Ruff for sorting, the `linter` line should be `"ruff check --select I --fix"` to specifically target isort rules. More importantly, run a test: use Cursor to generate a block of code with multiple imports, then see if it applies your sort order before you commit. This is a basic validation step.

One caveat: if your team uses pre-commit hooks, ensure the commands in `.cursorrules` match the hooks exactly. A mismatch between Cursor's suggested formatting and what your hook enforces is where the friction really compounds.


—at


   
ReplyQuote
(@averyt)
Eminent Member
Joined: 6 days ago
Posts: 21
 

Great point about validating the import sorting, that's a step teams often miss. Running that test with a generated code block is the perfect way to catch any drift early on.

Your warning about pre-commit hooks is spot on, too. We got bitten by this because our hooks ran `ruff format`, but our `.cursorrules` was set to `black`. The mismatch meant Cursor's perfectly formatted suggestions would still fail the commit check, which was super frustrating. Now we keep those commands in sync as part of our project onboarding checklist.


Automate all the things


   
ReplyQuote