24 Cursor Agent Mode Prompts (2026)

Explore this repo and report back — do NOT edit any files yet.

Task I'm about to give you: [describe the change].

Do this:
- Use @Codebase to map the areas this task touches: entry points, the modules involved, and how they connect.
- List the exact files you'd need to change and why, with paths.
- Tell me the commands to build, run, lint, and test here (check @Files package.json / Makefile / README).
- Flag anything fragile or unusual I should know before we start.
Report back in a short summary. Don't write code and don't touch unrelated files.

Propose a plan for this change and wait for my approval before editing.

Goal: [what should be true when done].
Acceptance criteria: [how we'll know it works, e.g. tests pass, endpoint returns X].
Relevant context: @Files [path/a] @Files [path/b] @Folders [dir/]

Do this:
- Outline the steps in order, naming the files you'll create or edit at each step.
- Call out risks, migrations, or anything destructive.
- State how you'll verify the result against the acceptance criteria.
Show me the plan only. Do NOT edit files or run commands until I say "go".

Break this large task into small, independently shippable steps.

Task: [the big feature or change].
Context: @Codebase, plus @Folders [dir/] where most of the work lives.

Do this:
- Split it into steps that are each small enough to review in one sitting.
- For each step: the goal, the files touched, and how I'd verify it (which test or command).
- Order them so each step leaves the app in a working, testable state.
- Note which steps depend on which.
Give me the step list first. We'll do them one at a time — don't start coding yet.

Estimate the blast radius of this change before we make it. Read-only.

Change: [what I want to change, e.g. rename this field / alter this function's signature].
Start from: @Code [symbol or function] and @Files [path].

Do this:
- Use @Codebase to find every file and call site that depends on this.
- List them with paths, grouped by how risky each is to change.
- Point out tests that cover this area and gaps where none do.
- Recommend the safest order to make the change.
Report only — don't edit anything or touch unrelated files.

Implement this feature end to end.

Spec: [what the feature does, inputs, outputs, behavior].
Acceptance criteria:
- [criterion 1, e.g. GET /things returns the list as JSON]
- [criterion 2]
- All existing and new tests pass.
Context / patterns to match: @Files [sibling feature file] @Folders [feature dir/]

Do this:
- Show me your plan and the files you'll change before editing.
- Implement it following the existing patterns in the files above.
- Add tests for each acceptance criterion, then run the test suite and fix failures.
- Show me the diff and a summary when done.
Only touch files needed for this feature. Ask before anything destructive.

Build a full [feature name] feature across the stack and wire it together.

What it does: [describe the user-facing behavior].
Layers: UI in @Folders [ui dir/], API in @Folders [api dir/], DB via @Files [schema/migrations path].
Acceptance criteria: [end-to-end behavior, e.g. user submits form -> row saved -> list updates].

Do this:
- Plan the change across all three layers and show it before editing.
- Add the DB change/migration, the API endpoint with validation, and the UI, matching existing patterns.
- Wire them end to end. Add tests at the layer boundaries and one end-to-end test.
- Run the migration in a safe/dev context, run the tests, and fix failures.
- Show me the per-file diff and how to run it locally.
Don't touch unrelated files. Ask before running any destructive migration.

Add a new [METHOD] [path] endpoint following the conventions here.

Behavior: [what it does, request shape, response shape].
Match the pattern in: @Files [existing route file].

Do this:
- Add the route, request validation, error handling, and the response type.
- Validate input and return proper status codes for bad input (e.g. 400 with a clear message).
- Write tests covering the happy path, invalid input, and the not-found/error path.
- Run the tests and fix any failures.
- Show me the diff.
Only add/change files for this endpoint — don't touch unrelated routes.

Integrate the [service name] API into this project.

Use @Docs [service docs] for the current API — don't guess endpoint names or parameters.
Goal: [what the integration should do].
Where it belongs: @Folders [integrations dir/], config via @Files [config/env file].

Do this:
- Read the docs, then show your plan and the files you'll add before editing.
- Add a small client wrapper, keep secrets in config/env (never hard-code keys), and handle errors and rate limits.
- Add tests that mock the external call so they run offline.
- Run the tests and fix failures. Show me the diff.
If the docs are unclear on a detail, ask rather than guessing. Don't touch unrelated files.

Create a [CLI tool / script] that does the following.

Purpose: [what it does]. It should accept: [flags/args]. It should output: [result/format].
Language & conventions: match @Files [an existing script here].
Put it at: [path].

Do this:
- Show your plan, then implement it with argument parsing, input validation, and clear errors.
- Add a --help output and a couple of usage examples in a comment or README section.
- Add tests for the core logic; run them and fix failures.
- Run the tool once on sample input via @Terminal to prove it works, and show me the output.
Only create/change files for this tool. Don't touch unrelated files.

Rename [oldName] to [newName] across the whole repo.

Symbol: @Code [oldName] (defined in @Files [path]).

Do this:
- Use @Codebase to find every usage: definitions, imports, call sites, tests, and strings/config where it matters.
- Rename all of them consistently — don't leave a mix of old and new.
- Skip unrelated identifiers that happen to contain the same substring; only rename this symbol.
- Run the build and full test suite, and fix anything the rename broke.
- Show me the per-file diff.
Don't change behavior — this is a pure rename.

Migrate this project from [library/framework old version] to [new version].

Use @Docs [migration guide / new-version docs] for the real breaking changes — don't guess.
Scope: @Codebase (every usage of the old API).

Do this:
- First list every breaking change that affects us and the files each one hits. Show this before editing.
- Update the code to the new API across all those files, preserving behavior.
- Update the version in @Files [package/lockfile], reinstall, and run the build.
- Run the full test suite and fix failures. Note anything the new version handles differently.
- Show me the diff grouped by breaking change.
Do this in reviewable steps. Ask before anything destructive.

Extract this duplicated logic into a shared module.

The duplication lives in: @Files [path A] @Files [path B] (and possibly others — use @Codebase to find the rest).

Do this:
- Identify all the copies of this logic and confirm they're truly equivalent before merging them.
- Create a shared module at [target path] with a clean interface.
- Replace every copy with a call to the shared module. Update imports.
- Keep behavior identical. Run the tests and fix failures.
- Show me the diff and list every call site you changed.
Don't touch code unrelated to this extraction.

Apply this code transformation everywhere it appears.

Old pattern:
<before>
[paste the old pattern, e.g. old logging call]
</before>
New pattern:
<after>
[paste the replacement]
</after>
Scope: @Folders [dir/] (or @Codebase for the whole repo).

Do this:
- Find every occurrence of the old pattern, including near-variants I might have missed.
- Rewrite each to the new pattern, preserving surrounding logic and formatting.
- Skip any occurrence where the transform doesn't apply cleanly, and list those for me to handle.
- Run the build and tests, and fix failures.
Show me the diff. Don't touch unrelated code.

I'm changing the signature of [function] — update every call site to match.

Function: @Code [function] in @Files [path].
New signature: [describe the new params/return, e.g. now takes an options object / returns a Result].

Do this:
- Use @Codebase to find every caller of this function.
- Update each call site to the new signature, adapting arguments correctly (not just mechanically).
- Update any mocks, stubs, and tests that reference the old signature.
- Run the build and full test suite; fix anything that breaks.
- Show me the per-file diff and the full list of updated call sites.
Only change the function and its callers — don't touch unrelated files.

Reproduce this bug with a failing test, then fix it.

Symptom: [what's wrong]. Steps to reproduce: [steps]. Expected vs actual: [both].
Suspected area: @Files [path] (but use @Codebase if it's elsewhere).

Do this:
- Write a test that reproduces the bug and confirm it fails for the right reason. Show me the failing output.
- Trace the root cause and explain it in one or two lines.
- Fix it with the smallest safe change.
- Re-run that test plus the full suite to prove it's fixed and nothing else broke.
- Show me the diff and the root cause.
Only change what the fix needs — don't touch unrelated files.

A bug is somewhere in the flow — help me find it across files.

Symptom: [what goes wrong and when].
Entry point: @Code [handler/function] in @Files [path]. The flow spans several modules.

Do this:
- Trace the code path with @Codebase from the entry point to where the symptom appears.
- List your ranked hypotheses for the root cause with the file/line each points to.
- Add temporary logging or a probe to confirm the top hypothesis, and run it via @Terminal.
- Once confirmed, apply the smallest fix, remove the temporary logging, and run the tests.
- Report the root cause, the fix, and how you verified it.
Don't touch unrelated files.

Fix all the current lint errors properly.

Errors: @Lint Errors

Do this:
- Group the errors by root cause, not one-by-one.
- Fix each by addressing the real issue — do NOT silence rules with ignore comments unless I approve it and you explain why.
- Keep behavior identical; if a lint fix would change behavior, stop and ask.
- Re-run the linter and the tests until both are clean.
- Show me the diff grouped by the kind of fix.
Only touch the files with errors — don't reformat unrelated code.

The build/CI is failing. Here's the output — fix it.

Failure output: @Terminal
(If you need to reproduce it, run: [the CI command, e.g. npm test / make ci].)

Do this:
- Read the failure and identify the actual root cause, not just the first red line.
- If it's an env/config issue vs a code issue, tell me which.
- Fix the code, then re-run the same command locally to confirm it passes.
- If several tests fail for different reasons, handle each and re-run until green.
- Show me the diff and a one-line explanation per fix.
Don't touch unrelated files or disable failing tests to make it pass.

Write tests for this code, run them, and fix whatever they surface.

Target: @Files [path] (behavior to cover: [what it should do]).
Framework: [Jest / pytest / etc.] — match the existing test style in @Folders [tests dir/].

Do this:
- Cover the happy path, edge cases, and error paths; name each test after the behavior it checks.
- Run the tests. If a test fails, decide whether the bug is in the code or the test, tell me which, and fix accordingly.
- Don't delete or weaken a test just to make it pass — if it caught a real bug, fix the code.
- Re-run until green and show me the results plus the diff.
Only add tests and any code fixes they justify — don't touch unrelated files.

I need to change [file/area] but it has little test coverage. Make it safe first.

Target: @Files [path]. Planned change (later): [describe it].

Do this:
- Read the code and describe its current behavior precisely — bugs and quirks included.
- Write characterization tests that lock in that current behavior so any change that alters it will fail loudly.
- Run them and confirm they pass against the code as it is now.
- Then tell me the safest order to make the planned change.
Don't fix anything yet and don't touch unrelated files — this step is only about capturing today's behavior.

Verify your last change against the acceptance criteria before I review it.

Acceptance criteria:
- [criterion 1]
- [criterion 2]
- Build passes, lint is clean, all tests pass.

Do this:
- Go through each criterion and state, with evidence, whether it's met — run the relevant test or command via @Terminal to prove it.
- Run the full build, lint, and test suite and paste the results.
- If anything fails or a criterion isn't met, fix it and re-check — don't report done until all are green.
- Then give me a short summary and the diff.
Don't change anything outside what these criteria require.

Run this as a background task while I work on something else.

Task: [self-contained, well-scoped change].
Everything you need: @Folders [dir/] @Files [key files]. Acceptance: [checkable done, e.g. tests pass].

Do this:
- Work autonomously to completion — plan, edit, and run the tests yourself.
- Stay strictly within [dir/]; do not touch anything outside it.
- If you hit a genuine ambiguity you can't resolve safely, stop and leave a note instead of guessing.
- When done, run the full test suite and leave me a summary, the diff, and the test results to review.

Here are several independent tasks. Confirm they don't overlap, then plan them for parallel agents.

Tasks:
1. [task one] — scope: @Folders [dir A/]
2. [task two] — scope: @Folders [dir B/]
3. [task three] — scope: @Folders [dir C/]

Do this:
- Check whether any two tasks touch the same files; if they do, flag the conflict so I don't run them in parallel.
- For each non-conflicting task, restate it as a self-contained spec with acceptance criteria and its file boundary.
- Tell me which can safely run at the same time and which must be sequenced.
Don't start editing — just give me the parallelizable plan.

Implement the feature described in this spec document.

Spec: @Files [path/to/SPEC.md]. Codebase context: @Codebase.

Do this:
- Read the spec fully, then restate your understanding and the acceptance criteria back to me so we agree before you start.
- Show your implementation plan and the files you'll change.
- Implement it to match the spec, following existing patterns. Add tests for each acceptance criterion.
- Run the build and tests, fix failures, and re-check the result against the spec.
- Report the diff, what's done, and anything in the spec that was ambiguous or you deferred.
Only build what the spec calls for — don't touch unrelated files, and ask before anything destructive.