Prompt Engineering for Developers

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

Yes. Treat the frame below as a starting point. Fill in your own files, constraints and done state, and keep the plan step, so the agent commits to an approach before it writes code.

Task: [one outcome]
Context: [files, errors, docs and examples]
Boundary: [what not to touch]
Done when: [test, typecheck, screenshot or review proof]

Before editing, write a short plan with files, risk and checks.

Fill the Context line with things the agent can open: file paths, the exact error text and the doc or example to follow. Paste errors instead of paraphrasing them, because a paraphrase drops the detail the agent needs to trace the cause.

The Boundary line is easy to leave out, and in our view it does the most work. Without it, every file the agent can reach is fair game. You end up reviewing incidental edits to config, imports and helpers you had forgotten about, mixed in with the change you wanted. Naming what not to touch takes a few seconds, and reverting stray edits afterwards takes far longer.

"Done when" has to name something you can run or look at: a test name, a typecheck, a command whose output you can read, or a screenshot of one specific state. "Done when the bug is fixed" doesn't count. It hands the judgment back to the agent, and the agent will report that the work is finished either way.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

Attach what the agent would otherwise have to find. Typing @ in the chat input pulls in files and folders, terminal output, an earlier chat through @Chats, git diffs and the built-in browser. You can use it as many times as one prompt needs. Each file you name is one the agent does not have to locate by grepping and guessing.

Skipping that step has a price. A vague prompt on an expensive model makes the agent spend tokens exploring to recover the scope you left out, so you pay more for worse output. When you know a file's name, mention it with @ instead of describing it.

More context has a cost too, and Cursor shows you where it goes. Click the context ring next to the prompt input to see the tokens split by category, from the system prompt, rules and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers to the conversation itself. Since the June 2026 canvas update, the agent can also lay out that breakdown as an interactive report in a canvas, with a Debug with Agent button that starts a new conversation about reducing context usage. Ask for the report when the agent feels slow, expensive or distracted.

So aim for precision over volume: the files the change touches, plus any error text you would otherwise paraphrase.

Anything you would otherwise retype. Rules are persistent instructions stored as .mdc files under .cursor/rules/. Your stack conventions and the patterns you always want followed belong there, and the prompt carries what is true only of today's task.

Not every instruction belongs in a rule. Short, scoped, specific rules work, and vague or bloated ones get ignored without any warning. The agent does not report that it skipped your style guide, so you only see output that reads as if you never wrote one.

One test helps: would the sentence still be true next month, on a different task, in a different file? If so, it is a rule. If it only makes sense for this ticket, it stays in the prompt. A draft rule that needs the word "usually" holds for some tasks only, so put it in the prompts for those tasks.

The direct measure needs Enterprise. Conversation InsightsA Cursor analytics view that passively categorises what agents are doing (new features, bug fixes, refactors) so leaders can see where engineering time goes. Press Enter for the full definition. is on by default there and classifies agent sessions on-device into work categories such as bug fixing, new features and refactoring. It also rates Specificity, meaning how specific the prompts developers give agents are, so it measures prompt quality as well as activity.

Without it, watch the agent's first move. If it opens four files you never mentioned before it touches anything, that usually means the prompt did not say where the change lives. Then watch your own habits, especially a clarification sent right after a prompt. You usually knew that detail before you pressed Enter, and the second turn is the expensive place to add it, because the agent has already started on the first version.