Tech & AI, Explained

prompt-patterns-for-dev

8 min read

Prompt patterns for dev

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: Reusable prompt structures for common dev tasks. Don’t write each prompt from scratch — start from a pattern that’s known to work.

In plain English

Some prompts work better than others for the same task. Over time, you discover patterns: ways of phrasing that consistently produce good output. This entry catalogs the ones that work in dev/code/AI-assisted contexts.

Each pattern is a template. You fill in the specifics; the structure stays the same. Save the ones you use most often as slash commands (Slash commands) so you don’t even have to remember them.

Why it matters

The difference between a vague prompt and a structured prompt is the difference between an okay output and a great one. Patterns aren’t about being clever — they’re about reusing what works, so the model can focus on the task instead of guessing at your intent.

Save the patterns; reuse them; tweak them. Over months, a small library of go-to prompts saves significant time and improves output quality.

Pattern 1: “Plan before doing”

For any non-trivial change. Forces the model to think first.

Before making any changes, walk me through your plan:

1. Files you'll touch
2. New files you'll create
3. Order of operations
4. Tests you'll run to verify
5. Any trade-offs or alternatives you considered

Wait for me to approve before writing anything.

Saves: at least one wrong-direction execution per non-trivial task.

Pattern 2: “Define done”

Removes “I think it’s done” ambiguity.

This task is complete when:
- All existing tests pass
- The new behavior works in the dev server (verify by running and clicking)
- The diff contains no `console.log` or `TODO` statements
- The PR description summarizes the change in one sentence

Confirm each criterion before claiming done.

Saves: half-done deliveries.

Pattern 3: “Show your work”

Forces the model to expose its reasoning.

Before producing the final answer, think step by step in <thinking> tags.

Then answer in <answer> tags.

If you're uncertain about any step, flag it in <uncertainty> tags.

Higher token cost. Higher accuracy on hard tasks.

Pattern 4: “Constrain the surface area”

Stop the model from refactoring everything.

Constraints:
- Touch only the files I name
- Don't change function signatures unless necessary for the fix
- Don't refactor — make the minimal change
- Don't add comments unless explaining a genuinely subtle invariant
- Match the existing code style exactly

Saves: surprise refactors that double the diff size.

Pattern 5: “Diagnose before fixing”

For bugs.

Before changing any code:

1. Read the relevant files
2. Reproduce the bug (run the dev server, hit the issue, confirm symptom)
3. Explain the root cause in 2-3 sentences
4. Propose a fix
5. Wait for my approval before applying

Don't change anything until step 5.

Saves: fixes that mask bugs without fixing them.

Pattern 6: “Independent review”

When you’ve made changes and want a fresh look.

Spawn an independent code-reviewer subagent. Don't bias it with your
own prior reasoning. Tell it:

"Review the diff in this branch. Identify:
1. Bugs (must fix)
2. Security issues (must fix)
3. Suggestions (consider)

Be terse. Be direct. Don't praise. Don't suggest stylistic changes."

The subagent doesn’t see your earlier reasoning — fresh eyes, less confirmation bias.

Pattern 7: “Constrained output format”

When you need structured output.

Return your answer as JSON in this exact shape:
{
  "summary": "<one-sentence summary>",
  "files_changed": ["<path>", "<path>"],
  "risk_level": "low" | "medium" | "high",
  "follow_ups": ["<thing>", "<thing>"]
}

No prose. No explanation outside the JSON. If you can't comply, say why instead.

For agent workflows, use tool use to enforce the schema even more strictly.

Pattern 8: “What would you NOT do?”

Reveals model assumptions.

Before you start: what are 2-3 things you considered doing but decided
against? Why?

Surfaces hidden trade-offs and constraints the model is operating under.

Pattern 9: “Pretend you’ve never seen the codebase”

Forces the model to actually look around instead of pattern-matching from training data.

Pretend you've never seen this codebase before. Read the relevant files
first. Then propose your approach based on what's actually there — not
on conventions you might expect.

Saves: solutions that assume a stack or pattern this project doesn’t use.

Pattern 10: “Verify and report”

For verification steps.

After making the change:

1. Run `npm run build` and report the result
2. Start the dev server (`npm run dev`) and verify the feature works
3. Take a screenshot if it's a UI change
4. Summarize what you tested and what you observed

Don't claim "should work" — say "ran X, observed Y."

Saves: silent failures.

Pattern 11: “Explore THEN edit”

For changes in unfamiliar code.

First (in this turn): explore the relevant files to understand the
current behavior. Don't change anything yet.

Reply with a summary of:
1. How the current behavior works (which files, which functions)
2. What you'd change to implement the new behavior
3. Any potential complications

I'll respond with approval or redirection. Only then make changes.

Saves: blind edits that conflict with the existing patterns.

Pattern 12: “Time-box the exploration”

For research tasks where you don’t want a deep dive.

You have ~10 tool calls to investigate. After that, give me your best
answer with whatever you've learned, and flag what you didn't have time
to verify.

Forces concise research instead of unbounded exploration.

Pattern 13: “Stop and ask”

For high-risk or ambiguous tasks.

If you encounter ambiguity (multiple reasonable approaches, unclear
requirements, possible data loss), STOP and ask me. Don't pick one and
proceed silently.

Saves: silent decisions you would have wanted to make yourself.

Pattern 14: “Test the assumption”

For when you’re sure the model is wrong but want it to discover that itself.

You said X. I'm not sure. Before relying on X, verify it:

- Read the relevant file
- Run a quick test
- Quote evidence

If X turns out to be wrong, course-correct.

Saves: arguing about what’s true; the model checks.

Pattern 15: “Multi-pass synthesis”

For tasks requiring breadth.

Pass 1: Survey the problem. List 5+ possible approaches without committing.

Pass 2: Evaluate each — pros, cons, fit for our constraints.

Pass 3: Recommend one. Explain why.

Surfaces alternatives you’d otherwise miss. Especially good for architecture decisions.

Pattern 16: “The non-technical translator”

For explanations.

Explain X to me as if I'm a smart non-programmer. Use analogies. No
jargon without immediate definition. Aim for 2-3 paragraphs maximum.
Don't dumb it down — just speak in plain English.

Way better than “explain X” alone.

Pattern 17: “Adversarial review”

For when something feels too clean.

Pretend you're a hostile code reviewer who suspects this PR has a bug.
What would you look for? What would you challenge? Find ONE thing wrong
with this approach, even if it's small.

Forces the model to look for problems instead of confirming its own work.

Pattern 18: “Stage and commit incrementally”

For larger changes.

Implement this in stages. After each stage:
1. Verify it works
2. Commit with a descriptive message
3. Briefly summarize what's next

Don't accumulate uncommitted changes across multiple stages.

Aligns with the “commit often” workflow pattern.

Pattern 19: “Save the lesson”

When you’ve learned something worth keeping.

Save this as a feedback memory: [the rule]. Reason: [why]. Apply when:
[the trigger context].

Use this when you find yourself correcting the same kind of thing repeatedly. See Memory system.

Pattern 20: “Use the right model”

Direct the model to consider its own choice.

This is a planning task. Use Opus mode if not already on it.

Or:

Switch to Haiku for this — it's high-volume, low-complexity classification.

Models have different strengths. Use the right tool for the job.

Combining patterns

These compose. A realistic complex prompt might use Pattern 1 + Pattern 4 + Pattern 10:

Add a dark-mode toggle to the navbar that persists across sessions.

Plan first (don't make changes until I approve):
1. Files you'll touch
2. New files you'll create
3. Order of operations
4. How you'll verify

Constraints:
- Touch only the files needed for the toggle
- Match existing code style
- Don't add comments unless explaining a subtle invariant

After implementing:
- Run npm run build
- Verify in the dev server (toggle works both ways, persists on reload)
- Take a screenshot
- Summarize what you tested

That single prompt encodes a workflow. Used repeatedly, it produces consistent quality.

Saving as skills

When a pattern works for you, save it as a skill (Slash commands) so you don’t have to retype:

---
name: plan-build-verify
description: Plan a change, get approval, build it, verify it, summarize
---
 
[the prompt template]

Then /plan-build-verify triggers the whole pattern. After a year, you have a personal library of named workflows.

See also

Sources

Graph View

Backlinks