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

Shift+Tab        # rotate to Plan mode
Cmd/Ctrl+.       # open the mode menu
agent --plan     # CLI, same as --mode=plan
/ask             # CLI read-only Ask 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

# Skills show in the / menu in Agent.
# Option+Enter (Mac) or Alt+Enter (Windows)
# on a skill uses it as a Custom Mode that stays
# active on every turn.

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

Cmd/Ctrl+N   # new chat
# Click the context ring by the input to see
# what fills the window. /btw opens a side chat.

Watch out

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

Go deeper