Cursor Prompts: Chat, Agent, Composer, and .cursor/rules

Cursor prompts are the asks you send through Cursor Chat, Agent, Composer, and durable project rules in .cursor/rules. Chat answers questions against pinned files and @ mentions. Agent plans and edits with steps you approve. Composer (multi-file edit) wants a fence, a success check, and a stop rule. Rules in .mdc files teach stack and style so you stop repeating the same constraints. This guide stays inside Cursor IDE. You get prompt anatomy for those four surfaces, a write-and-verify loop, paste examples, a mistakes list, and a note on PromptMake /text for scaffolding English before you paste. Soft tip: https://promptmake.net/text.

What cursor prompts cover

A Cursor prompt is any instruction you send in Chat, an Agent brief, a Composer task, a Tab comment above the cursor, or a rule file the Agent reads. Cursor also uses context you did not type: open editors, the selection, chat history, @file and @folder pins, and .mdc rules with globs or alwaysApply. A clean sentence with the wrong files open still drifts.

This page fits developers who already work in Cursor and still get full-file rewrites, wrong-stack guesses, or Agent loops that touch files outside the ticket. You need Cursor-shaped asks: goal first, then constraints, then scope, then a test or typecheck. Skip this path if you want GitHub Copilot Chat and copilot-instructions.md, or a model-agnostic coding course for browser ChatGPT. Those topics live in other posts. Here the product is Cursor, and the win is fewer wasted threads in your repo.

As of mid-2026, Cursor lets you pick models such as Claude Opus 5, Claude Sonnet 5, GPT-5.6 Sol, and Gemini 3.5 Flash for volume. Hard reasoning and multi-file edits often land on Opus 5 or GPT-5.6 Sol. Fast Chat Q&A can sit on Flash or a cheaper Cursor default. Name the model in your head when you write the ask: reasoning-class models want goal plus constraints plus format. Skip "think step by step" on those. Fast chat still likes a short role, task, and output shape.

PromptMake /text does not run inside Cursor. It cannot see your index, @Codebase hits, or rule files. Use it to tighten the English of a Chat or Agent brief. Paste the edited text into Cursor. Keep secrets and private customer data out of public generators.

How Cursor Chat and Agent read your ask

Cursor treats your words as one input among several. The written goal sits next to editor state and durable rules. People blame the model after a weak reply when they skipped context control. The prompt looked fine in isolation. The IDE handed the model stale history, ten unrelated tabs, or a novel of always-on rules that crowded out the ticket.

You control three layers. Layer one is the written ask: outcome, constraints, files in scope, files to leave alone, and how you will verify. Layer two is session state: which files you @ mention, what you selected, which chat you keep open. Layer three is project guidance: .cursor/rules/*.mdc, plus AGENTS.md if the repo uses that file for always-on agent notes. Strong cursor prompts align all three. A perfect sentence with the wrong @ pins still misses.

Keep the first draft of the ask short. Put the outcome before the constraint list. If the goal is still fuzzy, sharpen it offline. Draft the goal and fences in notes or on PromptMake /text, then paste into a fresh Chat or Agent thread with the right files attached. Soft link: https://promptmake.net/text.

Open files, @ mentions, and chat history

For Tab completions, open the files that teach the pattern you want and close the rest. Tab leans on nearby code and the comment above the cursor. Project rules do not apply to Tab the way they apply to Agent Chat. A precise comment is the prompt: name inputs, error behavior, and return shape.

For Chat and Agent, @ mention the files or folders that belong in the job. @Codebase (or the current codebase participant in your build) searches the repo when you need a map. Name the symbol in the sentence when "this" could mean the selection, the last reply, or the whole package. "Explain parseInvoice in src/billing/parse.ts and list two failure modes" gives the model a target.

Chat history counts as context. Start a new thread if the topic shifts from auth bugs to CSS. Delete turns that pull the model toward an old plan. One clean thread per task beats a long scroll of mixed goals. Large monorepos can return incomplete codebase hits. If the answer cites the wrong package, pin the correct @file and restate the package name in the prompt.

Project rules in .cursor/rules

Store project rules as .mdc files under .cursor/rules, not a leftover root .cursorrules file. Cursor docs treat the single-file format as legacy. Each .mdc file uses YAML frontmatter: description, globs, and alwaysApply. Always-on rules load every Agent Chat. Glob rules attach when matching files sit in context. Description-only rules load when the Agent judges them relevant. Manual rules wait for an @ mention.

Keep each rule short and scoped. Put stack, folder map, and banned patterns in a small always-on file. Put React component conventions in a glob for *.tsx. Put migration safety in a manual rule you @ mention during schema work. A 2,000-line always-on dump crowds the context window and dilutes the ticket prompt. Stale stack notes mislead as hard as missing notes. Update the file the day the stack changes.

User rules in Customize apply across projects on that machine. Team rules sync from a Cursor team dashboard when your org uses them. Per-task prompts still state the current goal. Rules teach durable facts. They do not replace a scoped Agent brief.

Step-by-step: write cursor prompts that ship

Use one loop for Chat, Agent, and Composer. Tab gets a shorter cousin: write the comment, keep related tabs open, accept or reject ghost text, then move on. The Chat and Agent loop saves the most time because a bad thread burns minutes and pollutes history.

Work from a real ticket or failing test. Copy the symptom, the expected behavior, and the file paths from the issue. Do not invent architecture mid-prompt. If you still hold a fuzzy goal, spend two minutes sharpening it offline. PromptMake /text can turn "login is broken" into a goal, constraints, and output shape you then adapt with @ files. Measure success by a reviewable diff and a passing check. A fluent essay about your codebase that you cannot merge is a failed prompt, even when it sounds smart.

Pick the model for the job before you send. Use Claude Opus 5 or GPT-5.6 Sol for multi-file Agent work and hard bugs. Use Gemini 3.5 Flash or a fast Cursor default for "where is this symbol" Chat. Switch models mid-thread only when you also restate the goal; leftover plan text plus a new model can wander.

Step 1: State the goal, then the constraints

Open with the outcome in one or two sentences. Example: "Add cursor-based pagination to GET /orders without changing auth." Then list constraints: language and framework versions, files in scope, files to leave alone, style rules, and banned approaches.

Add one example when format matters. Paste a sample request and response, or point at an existing handler Cursor should mirror. Unit tests count as examples: ask the Agent to draft failing tests first, then implement until they pass.

Vague verbs invite large rewrites. Prefer "Return a unified diff for OrdersController only" or "List three root-cause hypotheses before any edit." Skip "improve" and "clean up" as the whole ask.

Step 2: Scope files and success checks

Attach @file or @folder references for the exact paths you want in context. Write FILES IN SCOPE and DO NOT MODIFY lines in the prompt so Agent and Composer have a fence. Add the verification command: the test file, typecheck, or lint target that must stay green.

If root cause might sit outside the fence, tell Cursor to stop and explain in three sentences instead of patching neighbors. That stop rule prevents drive-by refactors that wreck review.

For Chat-only questions (explain, review, compare), still name the path and the reader. "Summarize risks in src/payments/webhook.ts for a reviewer who knows Stripe but not our retry queue" beats "review this."

Step 3: Break Agent and Composer work into approved steps

Agent mode plans and edits. Composer applies multi-file changes in one pass. Feed both a sequence, not a weekend project in one message. Ask for a short plan first. Approve the plan. Then allow step 1 only: for example, extract a pure function and update its unit tests. Review the diff. Start the next step in the same thread only if context still helps; otherwise open a fresh thread with the plan pasted in.

Require diffs or patch-style output when your flow supports it. Tell the Agent to document assumptions in comments or a short note. Approve terminal commands before they run. Treat suggested shell as untrusted until you read it.

If the Agent loops or rewrites the same file twice without progress, stop the run. Narrow the prompt: one file, one function, one test. Wide Agent prompts create thrash more than they create velocity.

Chat vs Agent vs Composer vs rules

Pick the lane before you write the ask. Mixing lanes in one mental model causes the wrong prompt shape. Tab wants a local comment. Chat wants a scoped question or small edit brief. Agent wants sequenced work with fences and checks. Composer wants a bounded multi-file change you will review as a unit. Rules hold standing project truth so each of those lanes starts from the same stack.

Cursor prompts for Chat often include an @ pin and an output shape: bullets, a short plan, a risk list, or "ask me one clarifying question if X is missing." Agent prompts add migration safety, rollback notes, and explicit stop conditions. Composer prompts name every file that may change and every file that must stay untouched. Rule text stays durable: stack, folder map, coding conventions. Ticket detail stays in the message.

Model choice still sits on top of the lane. A Composer dump on a fast Flash-class model can miss edge cases. A Chat "where is rate limiting" question on Opus 5 can waste a slower, costlier turn. Match model to job, then write the prompt for that lane.

Chat prompts

Use Chat for explanation, review, small patches, and test generation. Structure: goal, @ pins, constraints, output format. Example: "@Codebase How does rate limiting work for the public API? Cite file paths. Then propose a 10-line change in the existing middleware only."

Keep one concern per thread. Say "stop edits; answer in bullets only" or start over if Chat drifts into unrelated refactors. Save winning prompt text in your notes next to the ticket id.

Agent and Composer prompts

Give Agent a mission with fences. Example: "Plan a tagging subsystem for the notes service. Do not edit yet. List files, schema impact, and rollback. After I approve, implement domain model and tests only; leave controllers for a second pass." Composer can take the approved slice: "Apply the domain-model plan in these two files. Do not touch controllers. Run the unit tests I named."

Ask for tradeoff notes when architecture is open. Ask for diff-sized steps when architecture is closed. You remain the reviewer of record. Do not grant blanket trust on production migrations or secret-bearing scripts.

Worked examples you can paste

Bug-fix Chat prompt:

Goal: Fix the submit button that stays disabled after a valid SignupForm fill.

Stack: TypeScript, React, Vitest.

FILES IN SCOPE: src/components/SignupForm.tsx

@ mention that file. DO NOT MODIFY: validation schema, API routes.

OUTPUT: unified diff only, plus a two-sentence root-cause note.

TEST: npm test -- SignupForm.test.tsx must pass.

If cause is outside scope, stop and explain; do not patch other files.

Agent sequencing prompt:

Goal: Add additive, backward-compatible tags to the notes service.

Step 0: Propose schema migration, rollback, and client impact. No code yet.

After approval, Step 1: domain model + repository + unit tests only.

Stop before controllers. Document assumptions in a short NOTES comment.

Composer fence prompt:

Apply Step 1 only. Files allowed: src/notes/domain.ts, src/notes/repo.ts, src/notes/domain.test.ts. Leave HTTP handlers untouched. Run the named tests. If a type error appears outside scope, stop and report it.

Tab comment example:

// Map webhook events to internal JobStatus; unknown types return null and log a warning; do not throw.

Rule snippet idea (short always-on .mdc body): name the stack, the test command, and two bans (no new ORM; no drive-by format of unrelated files). Keep globs on UI conventions so they stay out of backend chats.

Your edit after any generator scaffold: add real paths, package names, and the exact test command from your repo. Tools that draft English cannot invent your tree.

Mistakes that waste Cursor turns

Mistake 1: "Fix this" with 400 lines pasted and no output shape. You invite a full rewrite. Demand a diff and a file fence.

Mistake 2: One endless Chat thread across unrelated tasks. Stale history steers new answers. Start fresh when the job changes.

Mistake 3: One huge alwaysApply rule or a leftover .cursorrules file that fights .mdc rules. Split by concern. Prefer .cursor/rules with globs.

Mistake 4: Agent briefs that ask for a multi-day feature in one shot. Split into plan, then thin vertical slices with tests.

Mistake 5: Treating PromptMake or any external scaffold as if it could see your workspace. It drafts wording. You add @ pins, rules, and local truth.

Mistake 6: Accepting Agent shell commands without reading them. Approve only what you would type yourself.

Mistake 7: Collecting random "best Cursor prompts" lists instead of saving three personal templates for bugfix, review, and small feature. Lists go stale. Your templates match your repo.

Soft scaffold with PromptMake /text

PromptMake /text turns a rough idea into a structured text prompt. For Cursor, that means a clearer Chat, Agent, or Composer brief: goal, constraints, output format, stop rules. You still paste into the IDE and attach @ files yourself.

Honest limits: /text does not complete code in Cursor, does not index your repo, does not write .mdc rules for you, and does not replace Cursor plans or Agent runs. Guests get about three /text runs per day. Free accounts get about five. Keep proprietary source out of public tools when policy forbids it; describe the bug in redacted form if you only need structure help.

A practical path: write three messy sentences about the ticket. Generate once on https://promptmake.net/text with a text or ChatGPT-style target as a stand-in for structure. Edit in the real file paths and test commands. Paste into a new Cursor Chat or Agent thread with @ pins. Save the final prompt beside the ticket.

If the job is image work or Midjourney dialect, use a different tool path. This article and CTA stay on text scaffolding for Cursor Chat, Agent, and Composer.

FAQ

These answers cover the searches people type after a weak Cursor Chat reply or an Agent that rewrote half the repo. Topics include what cursor prompts are, how to structure cursor ai prompts for Chat, when Agent or Composer fits, what .cursor/rules files do and do not replace, where PromptMake /text helps without pretending to be an IDE plugin, how this guide differs from GitHub Copilot and from general AI-for-code articles, and how to start on a free PromptMake tier. Each answer stays short so you can act in the same session. If you already finished the workflow sections, skim for the gap that still blocks you.

What are cursor prompts?

Cursor prompts are the instructions you give Cursor through Chat, Agent, Composer, Tab comments, or project rules. Cursor also reads open files, chat history, @ mentions, and .cursor/rules .mdc files. Strong prompts name the goal, constraints, file scope, and how you will verify the result. Weak prompts leave those blanks and force the model to guess.

How do I write better cursor ai prompts for Chat?

Start with the outcome, then list requirements. @ mention the files you care about, and use codebase search when you need a map of the repo. Ask for a concrete output shape such as bullets, a short plan, or a unified diff. Open a new thread when the task changes so old turns do not steer the model.

Should I use Agent, Composer, or Chat?

Use Chat for questions, reviews, and small scoped edits you want to steer turn by turn. Use Agent when you want a planned multi-file change with steps you approve. Use Composer when you already know the slice and want a bounded multi-file apply you will review as a unit. Agents and Composer need tighter fences; Chat needs cleaner history and precise @ pins.

Do .cursor/rules files replace per-task cursor ai prompts?

Rule files teach durable project facts: stack, style, folder map, and scripts. Per-task prompts still state the current goal, scope, and verification. Keep .mdc files short, scoped with globs, and current. Put one-off ticket detail in the Chat, Agent, or Composer message.

Can PromptMake write prompts that run inside Cursor?

PromptMake /text can draft a clearer English brief you paste into Cursor Chat, Agent, or Composer. It cannot see your IDE, attach @ files, or apply your .mdc rules. Soft start: https://promptmake.net/text for structure, then finish context inside Cursor. That split keeps expectations honest.

How is this different from GitHub Copilot prompts or general AI prompts for code?

Copilot guides cover GitHub Copilot Chat, agent mode, and .github/copilot-instructions.md. General coding prompt guides target ChatGPT or Claude in a browser with paste-in files. Cursor prompts lean on Cursor Chat, Agent, Composer, Tab, and .cursor/rules .mdc files, so templates here stay Cursor-specific even when diff-only output still helps.

How do I start today on a free PromptMake tier?

Pick one real bug or small feature and write three rough sentences offline. Generate one scaffold on /text if you want help shaping goal and constraints, then edit in real paths and tests. Paste into a fresh Cursor Chat or Agent thread with the right files pinned. Guest /text use needs no signup for a small daily quota; register if you need more runs the same day.