I asked my agent to build pr-rulebook from an idea that came up in conversation. When I wrote about the result, I included the candidate rule that failed review. That failure explains something important: a repeated comment is a lead, not an automatic team policy.
Here is how I approach turning code-review feedback into useful context for Cursor.
Collect evidence, not just wording
Start with human comments on merged pull requests. Check what changed after each comment. Similar feedback across distinct PRs is stronger evidence than two replies in the same discussion.
A later commit is still only an acceptance signal. It does not prove that the comment caused the change or that everyone agrees with the rule.
Separate a convention from a local preference
A suggestion that fits one file can be wrong elsewhere. Keep links to the examples and the original discussion beside each proposed rule. Have someone on the team review the scope before adopting it.
Write a rule someone can act on
"Write high-quality code" gives an agent little to check.
An illustrative example is: "In new API routes, validate input before accessing the database, using the project's reference implementation."
That is an example of wording, not a rule from a client project. A useful rule says what to check, when it applies and where a correct example lives.
Store it where the tool reads it
Cursor's current documentation puts project rules in version-controlled .mdc files under .cursor/rules. Rules can apply to specific files, be selected by relevance, be invoked manually or apply to every session.
Cursor recommends focused, actionable rules under 500 lines, split by topic. That is a ceiling for guidance, not a target to fill. Refer to canonical examples instead of copying information that already lives in the code.
Start small and test the result
The documented pr-rulebook experiment scanned 15 merged PRs and 45 human inline review comments in Ruff. It produced two candidate rules. One held up to inspection; the other was too vague to enforce. Even the stronger candidate had two examples from a single PR, which limits the claim that it was a team-wide convention.
The current tool requires evidence across distinct PRs. The experiment remains a small example, not proof that the method improves every team's productivity.
Try a small set of reviewed rules on real code. Check whether they prevent a repeated mistake. Rules supply context; tests and human review still matter.
Sources
This is an English adaptation of my Hebrew guide. My professional background and selected work.
Top comments (0)