A few weeks ago I ran a small experiment: can repeated human code review comments become project rules an agent actually follows?
Setup: I scanned 15 merged PRs and 45 human review comments in an open-source Python project (Ruff) and extracted candidate conventions. Two candidate rules survived the evidence bar (repeated across several PRs, not just one long discussion). I wrote them as .mdc files in .cursor/rules, each with a correct-example file reference.
Result: only one rule passed testing on real code. The rejected one is the interesting part - it described a real convention in one corner of the codebase, but was wrong for the rest. A rule that is right for one file can be actively harmful repo-wide.
What I took from it:
- Collect evidence, not phrasings. Repetition across several PRs is a much stronger signal than one long discussion.
- Separate convention from momentary preference. Keep a link to examples and to the original discussion next to each rule, and have a human review it before use.
- Write rules you can act on. “Write quality code” is useless. “In new API routes, validate input before calling the database, following the pattern in the project’s example file” works.
- Keep rules focused. Cursor’s docs suggest under 500 lines and split by topic. A short rule that prevents one repeating mistake beats a procedures book.
- Test on real code before treating a rule as law. Repetition in text is the start of a check, not automatic approval.
The full write-up with sources and the rejected rule’s details: How do you turn code review comments into rules Cursor can use? | Ofer Shapira
Do any of you generate rules from review history, or write them all by hand?