Prompts That Produce Components, Not Essays

The first ShopLens summary prompt was one line: "Summarize these reviews." The model did a good job by its own standards. It returned 340 words with a heading called "Pros", a heading called "Cons", eight bullet points and a closing paragraph that began "Overall,". The panel had room for about four lines. The headings rendered as literal ## characters, and the panel pushed the Add to Cart button below the fold on a phone.

The model was not wrong. It wrote an essay because nothing told it that its words would go into a fixed slot in a layout. A prompt for a UI is closer to a component specification than to a question. This lesson shows how to write the ShopLens summary prompt from the component backwards.

Start from the component, not from the model

Before writing any prompt, look at the slot the text will fill. The "What buyers say" box on a 360-pixel-wide phone shows about 12 words per line and four lines before a "Read more" fold. It renders plain text inside a paragraph. It speaks for buyers, not for the shop. Each of those facts becomes a rule.

Writing this table first is the most useful habit in this section. It turns vague wishes ("keep it short") into rules you can test against saved outputs.

The anatomy of a UI prompt

A ShopLens prompt has two parts. The system prompt holds the fixed instructions: the role, the task and the output rules. It is the same for every product. The user message holds the data for this request: the product name and its reviews. Keeping them apart has practical benefits: you can version the system prompt like code, and reviews can never accidentally rewrite the rules around them.

1// server/prompts.ts2import type { Review } from "../shared/schemas";34export const SUMMARY_PROMPT_VERSION = "summary-v3";56export const SUMMARY_SYSTEM = `You write the "What buyers say" box on a product page.7Rules:8- Write 2 to 4 plain sentences, at most 60 words in total.9- Describe what buyers report. Do not give your own opinion or advice.10- Mention both praise and complaints when both appear in the reviews.11- Use only facts found in the reviews. Do not state numbers that no review states.12- After each claim, cite one or two review ids in square brackets, like [r1042].13- Plain text only: no headings, lists, bold, emoji or line breaks.14- If fewer than 3 reviews discuss the product itself, reply exactly: NOT_ENOUGH_INFO`;1516export function formatReviews(reviews: Review[]): string {17  return reviews18    .map((r) => `<review id="${r.id}" rating="${r.rating}">\n${r.title}\n${r.body}\n</review>`)19    .join("\n");20}2122export function summaryUserPrompt(productName: string, reviews: Review[]): string {23  return `Product: ${productName}\n\nReviews:\n${formatReviews(reviews)}`;24}

Each review is wrapped in a tag like <review id="r1042">. The tags show the model where one review ends and the next begins, and they carry the id the model must cite. The SUMMARY_PROMPT_VERSION string travels with every logged output, so when a shopper reports a bad summary you know which prompt wrote it. Section 5 hardens formatReviews against reviews that try to break out of their tags.

Length: ask in words, enforce in code

Models are poor at counting words, because they see tokens, not words. Ask for "at most 60 words" and you get a distribution, not a guarantee. On the ShopLens test set of 200 products, 92 percent of summaries were under 60 words, 99.5 percent under 80, and one was 131 words long.

So the prompt sets the target and the code sets the limit. In section 3, the summary route counts words as they stream and stops at 80, whatever the model does. The prompt's job is to make that hard stop rare.

You might think the model's max_tokens setting is the length control. It is a cost ceiling, not a layout tool. When the model reaches it, the output simply stops, often in the middle of a sentence. ShopLens sets it well above the expected length, at 300 tokens, so that it only ever triggers on a runaway reply.

Give the model an honest way out

A product with two reviews, both about slow delivery, has nothing to summarise about the product. If the prompt only says "summarise", the model will still write something, and it will probably invent a general statement like "Buyers are generally satisfied." That is a hallucination created by your prompt.

The fix is to give the model an exit with a fixed, machine-readable reply: NOT_ENOUGH_INFO. The BFF checks for that exact string and sends the UI a clear "not enough reviews" response, which the panel renders as an empty state. A fixed sentinel is easy to test, easy to detect in a stream, and never shown to shoppers.

The BFF also checks the simple case before calling the model at all: fewer than 5 reviews means no call. That rule costs nothing, and the sentinel handles the subtler case where there are enough reviews but not enough substance.

Voice and perspective

"You should buy these" and "These are the best headphones under ₹10,000" are statements your company is making, even if a model wrote them. The rules "describe what buyers report" and "no advice" keep the summary on the right side of that line. They also make the summary more useful: "Several buyers find the cushions warm after two hours" helps a shopper decide; "Great headphones!" does not.