Cursor Prompt Templates (2026): Fill-in-the-Blank

MODE: Agent

Build this feature end to end.

Feature: [what it should do, in one sentence].
Spec / acceptance: [the behavior that must be true when you're done].
Context: @Files [path/to/related/file] @Folders [path/to/feature/dir] @Codebase

Do this:
- Plan first: list the files you'll create or edit and wait for the plan, don't edit yet.
- Follow the patterns already in the code I attached.
- Add or update tests for the acceptance criteria, then run them.
- Show me the per-file diff and a 3-line summary.

Constraints: only touch files needed for this feature; don't change unrelated code; done when [the test command] passes.

MODE: Agent

Scaffold a [component / API endpoint / module] that matches my codebase.

Stack: [framework and version]. Responsibility: [what it does].
It talks to: [DB / API / other module].
Context: @Files [path/to/sibling/file] @Definitions [TypeOrInterfaceName]

Do this:
- Create it at [exact/target/path] using the conventions in the sibling file.
- Include types, error handling, and one minimal test.
- Leave clearly marked TODOs where business logic is mine to write.
- Print the file tree of what you added.

Constraints: match the attached file's style; don't touch unrelated files; show the diff before I accept.

MODE: Agent

Integrate [service / library name] into this project.

Goal: [what the integration should let us do].
Docs: @Docs [service name] @Web [official docs URL if not indexed]
Context: @Files [path/to/where/it/goes] @Folders [config/or/env/dir]

Do this:
- Read the docs I attached before writing any code; use the current API, not guesses.
- Add the client/setup at [exact/path], with keys read from [env var], never hardcoded.
- Write one integration test that exercises the happy path and run it.
- List every new dependency and env var I need to set.

Constraints: use the attached @Docs as the source of truth; if an API detail is unclear, ask instead of guessing; don't touch unrelated files.

MODE: Agent

Build this UI to match the reference. [Attach the screenshot to the chat, or describe it below.]

Reference: [paste image, or describe layout, states, and behavior].
Stack: [framework + styling approach]. Where it lives: [exact/component/path].
Context: @Files [path/to/existing/component] @Folders [components/dir]

Do this:
- Reuse existing components and design tokens from the attached files; don't invent new styling.
- Match layout, spacing, and the empty / loading / error states.
- Make it responsive and keyboard-accessible.
- Show the diff and note anything in the reference you couldn't infer.

Constraints: keep it to [exact/component/path] and its styles; don't touch unrelated files; done when it renders and matches the reference.

MODE: Agent

Diagnose and fix this error. Explain the root cause before you change anything.

Error / stack trace:
[paste the full error]
Expected: [what should happen]. Actual: [what happens].
Context: @Lint Errors @Terminal @Files [path/to/suspect/file] @Recent Changes

Do this:
- State the most likely root cause first, then one alternate.
- Apply the smallest safe fix at the exact location.
- Add or update a test that would have caught this, then run the suite.
- Show the diff and how you confirmed it's resolved.

Constraints: fix only the cause of this error; don't touch unrelated files; done when the failing case passes and nothing else broke.

MODE: Agent

Reproduce this bug before fixing it.

Symptom: [what's wrong]. Steps to reproduce: [steps].
Expected vs actual: [both].
Context: @Codebase @Files [path/to/area] @Terminal

Do this:
- First write a failing test (or run the repro steps) and confirm you see the bug.
- Trace it to the root cause across files and tell me where it is.
- Fix it with the smallest change, then re-run the test/repro to prove it's fixed.
- Check nothing adjacent broke.

Constraints: no fix until the repro fails as expected; don't touch unrelated files; report the root cause, the fix, and how you verified it.

MODE: Agent

Some tests are failing. Decide whether the test or the code is wrong, then fix it.

Failing tests: [test names or file].
Context: @Terminal @Files [path/to/tests] @Files [path/to/code/under/test]

Do this:
- Run the tests and read the actual failure output.
- For each failure, tell me whether the bug is in the test or the code, and how you know.
- Apply the minimal fix; if a test asserted the wrong thing, correct it and explain the right expected behavior.
- Re-run until green and show the diff.

Constraints: don't delete tests to make them pass; don't touch unrelated files; done when [the test command] is fully green.

MODE: Agent

Refactor this for readability without changing behavior.

Target: [what to refactor and why].
Context: @Files [path/to/file] @Definitions [functionOrClassName]

Do this:
- Keep the exact same inputs and outputs.
- Improve naming, structure, and duplication only.
- Run the existing tests before and after to prove behavior is unchanged.
- Show the diff and a short list of what changed and why.

Constraints: behavior must not change; if there are no tests, say so and add characterization tests first; don't touch unrelated files.

MODE: Agent

Break up this oversized [function / component / module] into smaller pieces.

Context: @Files [path/to/file] @Definitions [theBigSymbol]

Do this:
- Extract logical units into named, single-responsibility pieces at [target location].
- Keep behavior identical and note any hidden coupling you find.
- Update call sites and imports.
- Run the tests, then show the diff plus a one-line job description for each new unit.

Constraints: no behavior change; keep public signatures stable unless I approve; don't touch unrelated files; done when tests pass.

MODE: Agent

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

Scope: [which files or module].
Context: @Docs [new library] @Files [path/to/affected/files] @Codebase

Do this:
- Use the new API from the attached @Docs; preserve behavior.
- Migrate one file at a time and keep tests green between each.
- Give me a table of every changed call and what replaced it.
- Flag deprecations, breaking changes, and anything I must test manually.

Constraints: don't upgrade unrelated dependencies; if a current API detail is unclear, ask instead of guessing; show the diff per file; done when the suite passes on the new version.

MODE: Agent

Write thorough unit tests for this code and run them.

Framework: [Jest / Vitest / pytest / etc.].
Context: @Files [path/to/code] @Definitions [functionOrClassName]

Do this:
- Cover the happy path, edge cases, and error paths.
- Include boundary cases I'd forget: empty, null, max, negative, unicode.
- Name each test after the behavior it verifies.
- Run the suite and fix any test that doesn't pass; flag anything hard to test as a possible design smell.

Constraints: put tests at [test/path]; don't change the code under test unless you find a real bug — if so, ask first; don't touch unrelated files.

MODE: Ask

Tell me what I'm not testing — don't edit anything yet.

Context: @Files [path/to/code] @Files [path/to/existing/tests] @Terminal

Do this:
- List the untested paths, branches, and edge cases, ranked by risk.
- Note any behavior that looks untested because it's dead or unreachable code.
- Propose the top 5 tests to add, with a one-line rationale each.
- Wait for me to pick which ones before writing anything.

Constraints: read-only analysis in Ask mode; reference the real coverage output if I paste it; don't propose duplicate tests.

MODE: Agent

Write an end-to-end test for this user flow and run it.

Flow: [the steps a user takes, start to finish].
Tooling: [Playwright / Cypress / etc.].
Context: @Folders [e2e/or/tests/dir] @Files [path/to/relevant/pages]

Do this:
- Model the full flow: [step 1] → [step 2] → [expected result].
- Use stable selectors (roles/test-ids), not brittle text or CSS.
- Cover the success path and one failure path.
- Run it headless, and show me the result and the new file's diff.

Constraints: add the test under [e2e/path]; don't change app code to make it pass — if the app is broken, report it; don't touch unrelated files.

MODE: Ask

Act as a staff engineer and review my current changes. Don't edit anything.

What this change is meant to do: [intent].
Context: @Git @Recent Changes @Codebase

Do this:
- List issues most severe first: correctness, security, edge cases, then style.
- For each, give the exact file and line and a concrete fix.
- Call out what I got right so I keep doing it.
- Point to specific lines — don't rewrite whole files.

Constraints: read-only review in Ask mode; base it on the actual diff, not assumptions; end with the 3 changes that matter most before I merge.

MODE: Ask

Review this change for security issues only. Don't edit anything.

Context: it [handles user input / touches auth / calls external APIs].
Context slots: @Git @Files [path/to/sensitive/file] @Recent Changes

Do this:
- Flag injection, auth/authorization gaps, unsafe deserialization, secrets in code, and SSRF/XSS/CSRF where relevant.
- Rate each finding high/medium/low with the attack it enables and the file:line.
- Give the fix for each.
- Note anything you can't judge without seeing more of the system.

Constraints: read-only, security-only scope in Ask mode; base findings on the real diff; don't report style nits.

MODE: Agent

Write documentation for this [module / API / project].

Audience: [teammates / external users / future me].
Context: @Files [path/to/code] @Folders [path/to/module] @Codebase

Do this:
- A short "what and why" overview.
- Usage examples that actually run, taken from the real code.
- Parameters, return values, and errors in a table.
- Gotchas and assumptions a newcomer would trip on.
- Write it to [docs/path or README.md] and show me the diff.

Constraints: match the tone of docs a good open-source project ships; don't invent APIs that aren't in the code; don't touch source files.

Save this as .cursor/rules/[name].mdc so Cursor injects it into every Ask/Agent run.

---
description: [when this rule applies, e.g. "frontend components in src/"]
globs: [src/**/*.tsx]
alwaysApply: false
---

# Project rules for [area]

Stack: [framework + version], [language], [styling], [test runner].

Conventions:
- Follow the patterns in @[path/to/canonical/example].
- Use [naming / folder] conventions; put new files in [dir].
- Prefer [preferred lib/util] over [thing to avoid].

Guardrails for the Agent:
- Don't touch unrelated files; keep changes scoped to the task.
- Write and run tests for new behavior; done means [test command] passes.
- Show the per-file diff before large edits.
- If an API or requirement is unclear, ask instead of guessing.

MODE: Agent

Before we change anything, get your bearings in this repo. Don't edit files yet.

Context: @Codebase @Folders [repo root or main src dir] @Files [package.json / config]

Do this:
- Map the project: languages, frameworks, entry points, and how it's built and tested.
- Summarize the architecture in a short paragraph plus a bullet list of the main modules.
- Tell me the exact commands to build, run, lint, and test.
- List anything unusual or fragile I should know before we make changes.
- Suggest what belongs in a .cursor/rules file for this repo.

Constraints: read-only reconnaissance — don't edit or run destructive commands; just report back so our next prompts are well-informed.