10 Prompts That Make Cursor and Copilot Do the Heavy Lifting

Cursor and Copilot have evolved significantly since 2024, with both tools now supporting agent mode, Model Context Protocol, and persistent project-level instructions. A developer demonstrated that writing a `.cursor/rules` or `copilot-instructions.md` file serves as a permanent system prompt for every AI interaction, eliminating the need to re-explain conventions each session. The developer also shared updated prompts for 2026, including one that instructs the AI to review and fix staged code changes by running type checks and linters automatically.

Here's something that hasn't changed since 2024: the AI editor is only as good as what you ask it. What has changed is that both Cursor and Copilot are completely different products now. Cursor v3.0 shipped Background Agents, Cloud Agents, and a redesigned Composer 2.0. Copilot got agent mode across VS Code and JetBrains, a full coding agent that turns GitHub Issues into pull requests, and MCP support baked in. Both now support Model Context Protocol, which means your editor can reach directly into your Linear board, your Postgres database, your Sentry errors, your Figma designs. The prompts that worked in 2024 still work. But there are new patterns that weren't possible before — and some old advice that's been quietly superseded by how agents actually behave now. This is the updated list for 2026. In 2026, the highest-leverage thing you can do before typing a single prompt is write a proper .cursor/rules file the modern replacement for .cursorrules or Copilot's copilot-instructions.md . This is a plain text file that sits in your repo and acts as a persistent system prompt for every AI interaction in that project. Every agent turn, every Composer session, every inline suggestion — your rules are always loaded. Without it, you re-explain your conventions every single session. With it, you explain them once. .cursor/rules/backend.md applies to: src/api/ , src/services/ Stack TypeScript strict mode. Node 22. Fastify, not Express. Prisma ORM — use the existing client from src/db/prisma.ts, never instantiate a new one. Conventions - Function names: camelCase. Files: kebab-case. Types: PascalCase. - All async functions return Result, never throw. - No any . No unhandled promise rejections. - Every new public function needs a JSDoc comment with @param and @returns. Testing Jest + Supertest. Tests live in tests / mirroring src/ structure. Always test happy path, null/empty inputs, and one error case minimum. What NOT to do - Never log sensitive fields email, password, token, card numbers . - Never commit .env changes. - Never modify the Prisma schema without a migration file. That file is loaded silently into every agent context. The AI stops violating your conventions not because you reminded it — but because it literally cannot forget them. Now, the prompts. The old version of this prompt asked the AI to review your code. The 2026 version asks it to review and fix — using agent mode's ability to actually open files, run the linter, check types, and propose changes rather than just listing problems. Review the changes in @git:staged as a senior engineer doing a PR review. For each issue you find: 1. State the file and line number 2. Explain what's wrong and why it matters 3. Write the corrected code inline After listing all issues, run npm run typecheck and npm run lint . Fix anything that fails. Show me a summary of what you changed. The @git:staged reference pulls your staged diff directly into context — no copy-pasting. The instruction to actually run the checks turns a list of suggestions into a verify-fix loop. What you get vs. the old approach: Old: A list of observations. You fix them manually. New: Issues found: 1. src/api/orders.ts:47 — userId accessed without null check. The getUser call on line 43 can return null on cache miss. Fixed: const user = await getUser userId ; if user return reply.status 404 .send { error: 'User not found' } ; 2. src/services/inventory.ts:112 — O n² loop. Fetching product inside the order loop. Moved query outside. Running typecheck... ✓ no errors Running lint... 1 warning: unused variable tempResult line 89 Fixed: removed unused variable. Summary: 2 logic fixes, 1 lint cleanup. 3 files changed. Most developers know they should have a rules file. Most never write one because staring at a blank file is tedious. This prompt generates a solid starting point from your existing codebase. Look at @src/ and @ tests / and generate a .cursor/rules/project.md file for this codebase. Infer and document: - The tech stack languages, frameworks, libraries and their versions from package.json - Naming conventions actually used in the code not ideal, actual - Error handling patterns used consistently - Test structure and what gets tested - Any patterns that appear in 3+ places these are de facto conventions - A "never do this" section based on anti-patterns you spot Format it as rules an AI agent should follow, not as a description. Run this once when you start a project — or when you join one. The AI reads the existing code, extracts the real patterns not the ones in the README that nobody follows , and produces a rules file you can refine. The 20 minutes you spend reviewing and editing the output will pay back every day you work on that codebase. This one didn't exist before 2025. Now that both Cursor and Copilot support MCP servers, you can pull live context from your actual infrastructure directly into the AI's working memory. If you have the Postgres MCP server or Linear MCP server connected: @linear:issue-ENG-847 The bug described in this ticket is happening in our production payments service. @sentry:recent-errors service:payments last:24h Look at @src/services/payments/ and find the root cause. Don't write any code yet — explain what's wrong and what the fix should be, referencing the actual error stack from Sentry and the schema from the DB. What this does: the AI reads the Linear ticket to understand the reported behaviour, pulls the actual Sentry stack traces from the last 24 hours, queries the live database schema to understand the data model, and reads your source code — all in one context. No copy-pasting, no screenshot-taking, no "let me find the error in the dashboard." Before MCP, you assembled this context manually. Now you ask the AI to read it directly. The quality of the diagnosis is genuinely different when the AI has the real error trace and the real schema rather than your paraphrase of them. Cursor's Background Agents run in cloud sandboxes while you do other work. You fire one off, go review a PR or attend a meeting, and come back to a finished task with a diff ready to review. Copilot's Coding Agent does the same via GitHub Issues. The prompt pattern that works for both is: brief it like you'd brief a junior developer who's going to work unsupervised. Task: Add pagination to the GET /api/orders endpoint. Context: - Current endpoint is in @src/api/orders.ts - We use cursor-based pagination elsewhere — see @src/api/users.ts for the pattern - The Order model is in @src/db/schema.prisma - Tests live in @ tests /api/orders.spec.ts Done means: - Endpoint accepts cursor and limit query params limit default 20, max 100 - Returns { data: Order , nextCursor: string | null } - At least these test cases pass: first page, second page, last page nextCursor null , limit=0 rejected - TypeScript strict mode passes - No changes to existing endpoint response shape for requests without pagination params Do NOT: - Change the authentication middleware - Modify any other endpoints - Add any new dependencies The Done means: section is the part most people skip. Without it, the agent decides what "done" looks like — and its definition and yours will differ. Write your acceptance criteria explicitly and the agent works toward them rather than toward its own interpretation. Nothing has changed here except that you can now ask the agent to actually test the failure modes it identifies, not just list them. You are adversarial QA. Your job is to break @src/services/rateLimit.ts. First, list every way this code can: - Return a wrong result allow when it should block, or block when it should allow - Crash or throw unexpectedly - Fail silently - Behave differently under concurrent requests - Create a security vulnerability Then write test cases for the three most severe issues you found. Run them. If they pass meaning the bug exists and is caught by the test , report what you found. If they fail meaning the code handles it , mark that issue as already handled. The last part — actually running the tests — is what separates this from a 2024-style prompt. In 2024, the AI gave you a list and you wrote the tests yourself. Now the agent writes and runs them, so you find out immediately which issues are real and which are already handled. This is specific to Copilot's asynchronous coding agent — the one that works through GitHub Issues rather than inside your editor. If you're on a team using GitHub, this workflow will save you hours per week on well-defined implementation tasks. Assign a GitHub issue to Copilot with a description like this: Implement email verification for new user signups. Acceptance criteria: - After registration, user receives a verification email with a time-limited token 24h - GET /api/auth/verify?token= verifies the token and marks the user as verified - Unverified users can log in but see a banner; they cannot access /api/orders or /api/payments - Verified status is stored on the User model migration required - Token is invalidated after use Patterns to follow: - Email sending: see how password reset emails work in src/services/auth/passwordReset.ts - Token generation: use the existing crypto utility in src/utils/tokens.ts - Middleware pattern: see src/middleware/requiresVerified.ts if it exists, or create it following requiresAuth.ts Tests required: registration flow, valid token verification, expired token, already-used token, unverified user hitting restricted endpoint. You file this. Copilot reads the issue, finds the referenced files, implements the feature, runs the tests, and opens a PR — while you work on something else. The PR comes back with a diff, test results, and a description of what it did. You review it like you would any PR from a developer. The key is specificity. Vague issues produce vague PRs. Specific issues with clear acceptance criteria and references to existing patterns produce PRs that need minimal revision. This is the one developers wish they'd had before onboarding a new team member and having to explain the same patterns seventeen times. Use it when code review keeps flagging the same issues. Look at these recent PR review comments: paste 5-10 recurring comments And look at @src/ to understand the codebase patterns. Do two things: 1. Write .cursor/rules entries that would have prevented each of these issues 2. Scan @src/ for existing violations of these patterns and list them don't fix them yet — just find them Real example input — recurring PR comments: "Use the Result type, don't throw" "Logs are missing the requestId field" "Why is this query inside the loop?" "This needs a test for the null case" "Don't import directly from @prisma/client, use our wrapper" What comes back: .cursor/rules additions: Error handling - NEVER use throw for expected errors. Use Result from src/types/result.ts - NEVER catch and re-throw without adding context. Use Result.mapErr to annotate. Logging - Every log.info/warn/error call MUST include requestId from the request context. Pattern: log.info { requestId: ctx.requestId, ...data }, 'message' Database - NEVER execute a database query inside a loop. Batch queries using Prisma's findMany with in operator. Testing - ALWAYS include a test case for null/undefined inputs on public functions. Imports - NEVER import from '@prisma/client' directly. Use the typed client from src/db/client.ts --- Existing violations found: - src/services/checkout.ts:89 — query inside loop 3 occurrences - src/api/webhooks.ts:34 — throws instead of Result - src/utils/email.ts:12 — direct @prisma/client import ...8 more Now you have rules that prevent future violations, and a list of existing debt to clean up. The PR comments stop repeating. Nothing about this has changed because it's based on a truth that hasn't changed: you cannot write good tests for code that already exists, because you're reverse-engineering intent from implementation rather than forward-engineering implementation from intent. The updated version adds MCP context when relevant: js I need to implement: user-facing webhook configuration let users register URLs to receive order events . @linear:issue-ENG-912 has the full requirements. Check @src/api/ for existing endpoint patterns. Check @src/services/webhooks.ts if it exists. Don't write any implementation yet. Write a complete test suite for this feature covering: - Happy path webhook registered, event fires, URL receives POST - Duplicate URL registration should update, not create a second - Invalid URL format should reject at validation - Webhook delivery failure should retry 3 times with exponential backoff - Delivery after retry exhaustion should mark as failed, not keep retrying - User can list their webhooks - User can delete a webhook Use the test patterns from @ tests /api/orders.spec.ts. Once I approve the tests, implement the feature to pass them. The ritual matters. Reading the tests you get back forces you to check your own requirements. You'll catch ambiguities — "wait, what should happen if they register the same URL twice?" — before they're baked into the implementation. New prompt for 2026. When you're dropped into an unfamiliar codebase — a new job, a client project, an open-source contribution — this gets you oriented in under five minutes instead of spending a day reading files. I'm new to this codebase. Give me an architectural orientation by reading: @src/ @package.json @README.md Tell me: 1. What does this application actually do? one paragraph, plain English 2. What's the folder structure and what lives where? 3. What's the request lifecycle? a user hits an endpoint — what happens, in order, from network to database and back 4. Where are the 3 most complex parts of the codebase? files/modules I should understand before touching anything 5. What are the patterns I'll need to follow? error handling, auth, DB access, testing 6. What are the landmines? deprecated patterns still in use, known rough edges, things that look wrong but aren't The last question is the one that saves you. Every codebase has things that look wrong but exist for a reason — a weird workaround for a third-party bug, a performance optimisation that looks like dead code, a "temporary" flag that's been in production for three years and is load-bearing. Ask the AI to find them before you accidentally remove them. This is genuinely new behaviour in 2026 that wasn't possible before Background Agents existed. You can now run multiple agent tasks simultaneously, the same way you'd assign work to multiple developers in parallel. I need to build out the notifications module. Start three background agents in parallel: Agent 1 — Database layer: Create the Notification model in @prisma/schema.prisma with a migration. Build the NotificationRepository following the pattern in @src/db/userRepository.ts. Done when: migration runs cleanly, repository has CRUD methods, unit tests pass. Agent 2 — Service layer: Build NotificationService in @src/services/notifications.ts. It should queue outbound notifications, handle channel routing email/SMS/push , and implement retry logic. Use @src/services/email.ts and @src/services/sms.ts for the actual sending. Done when: service unit tests pass with mocked channels. Agent 3 — API layer: Build GET/POST/DELETE /api/notifications endpoints. Follow the patterns in @src/api/orders.ts. Done when: integration tests pass and TypeScript is clean. After all three complete, I'll review the diffs together and handle any interface mismatches. A few things to keep in mind with parallel agents: give each agent a clear scope boundary so they don't step on each other's files, define "done" explicitly for each one so they don't sprawl, and do your integration review after all three finish rather than trying to steer them while they're running. Read back through these prompts. Every effective one shares the same structure: Context — what the AI should read before doing anything @mentions , @git , @linear , @sentry Constraint — what scope it should stay within and what it should not touch Acceptance criteria — what "done" actually means, stated explicitly Verification — run tests/typecheck/lint after the change, not just before The agents will work toward whatever definition of "done" they have. If you don't give them one, they'll make one up — and it won't match yours. Give them your definition, stated clearly, and they'll generally hit it. That's still the whole game. It just plays at a much higher level now. Originally published on ZyVOP