You type "add a settings page" into Cursor's Composer and get back a fully wired account-management modal: profile fields, a theme toggle, a data-export button, and a billing tab bolted onto a project that doesn't take payments yet. Cursor didn't misunderstand the request. It answered honestly. "Settings page" could mean almost anything, so it built the version it's seen most often: the kitchen-sink settings screen every SaaS app seems to have.
This is the pattern behind most "Cursor built the wrong thing" complaints. The request wasn't wrong, it was just underspecified, and Cursor filled every gap with its own defaults instead of yours. The fix isn't a magic prompt template. It's briefing Cursor the way you'd brief a contractor who's never seen your project: assume it knows nothing you haven't told it, because it doesn't.
Why "add a settings page" builds the wrong settings page
Cursor reads three things when it answers a prompt: your instructions, the code already in the repo, and whatever rules file you've set up. When your instructions are short, the other two sources have to make up the difference, and neither one knows what "settings" means for your specific app. A three-screen habit tracker and a twelve-tenant B2B tool might both have a page called "Settings," and they should contain almost nothing in common.
The gap gets worse in Cursor's agent mode, where it doesn't just suggest a diff, it plans and executes a sequence of changes on its own. A vague brief at the start means every downstream decision inherits the vagueness. By the time you notice the billing tab you never asked for, Cursor has already wired it into three other files.
What actually belongs in a brief (not your rules file)
It helps to separate two things that get blurred constantly: your .cursorrules (or AGENTS.md, the tool-agnostic version) and the brief for this specific ask. The difference between a rules file and a spec covers this split in more detail, but the short version is: the rules file says how you build, stays the same for months, and Cursor reads it automatically on every prompt. A brief is what you're building right now, and it changes every time you ask for something new.
The mistake is treating the rules file as a substitute for the brief, on the theory that Cursor "already knows the project." It knows your conventions. It doesn't know that this settings page needs exactly two fields and nothing else, because you haven't told it that, in this prompt.
The four things a good Cursor brief covers
A brief that actually prevents guesswork is short, shorter than a full PRD, but it borrows the same idea: decide before you describe. Four parts, in this order:
- What it's for. Not "a settings page," but "a place to change display name and notification preferences, nothing else yet."
- What's explicitly out of scope. "No billing here. No account deletion. No theme picker." This is the line that stops Cursor from reaching for the generic version.
- An edge case or two, if they matter. "If notifications are off, hide the frequency dropdown instead of disabling it." One real edge case saves a follow-up prompt.
- What "done" looks like. "Done when I can change my name, it persists on reload, and there's a save confirmation." Concrete and testable beats "done when it works."
None of this takes longer to write than the vague version. It just means typing four short lines instead of one, before Cursor starts filling in the rest for you.
Before and after: the same ask, two different builds
Vague: "add a settings page."
Briefed: "Add a settings page with two fields: display name and email notification toggle. No billing, no theme options, no account deletion, not yet. Persist changes on save, show a small confirmation toast. Done when both fields save and reload correctly."
The first version is technically a complete sentence. The second is the same request with the guessing removed. Feed Cursor the second version and it builds two fields and a toast. Feed it the first and you're reviewing a diff that touches Stripe types you haven't installed yet.
This isn't unique to UI work either. Take a request that touches data instead of a screen: "add a way to export a project's data." Vague, and Cursor will likely reach for the broadest reading, a full account export with every table, formats you don't need yet, and probably a background job you didn't ask for. Briefed: "Add a CSV export for a single project's items, triggered from a button on the project page, downloaded directly, no email delivery, no scheduling." Same underlying request. One version guesses at infrastructure, the other builds exactly the button you wanted.
This isn't unique to Cursor, either. Brief a non-code tool like Lovable or Bolt with "add a settings page" and you get the same kitchen-sink instinct, just rendered as a UI mockup instead of a diff. The tool matters less than whether you told it where the edges are.
When a brief is overkill
Not every prompt needs four bullet points. "Fix the typo in the header" doesn't need a scope statement, and writing one would be slower than just fixing it yourself. The four-part brief earns its keep on anything that touches more than one file, introduces new state, or could plausibly be interpreted three different ways. A good rule of thumb: if you can picture two reasonable but different things Cursor might build from your one-line request, you need the brief. If there's only one reasonable interpretation, skip it and just ask.
The skill isn't writing longer prompts by default. It's noticing, before you hit enter, whether this particular request has room to go sideways.
The takeaway
Briefing Cursor well isn't a skill you develop by writing more prompts and hoping the pattern-matching improves. It's a habit of writing four short lines before you hit enter: what it's for, what's out, an edge case if one matters, and what done looks like. Do that consistently and Cursor stops guessing at the kitchen-sink version of everything you ask for.
Writing that brief from scratch for every feature you touch is exactly the kind of small, repetitive thinking Draftlytic is built to take off your plate. Describe the feature once and it hands back the scope, the edge cases, and the "not this" list, already formatted as a Cursor-ready spec you can paste straight into Composer.