Cursor Rules for a PRD: Keep Requirements in Context

Cursor rules for a PRD tell the assistant where the product requirements document lives and what to check before changing behavior the PRD defines. They do not copy the document into the rule file, which would create two versions and an eventual disagreement.

The PRD says what the product should do. The decisions about what was accepted, changed, or postponed live somewhere else. fenbs keeps those decisions alongside the tasks that implement them, so the assistant reads the current approved state rather than guessing from an old document.

Why not paste the PRD into the rule file

A PRD changes over the life of a product. Requirements are approved, scoped down, postponed, or replaced. If you copy the document into a rule file, every change now has to happen in two places. The rule and the source quickly disagree, and the assistant chooses based on whichever text is in front of it.

A reference is better: a short sentence that names the document and tells the assistant when to read it. "Before changing the checkout flow, read docs/requirements/checkout.md and confirm the behavior you are about to change is still current." The document does the explaining; the rule just points to it.

The same logic applies when the PRD is in a tool like Confluence, Notion, or a shared drive. The rule names the location and the reading condition. See cursor rules for AI projects for how to structure those references alongside other project rules.

What the rule file should contain

The rule answers three questions for the assistant: which document is authoritative, when to read it, and what to do if it conflicts with an instruction in the current session. Those three answers fit in a short file and do not go stale when requirements change.

---
description: Product requirements document reference
globs: "src/**/*.ts,src/**/*.tsx,src/**/*.py"
alwaysApply: false
---

## Product requirements
- The authoritative PRD is `docs/requirements/product.md`.
- Before changing behavior in a user-facing flow, read the relevant PRD section.
- If a session instruction conflicts with the PRD, ask the developer to confirm
  which takes priority before proceeding.
- Accepted decisions and scope changes are in the project's Decisions and rules
  in fenbs — read those before planning work that affects a defined requirement.

## Scope
- Do not add a feature that is not in the PRD or in an accepted task.
- Mark any requirement you cannot find a current source for as needing
  confirmation before the task is done.

Accepted decisions versus open requirements

A PRD usually describes the intended state. What actually got accepted during a sprint, what was scoped down in a call, and what the product manager approved last week are not in the document. They are in meeting notes, Slack messages, or someone's memory. An assistant working only from the PRD misses all of that.

Recording those acceptances as decisions is more useful than hoping the PRD gets updated in time. When the team agrees to ship a simpler version of a feature, that agreement is a decision with a date and a reason. The next assistant reads it before planning the work and does not re-propose the fuller version.

The rule can point to where those decisions live. A short line in the rule file, like the example above, tells the assistant to check Decisions and rules in fenbs before starting work that touches a defined requirement. That makes the reference actionable rather than aspirational.

Keeping tasks aligned with the requirements

A PRD describes features. Tasks describe the specific pieces of work. When requirements change, both the PRD and the related tasks should reflect it. Without that connection, the assistant can finish a task correctly while building something the product team has moved on from.

Linking tasks to the decisions that shape them makes this visible. If the payment flow changes from two steps to one, a decision records that change. The related tasks then reflect the current scope. The next assistant reads the accepted state, not the original plan.

For the difference between a requirements document and a brief, see BRD vs PRD. For working with Cursor from the terminal, see Cursor CLI. Neighbors that cover rule organization: cursor rules hierarchy and cursor rules library.

How to reference a PRD with fenbs

1. Create a free account and add your product as a project in fenbs.
2. Add the key acceptance decisions that are not yet in the PRD: scope reductions, postponed features, approved alternatives. Record each with the person who decided and the reason.
3. Add tasks for the current sprint features, with the relevant PRD section named in each task's plan.
4. Place the .cursor/rules/prd.mdc file at your repo root and adjust the glob to match your source folders.
5. Connect Cursor via Integrations and ask it to read the project context before working on any requirement-bound feature.

The rule file does not need updating every time the PRD changes. The document handles its own content. The rule simply tells the assistant that the document exists, when to read it, and where the accepted exceptions live. That separation keeps the rule stable even as the product evolves.

The rule also helps when a new assistant joins mid-project. Without it, the assistant reads whatever files are open and infers requirements from the code. That inference is often wrong. A rule that says "read the PRD and the Decisions in fenbs before planning any new feature" tells the assistant where to look and makes the context explicit rather than guesswork.

A rule that works well at the start of a project becomes more valuable as the project grows. When the PRD covers ten features and six months of decisions, the rule is what keeps the assistant from treating old sections as current scope and from treating current scope as optional. The rule does not need to know the product; it needs to tell the assistant where the product definition lives and to read it before acting.