Cursor Rules Builder: Turn Project Standards Into Useful Rules

A Cursor rule is only as useful as the standard it comes from. Rules copied from a template or generated from a list of best practices often end up vague, outdated, or irrelevant to the actual codebase. The most reliable way to write a rule is to start with a real problem: a mistake the assistant keeps making, a decision your team keeps having to re-explain, or a convention that does not show up in the code itself. fenbs holds the decisions and lessons your team has already recorded, which are the best source material for writing rules that are genuinely specific to your project.

Building a useful Cursor rule is a four-step loop: extract the standard from real project context, write a short and specific instruction, test it on actual files, and refine until the behavior matches the intent. The goal is a rule that the assistant follows consistently, not a comprehensive style guide.

Step 1: Find the rule worth writing

Start by asking which convention the assistant violates most often. Run through recent code reviews and look for comments that corrected the same issue more than once. A pattern of corrections is a rule waiting to be written. The standard does not have to be complicated — "use the project's Result type for service errors, not exceptions" is a complete and useful rule.

A second source is onboarding friction. What does every new developer have to be told that is not visible from the code? The answer to that question is a rule your existing documentation has not captured in a place where the assistant can read it.

• Repeated code review comments on the same pattern.
• Assumptions a new developer gets wrong in the first week.
• Architecture decisions that are not visible from the folder structure.
• Commands or tools the assistant must not use in this project.
• Third-party libraries the project uses differently from the standard examples.

Step 2: Write the rule clearly and specifically

A useful rule is a short, specific instruction that changes behavior in a predictable direction. "Write clean code" does not. "Use ApiError from lib/errors.ts for all error responses from service functions — do not throw directly" does. Each rule should have one clear subject, one clear instruction, and enough context that the assistant can apply it without guessing.

Three tests for a well-written rule: Would a new developer find it accurate? Would violating it cause a real problem, or is it just style preference? Is the instruction specific enough to act on, or does it need a decision first? If it needs a decision, record the decision in fenbs and come back to write the rule after the team has agreed.

# Vague — gives the assistant nothing useful
Handle errors properly.

# Specific — gives the assistant a clear instruction
All service functions return Result<T> from lib/errors.ts.
Do not throw from service functions.
Controllers map Results to HTTP status codes via ResultMapper in api/mappers.ts.

Step 3: Test the rule on real files

Add the rule to a test rule file and open a file in Cursor where you want the rule to apply. Ask the assistant to complete a task it normally does in that file — adding a new function, handling a new error case, writing a test. Check whether the rule changed its output in the right direction.

If the assistant ignores the rule, the instruction may be too vague or too general for the context. If it follows the rule but produces wrong code, the rule may be incomplete — it said what to use but not when or how. Iterate on the language until the rule reliably produces the intended change.

Step 4: Review with the team before committing

A rule that turns out to be wrong is worse than no rule, because it teaches every assistant the wrong convention. Before committing a rule to version control, ask one or two teammates to check it against the actual codebase. Does it describe how things really work? Are there exceptions the rule does not account for?

If there are legitimate exceptions, write the exception into the rule explicitly: "Use the async flag for all API calls except the health check endpoint, which uses a synchronous check." An unwritten exception that the assistant cannot see becomes a bug in its output.

How to do this with fenbs

1. Create a free account and add a project for the codebase you are writing rules for.
2. Add the decisions and lessons your team has already recorded in fenbs — these are your source material. Each decision that ends with "always" or "never" is a candidate for a Cursor rule.
3. Draft a rule for each candidate and add it as a skill or prompt in fenbs, alongside the decision it came from. Keep them paired so the reasoning is always visible next to the instruction.
4. When a rule turns out to be wrong, record the lesson in fenbs: what the rule said, what actually happened, and what the correct approach is. That lesson prevents the same wrong rule from being written again.
5. Connect your AI tools from Integrations so they read both the rules and the decisions before starting work.

How many rules is too many

A short set of accurate rules is more useful than a large set with outdated or vague ones. Every rule you add increases the length of the context the assistant reads at the start of a session. Past a certain length, earlier rules get less attention or are forgotten by the time the relevant code is reached. Aim for rules that prevent real mistakes, and let style preferences live in your linter config instead.

Review your rule set when you onboard a new developer or after a major framework upgrade. If a rule is no longer accurate, update it immediately — a wrong rule actively harms every session until it is fixed. The cursor rules library shows how to organize rules into a shared, maintainable library across projects.