Prompt Templates for AI Coding Agents

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.

Don't stop at asking is this vulnerable? Tell the model to find the issue, then prove it. In Cursor's security workshop, the presenter said Opus 4.5 reasons well about security when you give it that guidance, and does better still when you ask for a proof of concept and the full exploit chain. Treat the model as a thought partner, never as the final word.

Review <files/diff> for security issues.
For each issue you find, run a validation loop:
  1. Generate a proof of concept that triggers it.
  2. Explain the entire exploit chain end-to-end.
  3. Rate exploitability and the minimal fix.
Do not assume a finding is real because the model flagged it. Prove it.

In the repo, as a skill. Each template becomes a folder under .cursor/skills/ holding a SKILL.md, and once you commit it, everyone gets the same entry in their slash menu. A template kept on a wiki page gets retyped from memory instead. Before long, each person has a slightly different version, and nobody can say which one is current.

The older home was a Markdown file under .cursor/commands/. Those files still load, but Cursor's docs now point command users to the built-in /migrate-to-skills skill, which converts commands into skills.

One decision carries over from commands: who fires the template. The agent can pull a skill in when it judges the description relevant, or you can limit the skill to human invocation with disable-model-invocation: true in its frontmatter. For prompt templates, the limited form is usually the better fit, because a person decided this job was worth repeating.

Write a template at the end of a session that went well, while you still remember which instructions made the difference.

Name the output you want. A Cursor field engineer recommends ending a slash command with an instruction on how the agent should respond, to cut long replies. Close a template with a line such as "report the failing test and your fix" or "reply with only the PR link", so nobody has to read the result twice to find the answer.

On a shared template, the report line also matters for review. The person reading the output may not have watched the run, and without a report line they have to reconstruct what happened from the diff.

They grow. Someone hits a bad result and adds a line to prevent it. After a month of that, a frame that fit on one screen has become a page of instructions. People skim past it on their way to the box where they type the task.

Cursor's advice for rules applies here almost unchanged: add a line only when you notice the agent making the same mistake repeatedly. The just-in-case lines do the damage, and they are the hardest to argue against, because each one looked reasonable on the day it went in.

If a line belongs in every prompt, it belongs in a rule. Scope that rule to the files it applies to, and it only enters the context when one of those files does.