Cursor prompts — build rules and tasks that stay in scope

# Cursor task

## Rules
- Make the smallest change that satisfies the task. Do not refactor unrelated code.
- Prefer explicit TypeScript types; avoid `any`. Keep public APIs typed.
- Match existing project style, naming, and file organization. No drive-by renames.

## Context
Stack: Next.js + React + TypeScript
Kind: feature implementation
Relevant files / areas: [attach or @-mention in Cursor]

## Task
[describe the change you want]

## Acceptance criteria
- Behavior matches the task description
- No unrelated files changed
- Project still typechecks / builds

## Output
- Implement the change (or propose a short plan if blocked).
- Summarize what you changed and how to verify.

No sign-up, nothing sent to your repo — the prompt assembles locally.

Why unstructured Cursor prompts create messy diffs

Coding agents optimize for helpfulness. Without guardrails, helpfulness looks like renaming variables for style, “improving” adjacent files, and expanding scope until the diff is a product redesign. That is not malice; it is missing constraints. Your job is to make the desired behavior the only reasonable behavior. The free Cursor prompts builder on this page exists because most failed agent sessions are brief failures, not model failures.

Engineers already know how to write tickets. A good Cursor prompt is a ticket the agent can execute: context links, scope boundaries, definition of done. If you would not accept a human PR titled “stuff,” do not send an agent a prompt titled “fix it.” The standards you already use in code review are the standards that make Composer behave.

Structure also makes failure diagnosable. When a structured task goes wrong, you can point at the missing rule or the weak acceptance bullet. When a vibes prompt goes wrong, you only know that “it didn’t work,” which teaches nothing and invites another random retry. Prompt engineering for agents is closer to writing runbooks than writing poetry.

Three ingredients do most of the work. Rules set standing laws (minimal diffs, no new dependencies). Context points at the files that matter so the model is not guessing architecture from filenames alone. Acceptance criteria define done in testable bullets so “looks good” is not the exit condition.

Compare “Add dark mode” with a prompt that lists the theme provider file, forbids new dependencies, requires keyboard-visible focus states, and defines acceptance as system preference plus manual toggle with persistence. Same feature request — wildly different blast radius.

Cursor prompts are still prompts: clarity beats cleverness. You do not need secret agent slang. You need the same discipline you would use writing a ticket for a human engineer who is fast, capable, and slightly too eager.

Anatomy of a Cursor-ready prompt

You can free-write this structure, but most people forget a section under pressure. The builder’s job is to make omission harder than inclusion. Skim the emitted markdown before you paste: if acceptance is still the default placeholders, you are not ready to run the agent. Fill the bullets until a skeptical teammate would know how to QA the result without asking you.

Rules — the laws of the land

Rules are cheaper than cleanup. Minimal diffs, match style, strict types, accessibility, no new deps — each rule deletes an entire class of unwanted PR. Put stable rules in project rule files; repeat the critical ones in the task when the stakes are high. When a rule and a task conflict, the task should win only if you say so explicitly — silent conflicts create thrash.

Context — stack and files

Name the stack so the model does not invent a different router or state library. List paths, then @-mention them in Cursor so the text and the attachments agree. If the model cannot see the file, it will hallucinate its contents.

Task — one job

One prompt, one job. “Fix the bug and also redesign the settings page and add analytics” is three prompts wearing a trench coat. Split work; keep diffs reviewable.

Acceptance — done means testable

Write bullets a skeptical reviewer could verify. Include negative space: what must not change. Include verification: commands to run, paths to click, edge cases to hit.

How to use this Cursor prompts builder

After you paste into Cursor, watch the first tool calls. If it opens unrelated files, stop and tighten context. If it plans a rewrite, restate minimal-diff rules. Steering early is cheaper than reverting late.

Five Cursor prompt recipes to copy

These are full structured prompts. Copy one, swap paths and task text, keep the scaffolding.

# Cursor task

## Rules
- Make the smallest change that satisfies the task. Do not refactor unrelated code.
- Prefer explicit TypeScript types; avoid `any`. Keep public APIs typed.
- Match existing project style, naming, and file organization. No drive-by renames.
- Do not add new dependencies unless absolutely required and justified.
- Do not change payment provider SDK version.

## Context
Stack: Next.js + React + TypeScript
Kind: bug fix
Relevant files / areas:
- src/app/api/checkout/route.ts
- src/lib/payments.ts
- src/components/CheckoutForm.tsx

## Task
Fix double-charge risk when the user double-clicks Pay. Ensure the checkout endpoint is idempotent for the same cart session and disable the button while the request is in flight.

## Acceptance criteria
- Second concurrent click does not create a second charge
- Button shows loading and is disabled during submit
- Existing success and error paths still work
- Add a short comment or test documenting the idempotency key

## Output
- Implement the change (or propose a short plan if blocked).
- Summarize what you changed and how to verify.

# Cursor task

## Rules
- Make the smallest change that satisfies the task. Do not refactor unrelated code.
- Preserve accessibility: labels, focus order, keyboard paths, ARIA only when needed.
- Match existing project style, naming, and file organization.

## Context
Stack: Next.js + React + TypeScript
Kind: feature implementation
Relevant files / areas:
- src/components/SettingsForm.tsx
- src/app/settings/page.tsx

## Task
Add a notification preferences section with email/push toggles and a Save button that persists via the existing settings API helper.

## Acceptance criteria
- Toggles are labeled and keyboard accessible
- Save disabled while request in flight
- Error banner on failure with retry
- Mobile layout does not overflow

## Output
- Implement the change.
- Summarize what you changed and how to verify.

# Cursor task

## Rules
- Make the smallest change that satisfies the task. Do not refactor unrelated code.
- Do not add new dependencies unless absolutely required and justified.

## Context
Stack: Node.js service / API
Kind: code explanation / plan first
Relevant files / areas:
- src/db/schema.ts
- src/jobs/reindex.ts

## Task
We need to backfill a new indexed column on users. Explain current write paths and propose a zero-downtime plan before any code changes.

## Acceptance criteria
- List files that write to users
- Propose migrate → dual-write → backfill → switch order
- Call out lock/risk points
- No code changes in this pass

## Output
- Propose a short plan only.
- Summarize risks and verification steps.

# Cursor task

## Rules
- Make the smallest change that satisfies the task. Do not refactor unrelated code.
- Add or update unit tests for the changed behavior when practical.

## Context
Stack: Next.js + React + TypeScript
Kind: tests only
Relevant files / areas:
- src/lib/pricing.ts
- src/lib/pricing.test.ts

## Task
Add unit tests for edge cases in calculateDiscount: zero items, 100% coupon, stacking prohibition.

## Acceptance criteria
- Tests cover the three edge cases
- No production code changes unless a clear bug is proven
- Tests follow existing test style

## Output
- Implement tests.
- Summarize cases covered.

# Cursor task

## Rules
- Match existing project style, naming, and file organization.
- Prefer explicit TypeScript types; avoid `any`.

## Context
Stack: existing project conventions
Kind: code review feedback
Relevant files / areas:
- src/features/billing/*

## Task
Review the billing PR diff for correctness, security, and missing tests. Do not implement fixes unless a one-line issue is trivial; prefer a structured review.

## Acceptance criteria
- Group findings by severity
- Cite file paths
- Note missing tests
- Call out any secret or PII risks

## Output
- Structured review only.
- Summarize top three risks.

Cursor prompts vs generic coding chat

Building UI from a blank slate? Try the v0 prompts builder. For general prompt craft, see AI prompts and the coding & development world.

Standing rules vs per-task prompts

Standing rules should be short, non-controversial, and truly standing: style match, security basics, test expectations. Per-task prompts should carry the unique scope: which bug, which files, which acceptance bullets. If you paste a 200-line manifesto into every chat, the model will deprioritize the task. If you rely only on standing rules, one-off constraints disappear.

A practical split: project rules hold the team constitution; the builder on this page drafts the work order. When a work order keeps repeating the same extra constraint, promote that line into standing rules and delete it from templates.

Never put secrets, production connection strings, or customer PII into prompts you might publish or fork. Describe the shape of data; do not paste the data. Cursor runs against your machine context — treat prompts you share publicly as documentation, not dumps.

When Cursor goes off the rails

Team habits that compound

Save winning Cursor prompts next to tickets or in PromptFork so the next engineer does not rediscover the same brief. Standardize acceptance language for common chores: migrations, feature flags, accessibility passes, API idempotency. The builder is a drafting table; the library is institutional memory. A team that cannot find last month’s good agent brief will pay the tuition again.

Pair the library with lightweight rituals: paste the structured prompt into the PR description, link the fork, and note where the agent struggled. That feedback loop improves the template. Without it, prompts fossilize into cargo cult markdown nobody trusts.

Junior engineers benefit especially from recipes that encode senior judgment — minimal diffs, tests-only scopes, plan-first migrations. The agent is not a replacement for mentorship; a good Cursor prompt is a mentor that scales to 2 a.m. incidents without losing patience or context discipline.

Review agent diffs like junior-engineer diffs: trust but verify, especially around auth, payments, and migrations. A structured prompt reduces risk; it does not remove responsibility. Use Supercharge → Studio when you want help tightening a messy ticket into this structure.

Browse Explore and Top for community prompts, and Platforms for model hubs when the agent is not Cursor-specific.

Worked examples: good vs weak Cursor asks

Weak: “Clean up the auth code.” The agent may rewrite modules you did not open, invent abstractions, and ship a stylish mess. Strong: name the files, state the bug or smell (duplicate session refresh), forbid new dependencies, require tests for the refresh path, and define acceptance as “single refresh in flight, 401 retry once, types pass.” Same domain, different professionalism.

Weak: “Make it faster.” Faster how? Strong: “Profile the `/api/search` handler; if N+1 queries exist against `Prompt`, batch them; do not change the response schema; add a before/after note in the summary.” Performance work without a metric or a boundary becomes random micro-optimizations.

Weak: “Add tests.” Strong: “Add unit tests only for `calculateDiscount` edge cases listed below; do not refactor production code unless a test proves a bug; follow existing vitest style.” Tests-only prompts should say tests-only or you will receive a rewrite with tests as a side quest.

Weak: “Why is this broken?” without a stack trace or file. Strong: paste the error, @-mention the stack frames’ files, ask for a root-cause hypothesis and a minimal fix plan before edits. Diagnosis prompts should request a plan gate when the system is unfamiliar; implementation prompts should request a diff when the fix is local.

Notice the pattern: weak prompts outsource judgment; strong prompts encode judgment. Cursor is extremely good at executing a clear brief and extremely creative at filling an empty one. Your structure is how you choose which of those talents you unlock.

Safety, secrets, and review culture

Never paste production secrets into a prompt you might sync, share, or publish. Describe secret usage (“read STRIPE_KEY from env”) without values. Redact customer data from logs before asking for analysis. Treat agent chat as semi-public, even when it feels private.

High-risk areas — auth, payments, migrations, cryptography — deserve stricter prompts and stricter human review. Add rules like “do not weaken auth checks” and acceptance bullets that force explicit reasoning about threat cases. A structured prompt reduces variance; it does not sign the deploy.

Build a team norm: agent diffs get the same checklist as human diffs. Run tests. Skim every file. Reject scope creep politely and rerun with tighter rules. The builders and recipes on this page make the first message better; culture makes the last merge safe.

When you publish Cursor prompts to a library, strip company-specific paths if needed, keep the guardrails, and write a short “why it works” note. The next reader should understand which lines are load-bearing. Opaque mega-prompts help no one.

From one great prompt to a reusable system

One excellent Cursor prompt fixes today. A library of them fixes the quarter. Save the idempotency brief, the a11y feature brief, the migration plan brief. Fork them per ticket. That is how teams stop relearning the same agent lessons every sprint — and how PromptFork turns coding prompts into shared infrastructure instead of private chat folklore.

Related tools

Questions people ask about Cursor prompts