How to prompt Cursor Composer 2.5

Prompt Composer 2.5 like you’re briefing an engineer who will start work immediately. Open with one goal sentence that includes the outcome, add the repo context, state hard constraints before the work starts, and say how you want the answer presented (usually diffs). Composer is Cursor’s coding agent for real codebases. Ask it to do the work, not to propose a plan.

What Composer 2.5 is built for

Cursor trained Composer 2.5 for sustained, multi-step coding inside existing repositories, with explicit attention to coding style, communication and effort calibration. That shapes the prompts that work: a self-contained task brief with everything the agent needs to act.

The prompt structure

Use plain labels on their own lines, in this order:

Goal
Add pull-to-refresh to the activity feed so users can load new items
without restarting the app.

Context
React Native + TypeScript. Data fetching goes through hooks in
the feed feature folder using React Query. Follow the existing
useFeed hook pattern.

Constraints
- No new dependencies.
- Keep the current empty-state and error UI unchanged.

Output format
Diffs only. Under 120 words of explanation.

Success criteria
- Pulling down refetches and shows the native spinner.
- Existing feed tests pass.

Scale the structure to the task. A quick fix needs Goal and Context. A larger feature earns Constraints and Output format. Save Success criteria for demanding work. Leaving a block out beats padding it.

Goal: an action with an outcome

“Refactor the auth flow to remove duplicate session refresh logic” gives the model something to aim at. The outcome clause (“so users can…”, “so that…”) lets it make sensible trade-offs along the way.

Frame it as work to do now: “Implement”, “Fix”, “Refactor”, “Write”. Prompts like “Suggest how I might…” or “What do you think about…” produce analysis instead of edits.

Context: the facts that change the code

Name the stack, the relevant area and the patterns to follow: how data is fetched, how state is managed, where tests live. Context earns its place only if it changes the implementation. “This is a web app” doesn’t.

Never invent file paths or component names. A wrong path sends the agent to edit the wrong place, which is worse than no path. If you don’t know where something lives, describe it (“the screen that renders the activity feed”) and let Composer find it.

Constraints: before the work, not after

Stating limits up front is far more effective than correcting the agent afterwards. Common constraints:

• No new dependencies.
• No breaking API changes.
• Stay within a named area.
• Keep public exports, event names and runtime behaviour identical.

Separate must-haves from preferences, and phrase them positively. “Keep data access inside the service layer” steers better than “don’t query the database from components”.

Output format: diffs, short prose

A lot of prompt failure is really output failure. Ask for:

• Diffs or changed sections, not whole files.
• A cap on explanation length.
• Code in fenced blocks when prose and code are mixed.
• A short note on the tests and edge cases the change affects.

For reviews, ask for findings grouped by severity, with line references and concrete fixes, and no full rewrite.

Large tasks: phases, not approval gates

For a real migration or multi-file feature, a short numbered process helps: inspect the relevant files, briefly summarise, implement in small steps, then verify against the criteria. Keep those as working steps. “Propose a plan and wait for approval” stalls an agent you asked to do the work. If you only want a plan, make the plan the whole task.

Follow-ups: one precise correction at a time

Composer responds best to targeted feedback: “Use the existing sessionStore instead of a new cache.” “Same approach, but don’t move any files.” “Show only the changed sections.”

Vague restarts like “try again” or “this feels off” give it nothing specific to fix. Say which part is wrong and what right looks like, and leave the rest alone.