Prompt Templates for AI Coding Agents

The working pattern for coding agent prompt templates is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Yes. The frame below is a starting point, not a script. 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.

The Boundary line is the one people leave out, and probably the one doing the most work. Without it every file the agent can reach is fair game, so you end up reviewing incidental edits to config and imports and some helper you'd forgotten existed, all mixed in with the change you actually wanted. Naming what not to touch takes a few seconds. Reverting it afterwards does not.

"Done when" has to name something you can run. A test name, a typecheck, a command whose output you can read, a screenshot of one specific state. "Done when the bug is fixed" doesn't count, and I'd say that's the single most common version of this mistake, because it quietly hands the judgment back to the agent, and the agent is going to tell you it's finished either way.

Running coding agent prompt templates as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

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.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains 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.

Don't just ask is this vulnerable? Tell the model to find the issue, then prove it. Frontier models like Opus 4.x are very good at security reasoning when you give them that guidance, and they do an even better job when you ask for a proof of concept and the full chain. Use 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. A template becomes a folder under .cursor/skills/ holding a SKILL.md, and committing it gives everyone the same entry in their slash menu. A template that lives in a wiki page gets retyped from memory instead, so before long each person is carrying a slightly different version of it and nobody can say which one is current. (The older home was a Markdown file under .cursor/commands/; those still load, but Cursor has retired the format and ships a /migrate-to-skills converter for a reason.)

One decision carries over from the command era: who fires the thing. A skill can be pulled in by the agent when it judges the description relevant, or restricted to human invocation with disable-model-invocation: true in its frontmatter. For prompt templates the restricted form is probably right, since a template exists because a person decided this was the job worth repeating.

The best moment to write one is the end of a session that went well. Not the start of the next one, when it is already half-forgotten.

Name the output you want. Cursor's field guidance on slash workflows calls the response instruction the most-skipped step, and closing a template with something like "report the failing test and your fix", or "reply with only the PR link", is what keeps the result scannable rather than something you read twice to find the answer in.

I filed that under cosmetic for a long time. Wrong call, and the reason is review rather than tidiness. On a shared template the person reading the output usually was not watching the run, so the report line is the only thing standing between them and reconstructing what happened from the diff.

They grow. Somebody hits a bad result, adds a line to prevent it, and repeats that for a month until the frame that fitted on one screen is a page of instructions people skim past on their way to the box where they type the actual task.

So the rule guidance transfers here almost unchanged. Build reactively rather than preventively, and add a directive only after the model has made the same mistake more than a few times. The just-in-case lines are the ones doing the damage, and they are also the hardest to argue against, because each one looked reasonable on the day it went in.

And if a line belongs in every prompt, it was never template material. Put it in a rule scoped to the files it applies to, so it costs you nothing on the work it has no opinion about.