Skip to content
CodeAndBuild LogoCodeAndBuild

AI Coding

12 Cursor Prompts That Save Developers Hours Every Week

Copy-ready prompts for Cursor and other AI coding agents: explain a repo, fix a failing test, review a diff, write a migration, and more.

CodeAndBuild Team10 min read
  • Cursor
  • AI Coding
  • Prompts
  • Productivity
On this page
  1. Understand code faster
  2. Fix and change code safely
  3. Build new pieces
  4. Review and ship
  5. One prompt, start to finish
  6. Habits that make every prompt better

An AI coding agent is only as good as the job description you give it. "Fix this" gets a guess. A prompt that names the goal, the files, the constraint, and the way to check the result gets work you can merge. These twelve prompts are the ones worth keeping in a snippet file. Each one has three parts: what to do, what to read first, and when to stop. Paste them into Cursor, Claude Code, or any agent that can read your repo.

Understand code faster

1-explain-repo.txttext
Explain this repository to a new developer. Read package.json, the top-level folders, and the main entry points first. Give me: what the app does, how a request flows from the route to the data, where config and secrets are read, and the three files I should read first. Do not change any files.
2-trace-feature.txttext
Trace how [feature, e.g. the contact form] works end to end. List every file involved in order, with one sentence each about its role. Point out anything that looks unused or duplicated. Do not edit code.
3-explain-error.txttext
Here is an error and its stack trace: [paste]. Find the line in this repo where it starts, explain the cause in plain words, and propose the smallest fix. Show the fix as a diff but do not apply it yet.

Fix and change code safely

4-failing-test.txttext
The test [name] is failing. Run it, read the failure, and fix the code under test, not the test, unless the test is clearly wrong. Explain which one you changed and why. Run the test again and stop when it passes.
5-small-change.txttext
Make this change: [describe]. Touch as few files as possible. Match the existing style and naming. Do not add new dependencies. When done, run the typecheck and show me the diff.
6-refactor.txttext
Refactor [file or function] so it is easier to read, without changing behavior. Keep the public API the same. List the behavior you preserved, and run the existing tests before and after.

Build new pieces

7-new-component.txttext
Create a [component] that [does X]. Look at two existing components in components/ first and follow their structure, styling, and prop naming. Make it accessible: labels, keyboard support, and focus states. Use it on [page] so I can see it.
8-api-route.txttext
Add an API route at [path] that [does X]. Validate the input, return clear JSON errors with the right status codes, and read secrets from process.env on the server only. Never put a key in client code. Add a short example request I can run with curl.
9-migration.txttext
Write a database migration that [adds X]. Make it safe to run on a table that already has data: no locks on large tables, a default for new non-null columns, and a matching down migration. Explain any risk before writing it.

Review and ship

10-review-diff.txttext
Review my uncommitted changes like a senior engineer. Look for bugs, security problems, missing error handling, and missing tests. Ignore style nitpicks. Rank findings by severity and quote the exact lines.
11-write-tests.txttext
Write tests for [function]. Cover the normal case, edge cases (empty, null, very large), and one failure case. Use the test framework already in this repo. Run them and fix only the tests if they fail for setup reasons.
12-commit-message.txttext
Write a commit message for the staged changes. Subject line under 60 characters in the imperative mood. Add a short body only if the reason is not obvious from the diff.

One prompt, start to finish

Here is prompt 4 on a real bug. A contact form test fails because the API returns 500 when the subject is empty. The weak version of the request is "tests are broken, fix them." The agent might delete the assertion, loosen the test, or rewrite the whole route. The strong version names the test, says the code is the suspect, and gives a stopping rule.

real-example.txttext
The test "rejects an empty subject" in tests/contact.test.ts is failing with a 500. Read app/api/contact/route.ts and the test. Fix the route so an empty subject returns 400 with a JSON error, without changing the test. Run that test and stop when it passes. Show me the diff.

With that prompt, the agent reads two files, adds one validation check, runs one test, and shows a five-line diff. You review it in thirty seconds. That is the whole point: a precise prompt makes the result small enough to trust.

Habits that make every prompt better

  • Name files. "Look at app/api/contact/route.ts" saves the agent from guessing and from editing the wrong copy.
  • Say what not to do. No new dependencies, no changes outside this folder, no public environment variables for secrets.
  • Ask for a plan on big jobs. "Give me a plan first, then wait" lets you correct the direction before 20 files change.
  • Keep project rules in the repo. Conventions you repeat in every prompt belong in a rules file. See Cursor rules for Next.js.
  • Read the diff. The agent is fast. You are the reviewer. A minute reading the diff saves an hour debugging production.

Save these twelve as snippets and adjust the brackets for each task. After a week, you will notice which ones you use daily. Turn those into project skills so the agent follows the same steps without you pasting them.

Found this useful? Send it to someone building the same thing.

Sharing is the main way new readers find CodeAndBuild. One click posts this guide with its cover image.