Cursor Prompts: 10 Agent Briefs With the Rules File Each One Needs

Which growth channels do these prompts serve?

Every prompt in this category carries a distribution section naming the channel it is built for, so the generated app has a way of being found rather than only a feature set. The chart counts primary and secondary coverage together, computed from the prompt bodies when the site is built.

What is a Cursor prompt, and how is it different from a Lovable or Claude Code prompt?

All three describe a feature; they differ in where the standing context lives and how the result is checked. In Lovable, the context is project knowledge and you test in the preview. In Claude Code, it is CLAUDE.md and the agent runs the check you name. In Cursor, the context is a rules folder with three attachment modes, the docs' names being Always Apply, Apply Intelligently, Apply to Specific Files and Apply Manually (rules documentation, read the same day), and the check runs in the integrated terminal while you watch the diff. Cursor adds one safety rail the others express differently: "Checkpoints save snapshots of your codebase during an Agent session. Agent automatically creates them before making significant changes."

So a Cursor brief in this library keeps the skeleton and changes three things. Context references files with @ rather than describing them, because that is how Cursor attaches them. Repository Rules point at the .mdc file that already holds the constraint, so the brief repeats only what is specific to its job. And Safe-Guard asks for a checkpoint before the first migration or the first rewrite of an existing file, because a checkpoint is the cheapest undo the editor has and Agent will not always judge a change significant the way you would.

How is a Cursor brief in this library built?

The auth brief is the one to read, because it is the foundation the others assume and because it shows all three changes at once. Its Context line references the database rule and the migrations folder with @, so the constraint attaches before the agent reads anything else. Its Safe-Guard opens with a checkpoint. Its Verification is the same two queries as the Claude Code version, one as the owner expecting rows and one as a second user expecting none, plus four tests, and it asks for the output pasted rather than summarised.

The rule the brief depends on is the second file the bootstrap brief writes: a database rule with globs for migrations and server functions, which the Cursor rules guide on this site prints in full alongside the other two. That guide also measured 498 public rule files and found 82% of the community-written ones attached to every file with a wildcard glob; the three-file split here is the alternative, and each brief names which of the three it needs.

What do the rules these briefs depend on look like, and what do public ones get wrong?

The bootstrap brief writes three files because Cursor's docs offer three ways to attach one, and most public rules use only the first. On 26 September 2026 we measured the two most-starred public collections: 257 community-written rules with a median of 69 lines, 212 of them (82%) set to attach to every file; and 241 LLM-generated rules with a median of 307 lines, 6 over the docs' 500-line guidance. Only one file in 498 used alwaysApply honestly, and four referenced another file with @ instead of pasting it. The Cursor rules guide has the charts and the measurement script.

The briefs here are written against that finding. The project rule is short and always on; the database rule attaches only when a migration or server function is open; the marketing rule attaches when the agent decides a public page is in play. A brief for a landing page therefore carries the no-invented-proof rule without repeating it, and a brief for analytics does not carry the marketing rule at all. Cursor's docs put the principle in one line, "Keep rules focused on patterns you use frequently", and the one everyone breaks in another: "Reference files instead of copying their contents."

What happens after the brief: review, cloud and the other editor?

Two things Cursor's paid plans add, per its pricing docs on 26 September 2026, which say Pro, Pro Plus and Ultra include "access to Bugbot, and access to Cloud Agents": a review of the pull request that did not write it, and a run that does not need your laptop open. The briefs are written so both fit: every one ends with a checkable Verification, which is what a reviewer reads, and none depends on watching the editor, which is what a cloud run lacks. The Cursor CLI adds the third path, "print mode for non-interactive scenarios like scripts, CI pipelines, or automation".

If the repository is also opened in Claude Code, the bootstrap brief's AGENTS.md is the file both read; the Cursor vs Claude Code page covers what each does that the other does not, and the Claude Code prompts category has the same ten jobs written for that side, with CLAUDE.md where these have rules.

Which Cursor brief to use

If the repository has no .cursor/rules folder, start with the Rules Bootstrap, and if it is a Lovable export, run the Handover brief right after. Every other brief names one of the three rule files the bootstrap writes.

If the app has teams, Auth, Roles and RLS, then the Invite Loop. If it has content people search for, the Programmatic Public Pages brief, then the Changelog. If traffic is about to be sent, the Landing Page and the Event Taxonomy, in that order.

Lifecycle Email and B2B Signals come last; both read tables the earlier briefs create.

Suggested build order

Rules first, then the foundation with its proof queries, then the events, then the surfaces, then the loops that read them. Running a growth brief before the taxonomy exists means events get invented per chat, which the typed helper in the analytics brief exists to prevent.

1. 1

   Write the three rules and the verify script

   Every later brief names one of them.

   Prompt: Cursor Rules Bootstrap

2. 2

   Build the foundation with proof

   Checkpoint, migration, policies, two queries.

   Prompt: Auth, Roles and RLS in Cursor with Proof Queries

3. 3

   Define the events once

   A typed list the typecheck enforces.

   Prompt: Event Taxonomy and Funnel Page in Cursor

4. 4

   Then the surfaces

   Public pages with the SSR and link gates; the landing page follows the same rules.

   Prompt: Programmatic Public Pages in Cursor

5. 5

   Then the loops

   Invites, email and signals read the tables the earlier briefs created.

   Prompt: Invite Loop with Attribution in Cursor

Where Cursor briefs usually go wrong

• One always-on rule that carries everything. It rides on every chat, the agent stops reading it, and the constraint that mattered is lost in it. The bootstrap brief splits by attachment mode for that reason.
• Pasting a file into the brief. Cursor attaches files with @ and the docs say to reference rather than copy; a pasted schema drifts the moment the migration runs.
• No checkpoint before the hard change. Agent creates them before changes it judges significant; a migration it judges routine is the one you wanted the snapshot for. The briefs ask for one by name.
• Reporting done without the check. A brief that ends at Build Order gets a diff that looks complete. The Verification section asks for the terminal output pasted, so the reviewer, Bugbot or a person, reads a result instead of a claim.

Frequently asked

Sources

All checked on 26 September 2026.

• Cursor docs: Agent
• Cursor docs: Rules
• Cursor docs: CLI
• Cursor docs: Pricing
• GitHub: PatrickJS/awesome-cursorrules (measured)
• GitHub: sanjeed5/awesome-cursor-rules-mdc (measured)