Prompt patterns and recipes

Named patterns that get you better builds — plan-first, do-not-touch, constraint prompts, critique-and-revise, atomic UI vocabulary.

Once you have the basics down, prompting becomes a small set of reusable moves. This page names the ones that pay off most often, with examples you can copy. Pair it with Writing better prompts for the fundamentals.

Plan-first prompts

Ask Layout to write a plan before it writes code. For any change larger than a single component, this is the cheapest way to catch a misread before it turns into five files of the wrong thing.

Before making changes, write a short plan:
- What files will change
- What the new behavior is
- What I should test after
Wait for my approval before editing.

You pay one credit for the plan, then approve or correct. If the plan is wrong, you have saved the cost of the bad build.

Plan-first is worth it when the change touches more than one file, when it adds a new data model, or when you have been through two rounds of wrong fixes already.

Do-not-touch lists

The biggest source of wasted credits is the AI fixing a file you did not ask it to change. Prevent it.

Fix the bug in components/cart.tsx.

Do not touch:
- app/layout.tsx
- components/nav.tsx
- anything in lib/

The more precisely you name the scope, the less scope creep you get. Anything not on the list is fair game for the AI; anything on the list is off-limits.

Constraint prompts

Tell the AI what the solution space is, not just what the problem is. Constraining the shape of the answer costs nothing and saves rounds.

The heading on the homepage is hard to read.

Fix it by changing the text color only. Don't move anything, don't change the font size,
and don't touch any other section.

Compare:

Fix the heading on the homepage.

The first prompt has one reasonable outcome. The second has a hundred — the AI might resize the text, restructure the section, change the background, or rewrite the copy. Adding "change the color only" rules all of that out before it starts.

Critique-and-revise

Ask the AI to review its own work before you do. Models are better at catching their own mistakes than at avoiding them in the first place.

You just added the notifications feature.

Before I look at it, review your own work:
- Does it do everything I asked for?
- Is there an empty state — what shows when there are no notifications yet?
- Did you change anything I didn't ask you to change?

List any issues, then fix them.

If you're building with a database or backend, you can make the checklist more specific:

You just added the notifications feature.

Before I test, review your changes:
- Is RLS enabled on any new tables?
- Are there any unused imports?
- Is the empty state handled?
- Did you touch files you did not need to?

List issues, then fix them in the next build.

This pattern is especially useful after the AI has generated a migration plus the code that uses it — a common place for subtle mismatches.

Atomic UI vocabulary

Pick a small, consistent vocabulary for UI elements and reuse it. The AI picks up on the names you use and stays consistent with them.

A working vocabulary:

  • Panel — a section of the page with a heading
  • Card — a compact rectangular item in a list
  • Modal — an overlay that blocks the page
  • Drawer — a panel that slides in from the side
  • Toast — a transient notification in the corner
Move the "Add task" form from a modal to a drawer on the right.

Clearer than "move the popup thing to the side."

The "show me first" pattern

When you want to see options before committing, ask the AI to produce variants side by side or in sequence.

Propose three layouts for the pricing page. Describe each in one paragraph,
no code yet. I'll pick one.

Cheap, fast, and avoids building-then-discarding.

The "rollback or refine" rule

After any failed fix, ask one question: do I understand the problem better now? If yes, refine the prompt. If no, roll back and try a different approach. Do not re-prompt without new information.

See Debugging mindset for the full treatment.

Anti-recipes

Patterns that look helpful but backfire.

"Just do what you think is best"

Sounds humble. In practice, the AI picks an arbitrary direction, and you spend the next three prompts walking it back. Always name the outcome.

"Make it better"

Too vague to act on. Pick an axis: faster, cleaner, more accessible, more consistent with the rest of the app. Name the axis.

Stacking five changes into one prompt

Each change is a vector for error. If three land and two miss, the diff is hard to reason about. One change per prompt is the default.

Next steps

On this page