All field notes

Prompts · 4 min read ·

AI coding prompts with a clear finish line

Six copy-paste prompt templates for coding agents, each ending in a check the agent can run: bug fix, feature, refactor, UI change, review and investigation.

What makes a coding prompt work?

A finish line the agent can test. Anthropic’s best practices put it clearly: Claude stops when the work looks done, and without a check it can run, “looks done” is the only signal available. You become the verification loop, and every mistake waits for you to find it.

OpenAI’s docs for long-running work ask for the same three things: the outcome, the constraints and the verification, meaning the tests, measurements or review criteria that prove the work is done. Its prompting guide lists goal, context, output and boundaries, including what must stay unchanged.

Two vendors, one idea. If you want the longer argument, read give every agent a job you can verify.

What is a simple frame you can reuse?

Four lines: outcome, boundaries, check, evidence.

Outcome says what should be different when the agent is done. Boundaries say what must not change. The check is the command that proves it worked, such as npm test. The evidence is what the agent pastes back, so you can read the result instead of trusting a summary. Anthropic’s guidance says to have Claude show evidence rather than assert success.

Everything below is that frame applied to six common jobs. Replace the file names and commands with yours.

Template 1: fix a bug

“Bug: clicking Save on the settings page shows Saved, but the change is lost after a refresh. Repro: run npm run dev, open /settings, toggle alerts, click Save, refresh. Write a failing test that reproduces it, then fix the cause, not the symptom. Do not change the API shape. Done when npm test passes and the new test failed before your fix. Paste the command output.”

This follows examples in both vendors’ docs: give a reproduction, ask for a failing test first, and ask for the root cause. Anthropic’s example for a failing build says to fix it and verify the build succeeds, addressing the root cause rather than suppressing the error.

Template 2: add a small feature

“Add a Duplicate project button to the project menu. Follow the pattern of the existing Archive action. Copy the name and settings, not the members. Add tests for the new action. Do not add dependencies. Done when npm run check passes. List every file you changed.”

Pointing at an existing pattern is one of Anthropic’s listed tactics, and it keeps the new code consistent with the old. The “list every file” line gives you a quick way to spot changes you did not ask for.

Template 3: refactor without changing behavior

“Extract the date formatting in src/invoices/ into one helper. Behavior must not change. Do not edit any existing test. Run npm test before you start and after you finish, and paste both results. Done when the two results match.”

A refactor has no new behavior to test, so the finish line is sameness. Running the suite before and after turns “I think nothing changed” into a comparison.

Template 4: change the UI

“[paste a screenshot] The card title overflows on narrow screens. Fix it in Card.tsx only. Check the page at 360, 768 and 1280 pixels wide and describe what you see at each. Run npm run lint and show the output.”

Anthropic’s examples for visual work include pasting a screenshot and asking the agent to compare its result with the original. A passing test suite cannot tell you the layout is right, so the check here is a look at the result at several sizes.

Template 5: review before merging

“Review the changes on this branch against main. Do not edit any files. List problems in order of risk, with the file and line. For each change, say which test covers it, and name the changes that have no test.”

A read-only review keeps the reviewer from fixing things quietly, which would hide what it found. The question about tests turns the review into a coverage check.

Template 6: investigate without editing

“Do not write any code. Find out why the nightly export sometimes returns an empty file. List the three most likely causes, the evidence for each, and how I could confirm each one.”

Cursor’s CLI docs note that a prompt such as “do not write any code” is generally helpful when planning before implementing. The finish line is a list of causes with evidence, which you can check yourself.

When should you ask for a plan first?

When the change touches several files, when you are unsure of the approach, or when you do not know the code. Anthropic’s best practices recommend separating exploration and planning from coding in those cases. They add a counterweight worth remembering: if you could describe the diff in one sentence, skip the plan. A typo fix does not need a proposal.

A good planning prompt uses the same frame. Ask for the files that will change, the tests that will cover them and the risks, and say that nothing should be edited yet.

What if the agent says it is done and the check fails?

Paste the failing output into the conversation. Do not summarize it, because the details are what the agent needs. Ask for the root cause, and for why the first attempt missed it.

If two rounds do not fix it, the task is probably too big. Restate it smaller, or split it, and start from a clean checkpoint.

Save the good ones

SwarmPane’s Skills are reusable instructions, included whenever you assign the skill to a teammate. A template that works for your project is a good first skill: write it once, and assign it to the teammates that need it.

SwarmPane runs the agent CLIs and accounts you already have. Start with a 7-day trial for $1 and keep your best prompts where your agents work.