Prompt Engineering Examples: Before-and-After Pairs From a Library We Rewrote, With the Outputs

A prompt engineering example needs three parts: the prompt, the change, and what the change did. The pages ranking for this term show the first, sometimes the second, and almost never the third. On 26 September 2026 every base prompt in this site's 151-prompt library was audited against the builder's published rules and edited. Six of those edits are below as pairs: the line that was added, read from the prompt at build time; the vendor rule it applies, quoted; and the measured effect on what the builder did, where a run exists to measure it.

Updated 26 September 2026

Prompt engineering examples hero: the title beside a card, 101 prompts audited against Lovable's rules, each pair shows the line changed and what it changed, the ask-first closer measured at 2 to 5 questions, vendor techniques quoted not paraphrased, two runs of near-identical prompts compared, what a technique costs in credits where known

What do the vendors say a good prompt does?

Anthropic's prompting best practices, read 26 September 2026: “Claude responds well to clear, explicit instructions. Being specific about your desired output can help enhance results.” The image it uses: “Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.” On examples: “Examples are one of the most reliable ways to steer Claude's output format, tone, and structure.” On structure: “XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs.” On roles: “Setting a role in the system prompt focuses Claude's behavior and tone for your use case. Even a single sentence makes a difference:”

Lovable's docs, for a model that also runs the code: best practices gives three parts to a change prompt: what to build, where it goes, what must stay untouched, prompt by component, not page, and the closer “Ask me any questions you need in order to fully understand what I want”; from idea to app adds one change per prompt; split the prompt if the word and appears more than twice, and after two or three failed fixes, switch to Plan mode; design guidance says a prompt that commits to a visual direction skips the three-direction step.

The two rule sets, side by side
	Anthropic, for a chat or API prompt	Lovable, for a prompt that builds an app
Clarity	Clear, explicit instructions; a brilliant new employee without context	Three parts: what to build, where it goes, what must stay untouched
Scope	Chain complex prompts into steps	One change per prompt; split on more than two ands; prompt by component
Context	Add context; put long data at the top	Save decisions to project knowledge; name a visual direction
Examples	Three to five, in tags, to steer format and tone	Name the state copy and the look, or the builder invents them
Closing	Ask for a structured output	Ask the builder to ask its questions first

Six before-and-after pairs from the audit

The after text is read from the prompt at build time, so it is what the library ships today. The effect line says whether a run exists; three do, three do not.

1. End the prompt by asking for questions

Technique: Clarity, applied in reverse: let the model close the gaps you cannot see

Pair 1, prompt saas-mvp-auth
	Text
Before	The prompt ended at Safe-Guard Instructions. Lovable built from what was written and guessed the rest.
After	## Before Building Ask me any questions you need in order to fully understand the audience and the offer, then save the decisions to the project knowledge so later prompts build on them.
Rule applied	Lovable's best-practices page: end large prompts with "Ask me any questions you need in order to fully understand what I want". Applied to all 101 base prompts on 26 September 2026.
Effect	Measured: the July run without the closer asked 0 questions; the September runs with it asked 2, 4 and 5 before building, and one of them self-tested the invite flow.

2. Name the visual direction, or leave a slot that says you have not

Technique: Add context: one line that removes a whole round of guessing

Pair 2, prompt empty-states-skeletons
	Text
Before	UI prompts said nothing about the look. Lovable picked one, or asked, depending on the day.
After	## Visual Direction - [One line naming the look, e.g. minimal, one accent colour, Inter, an 8px spacing grid. Leave this section out and Lovable proposes three design directions to pick from before building.]
Rule applied	Lovable's design guidance: a prompt that commits to a visual direction skips the three-direction step. Inserted in 14 UI prompts.
Effect	Measured: with the slot removed on the states run, Lovable asked for the direction as one of its two questions; with the product named on the landing page run, it rendered two mockups and asked which to build.

3. Tell the model how to verify, not only what to build

Technique: Be clear and direct about the check, because the model cannot see what a crawler sees

Pair 3, prompt sitemap-seo-generator
	Text
Before	The SEO prompt asked for a sitemap and canonicals and stopped.
After	- After publishing, run Lovable's SEO & AI search review from the editor; on React + Vite projects crawlers receive a pre-rendered page that a plain fetch will not show, so the review is the check that counts
Rule applied	Lovable's SEO and AI search page: pre-rendering is served to verified crawlers only, so a plain fetch does not show it; the in-editor review is the check.
Effect	Measured on the Cadence project: the review ran for 1.1 credits and passed five of six checks; the sixth was the sitemap, deferred until publish.

4. Encode the platform's plan rules in the safeguard

Technique: Add context the model does not have: what the platform will refuse to do on this plan

Pair 4, prompt lead-magnet-download
	Text
Before	The lead-magnet prompt asked for an email delivering the asset. On a free plan that email cannot send.
After	- App emails on Lovable need a paid plan and a verified email domain; until both exist, deliver the asset on the thank-you state and queue the email for later
Rule applied	Lovable's prompt library page: app emails require a paid plan and a verified email domain.
Effect	Not run. The line changes what Lovable builds first: the thank-you state delivers the asset, the email is queued.

5. State the two paths so the model does not pick one silently

Technique: Structure: put the branch in the prompt, not in the model's head

Pair 5, prompt subscription-checkout
	Text
Before	The checkout prompt assumed a connected Stripe account.
After	- On Lovable, built-in payments (Paddle or Stripe) need a paid plan and run in test mode in the preview until the app is published; on the free plan connect your own Stripe account. Either way the webhook stays the source of truth, and the built-in flow allows one subscription per user per environment by default
Rule applied	Lovable's payments page: built-in payments need a paid plan; the free plan connects its own Stripe; one subscription per user per environment by default.
Effect	Not run. The Lovable and Stripe page has both paths quoted and this site's own webhook.

6. Sequence what the platform offers, so the first build is the simplest

Technique: Chain: the order of features is an instruction

Pair 6, prompt saas-mvp-auth
	Text
Before	The SaaS prompt said email and password auth and left providers to chance.
After	- Email and password first; Lovable's built-in auth also offers Google, Apple, Microsoft and magic links, so add a provider only after the role model works end to end
Rule applied	Lovable's authentication page lists Google, Apple, Microsoft and magic links on the built-in auth; the prompt makes email-first explicit.
Effect	Measured: the foundation run built email and password, roles and invites in one pass for 10.4 credits, with no provider added.

The one technique with a measurement across runs

The ask-first closer is the only edit applied to every prompt and run on both sides of the change. The count of questions the builder asked before writing code, per run:

Questions Lovable asked before building, per measured run

Questions Lovable asked before building, per measured run
Category	questions
Landing page + email opt-in	0 (2026-07-31)
Empty states and skeletons	2 (2026-09-26)
SaaS MVP with user auth	4 (2026-09-26)
SaaS landing page, six sections	5 (2026-09-26)

src/data/runs.ts and the SaaS landing page run. The July run predates the closer; the September runs include it.

Four runs is a small sample and the prompts differ, so this is a pattern, not a controlled test. What is not in doubt is the mechanism: the closer is the only line in those prompts that asks for questions, and the runs without it got none. The how to write prompts guide has the full section skeleton; the advanced prompts page covers Plan mode and knowledge files, which are where the answers go.

What do the top results for this term leave out?

Coursera, 6 Prompt Engineering Examples. About 1,400 words, updated 23 January 2026; six application areas described in a paragraph each, no prompts, no outputs; the CTA is a course.
CodeSignal, prompt engineering examples. About 1,600 words; four techniques with prompts and described outputs, one telling-versus-showing pair, no generated text; the CTA is a course.
Prompt Engineering Guide, Examples of Prompts. About 2,300 words; seven task types with prompts and outputs shown, which is the honest format; generic tasks, no before-and-after, no cost.

What we did not publish

A controlled test. The same prompt with and without one line, run twice on the same day, is the experiment this page implies and did not run.
Effects for pairs four and five. The lines are shipped; the runs are not, and the effect column says so.
Chat-model examples with outputs. The guide that shows those is linked above; ours are builder prompts, where the output is an app.

Sources

All read on 26 September 2026. Pairs composed from src/data/prompts.ts in src/data/promptEngineeringExamples.ts; the audit is docs/prompt-audit-2026-09.md in the repository.

Frequently asked

What is a prompt engineering example?↓

A prompt, the change made to it, and what the change did to the output. Most pages on this term show the first and skip the third. The six pairs here come from the audit of this site's own library on 26 September 2026: the line that was added, the vendor rule it applies, and where a run exists, the measured difference in what the builder did.

Which techniques do the vendors actually recommend?↓

Anthropic's prompting best practices, read 26 September 2026: be clear and direct, add context, use examples, structure with XML tags, give a role, put long data at the top, chain complex prompts. Lovable's docs for its builder: three parts to a change prompt, prompt by component, one change per prompt, end large prompts by asking for questions, and commit to a visual direction or expect to be asked. The pairs map each change to one of those.

Does asking the model to ask questions work?↓

It is the one technique on this page with a before-and-after measurement across runs. The July run without the closer asked no questions and built from guesses. The September runs with it asked 2, 4 and 5 questions first, and the answers shaped the build more than the prompt did. It costs a round of your attention and, on the SaaS run, part of the 10.4 credits.

Where do examples fit in a build prompt?↓

Anthropic calls examples one of the most reliable ways to steer format, tone and structure. In a build prompt for Lovable the example is usually the shape of the page section, the copy tone, or the exact state text; the states prompt names each state's copy so the builder does not invent it. The pairs here are about instructions, because that is what the audit changed.

How do you know a prompt change worked?↓

By running it and reading what came back, not by reading the prompt. Three pairs on this page have a run behind them and say what it cost; three do not and say so. A prompt edit without a run is a hypothesis, and the audit log records which is which.

Can I apply these to ChatGPT or Claude directly?↓

The vendor techniques, yes: they are Anthropic's own. The Lovable-specific rules, plan requirements and the ask-first closer, belong to a builder that runs the code. The coding prompts guide on this site has the library skeleton adapted for a chat model without a build step.