Prompting for code

Turning a task into something a tool can do well: small steps, a clear spec with a definition of done, a plan before code, reusable prompts and a fresh context for each task.

Small, checkable tasks

Also called task decomposition, one change at a time

What: Breaking work into steps small enough that you can describe the change in a sentence or two and check it in a few minutes, then giving the tool one step at a time.
Why: Small tasks fail small. When something goes wrong you know which step caused it, and each diff is short enough to actually read.
Example: Instead of "add user accounts", ask for the users table migration first, then the sign-up endpoint with tests, then the login endpoint, reviewing each one.

Watch out

Chaining ten steps in one prompt and then trying to review one enormous diff.

A task spec

Also called prompt spec, requirements, definition of done

What: A short, structured prompt: the goal, the files involved, the constraints and what is out of scope, and how to prove it is done.
Why: Vague prompts get the tool's guess at what you meant. A spec gets your intent, and the "done when" line gives both of you the same check.

Code

Goal: add rate limiting to POST /api/login.
Files: src/api/login.ts, src/lib/rate-limit.ts
Constraints: reuse the Redis client in src/lib/redis.ts;
  no new dependencies; keep the response shape.
Out of scope: other endpoints.
Done when: 6th attempt in 1 minute from one IP gets 429,
  new tests pass, npm test and npx tsc --noEmit pass.

Watch out

Leaving out the non-goals, so the tool "helpfully" refactors code you did not ask it to touch.

Pointing at an existing pattern

Also called few-shot, reference implementation

What: Naming a file in your codebase that already does something similar well and asking the tool to follow it.
Why: Your project's own patterns beat the model's generic habits. New code that looks like the old code is easier for everyone to review and maintain.
Example: "Add a PaymentsService following the structure and error handling of src/services/orders.ts."

Plan before code

Also called plan mode, Plan agent, design first

What: Asking the tool to read the code and propose a plan, the files to change and the approach, without editing anything, then correcting the plan before any code is written.
Why: Fixing a wrong plan takes a minute; fixing wrong code across eight files takes an hour. Planning is worth it whenever a change touches several files or you are unsure of the approach.

Code

/plan add OAuth login   # VS Code chat
# or choose the Plan agent in the agent picker
Shift+Tab        # Copilot CLI: cycle to plan mode

Watch out

Planning a one-line fix: if you can describe the diff in one sentence, skip the plan.

Prompt templates for common tasks

What: Reusable shapes for the prompts you write every week: explain, fix a bug, add a feature and refactor, each ending with how to verify.
Why: A template makes you include the context and the check every time, which is most of what separates good results from bad ones.

Code

EXPLAIN: Explain how @file works. Ask me 3 questions
  after to check I understood. Do not change code.
BUG: Symptom: ... Expected: ... Repro: ... Write a
  failing test first, then fix the cause, not the symptom.
FEATURE: Goal ... Files ... Constraints ... Done when ...
REFACTOR: Restructure X without changing behaviour.
  All existing tests must pass unchanged.

Saved prompts and skills

Also called skills, slash commands, prompt files, custom commands

What: Prompts saved as files in the repository and run by name with a slash, so a team shares the same review checklist, test workflow or release steps.
Why: Good prompts are worth keeping. Saving them turns a clever one-off into a repeatable team habit.

Code

# .github/prompts/review-pr.prompt.md
---
description: Review a diff with our checklist
---
Run it in chat with: /review-pr
/create-prompt   # let the agent draft one

Watch out

Saving a prompt that only worked once. Keep it only after it has worked on several tasks.

Fresh context per task

Also called /clear, /compact, new chat, context rot

What: Starting a new conversation for each unrelated task, and compacting or summarising a long one, so old detail does not confuse new work.
Why: Quality drops as the context fills with failed attempts. After two failed corrections, a fresh start with a better prompt usually wins.

Code

/clear      # new chat
/compact    # compact the conversation
Cmd/Ctrl+N  # new chat in VS Code

Watch out

Correcting the same mistake over and over in one long chat instead of starting again with what you learned.

Go deeper