Prompt Patterns for Development

Overview

Good prompts are reusable. Instead of writing ad-hoc instructions every time, keep a library of proven patterns for common development tasks. Each pattern below has been refined through hundreds of real-world uses.

Copy, adapt, and make them your own.

Code Review Pattern

Use this when reviewing code changes — your own or a teammate’s:

Review this code for:
1. Security vulnerabilities (injection, XSS, secrets)
2. Performance issues (N+1 queries, unnecessary re-renders)
3. Error handling gaps (unhandled promises, missing try/catch)
4. Type safety (any types, missing null checks)
5. Naming clarity (functions, variables, files)

Rate each issue: CRITICAL / HIGH / MEDIUM / LOW
Suggest a fix for each issue found.

Why It Works

The numbered list forces structured analysis instead of surface-level feedback. The severity rating ensures you fix critical issues first and don’t get distracted by style nits.

Bug Investigation Pattern

Use this when you have a bug to track down:

Investigate this bug:

**Symptom:** [what the user sees]
**Expected:** [what should happen]
**Steps to reproduce:** [1, 2, 3]

1. Find the root cause (not symptoms)
2. Explain WHY it happens
3. Propose a fix with minimal code changes
4. Identify related code that might have the same issue

Why It Works

The symptom/expected/reproduce structure ensures you provide enough context. Step 4 catches similar bugs before they become user reports.

Architecture Decision Pattern

Use this when choosing between approaches:

I need to decide between [Option A] and [Option B] for [context].

Evaluate both options on:
1. Simplicity (less code, fewer abstractions)
2. Performance (runtime, build time, bundle size)
3. Maintainability (team familiarity, ecosystem support)
4. Scalability (will it work at 10x scale?)

Recommend one with clear reasoning.
Show the tradeoffs I'm accepting with each choice.

Why It Works

Forces evaluation on specific criteria instead of vague “which is better” questions. The tradeoffs line ensures you understand what you’re giving up — every choice has a cost.

Test Writing Pattern

Use this when writing tests for a function or component:

Write tests for [function/component]:

1. Happy path (expected inputs -> expected outputs)
2. Edge cases (empty, null, boundary values)
3. Error cases (invalid inputs, network failures)
4. Use describe/it blocks with clear test names
5. Follow AAA pattern: Arrange -> Act -> Assert

File: [path to implementation]
Framework: [vitest/jest/playwright]

Why It Works

The three categories (happy, edge, error) ensure comprehensive coverage. The AAA pattern keeps each test focused and readable. Specifying the framework avoids guessing.

Component Implementation Pattern

Use this when building a UI component:

Implement [component name]:

**Behavior:** [what it does]
**Props:** [interface or list]
**Design:** [reference to design system or Figma]

Requirements:
- Accessible (ARIA attributes, keyboard navigation)
- Responsive (mobile-first)
- Performant (no unnecessary re-renders)
- Tested (unit test alongside)

Constraints:
- [File size limit, dependency restrictions, etc.]

Why It Works

The structured format prevents half-built components. The constraints section catches issues before implementation — better to know the rules upfront than refactor later.

Refactoring Pattern

Use this when improving existing code:

Refactor [file/function]:

Current issues:
- [list specific problems]

Goals:
- [what the refactored code should achieve]

Constraints:
- Don't change the public API
- Keep all existing tests passing
- No new dependencies

Show the before/after diff for each change.

Why It Works

Explicit constraints prevent scope creep. The “don’t change the public API” constraint is especially important — refactoring should improve internals without breaking consumers.

Tips for Better Prompts

Be Specific About Constraints

# Vague
"Make this faster"

# Specific
"Reduce the initial render time of this component.
Only use transform and opacity for animations.
Keep the bundle under 5KB gzipped."

Provide Context

Always include: what file you’re working in, what the surrounding code looks like, what patterns the project already uses. Context prevents the AI from inventing new patterns that clash with existing ones.

Define Done

# Vague
"Write a function to validate email"

# Clear
"Write a function that validates email addresses:
- Returns { valid: boolean, error?: string }
- Checks format, domain, and common typos
- Unit tested with 10+ test cases
- Exported from src/utils/validation.ts"

Ask for Reasoning

Adding “explain your reasoning” or “show the tradeoffs” forces deeper analysis. Without it, you get the first plausible answer. With it, you get the considered answer.