Lesson 24 of 25
The Treasure of Specificity
A vague request gets an average answer, because the model has to pick a middle of the road you did not describe. Every concrete detail you add - a word count, a named place, a numbered structure, who is reading it - removes a guess it would otherwise make for you. Specificity is not about writing a longer prompt; it is about replacing the decisions you left open with the ones you actually want.
Break the specifics into separate tags rather than one dense paragraph - <audience>, <structure>, <constraints>, <format> - so each kind of specificity sits in its own place and nothing hides in the middle of a block. When you have long reference material, put it in a tag first and the instruction last. Then add the tag the others do not have: <how_to_handle_uncertainty>, telling it what to do when a specific is missing, which is what stops it filling a gap with something plausible.
- One tag per kind of specific; nothing in a dense block.
- Long reference material first, instruction last.
- Add a tag saying what to do when a specific is missing.
- No image generation here - write the prompt, run it elsewhere.
- If output reads mechanically, loosen structure, keep content specifics.
Instead of
Write a blog post about travel in India.
Perplexity version
<task> Write a 1200-word travel blog post titled "A 3-Day Cultural Deep Dive into Hyderabad for First-Time Visitors". Produce it as an Artifact - I will be editing this. </task> <audience> Someone who has never visited Hyderabad, is planning a long weekend, and is choosing between this and three other Indian cities. They want to know what makes this one worth the trip. </audience> <tone> Enthusiastic and informative. Not a brochure, not a listicle. </tone> <structure> Day 1 - the Old City: Charminar, Laad Bazaar, Chowmahalla Palace. Day 2 - the era of the Nizams: Salar Jung Museum, Golconda Fort with the evening light and sound show. Day 3 - modern Hyderabad: Hi-Tech City, and a biryani meal at a well-known place such as Paradise. Per day: a short paragraph on its character, then each stop with roughly how long to spend, what to actually look at while there, and one specific detail a first-time visitor would otherwise walk straight past. </structure> <must_hold> 1. Each day works as a route - stops in an order that makes geographic sense. A plan that sends the reader across the city twice is not a plan. 2. Practical specifics: which parts of the city the metro reaches and which it does not, when an auto or cab is the better call, and which months are genuinely too hot - name them rather than writing "visit in the cooler season". 3. Concrete over evocative, throughout. "Charminar at 7am before the shops open" earns its place. "Charminar at sunset, bathed in golden light" is in every other post about this city. </must_hold> <preferences> - Two or three dishes named, beyond biryani. - A line on what to wear for the Old City and the fort. - Close with what to cut if the reader only has two days. </preferences> <how_to_handle_uncertainty> This is the important one. You do not know current opening hours, ticket prices, whether the light show still runs or whether a given restaurant is still open. Do not state any of those as fact and do not quietly leave them out either - write them as "check before you go" in the text, and list them separately at the end as things I must verify before publishing. Confident invention about a ticket price is the specific way a detailed travel post becomes wrong. </how_to_handle_uncertainty>
Instead of
Analyze my sales data.
Perplexity version
<sales_data> [Paste the full CSV here - this goes first because it is reference material, and the instruction below is what you follow] </sales_data> <role> A senior data analyst. </role> <task> Analyse the sales data above - last quarter. Four tasks, in order. </task> <tasks> 1. Total revenue for the quarter. Give the figure and the number of rows it was computed from, so I can see nothing was dropped. 2. Top 5 products by units sold, as a table: product, units, revenue, share of total revenue. Call out any case where the top seller by units is not the top by revenue - that gap is usually the most useful thing in a quarter of sales data. 3. Week-by-week trend. A table, then one paragraph: rising, falling or flat, and whether the movement is big enough to be a trend or is noise at this sample size. 4. A one-paragraph recommendation on which category to focus marketing on next quarter, citing the specific numbers from tasks 1 to 3 that support it. </tasks> <must_hold> - Every figure traceable to the data above. No industry benchmarks, no comparison with typical performance, nothing from outside the file. - Show the arithmetic for the totals in one line so I can check it. </must_hold> <how_to_handle_uncertainty> If a column is ambiguous, inconsistently formatted or missing values, stop and ask me before computing anything. Do not infer what a column means and proceed - an analysis built on a guessed definition looks exactly like a correct one, and I will not know which I am reading. Specifically: tell me if you find duplicate rows, blank prices, or dates in more than one format, and wait. </how_to_handle_uncertainty> <also_tell_me> - What this data cannot answer. One quarter with no prior period means seasonality is invisible, and a recommendation that ignores that is overconfident. - Which fields I should start capturing to make next quarter's analysis better. </also_tell_me>
Instead of
Create an image of a woman working.
Perplexity version
**Claude cannot generate images.** That is a plain gap, and the honest adaptation is to use it for what it is good at here - turning a vague visual idea into a precise, structured brief - then run that brief in Gemini, ChatGPT or a dedicated image tool. This is genuinely useful rather than a consolation prize: most bad images come from an underspecified prompt, and writing the prompt properly is a writing task. <my_rough_idea> An image of a woman working. Indian, software developer, modern office in Hyderabad's Hi-Tech City, looking confident. </my_rough_idea> <task> Turn the idea above into a complete image-generation prompt I can paste elsewhere. </task> <what_the_prompt_must_specify> - Subject: age, what she is doing, where she is looking, her expression - and make the expression specific rather than "confident". Smiling at her work is a different picture from smiling at the camera. - Setting: the office, the light, the windows, what is visible behind her and how out of focus it is. - Clothing: specific enough to be rendered - a smart kurti and trousers, not "professional attire". - Camera: shot type, angle, depth of field, light source and direction. This is the part people leave out and it decides whether the result looks like a photograph or like stock. - Style: photorealistic, and what that excludes. </what_the_prompt_must_specify> <then_give_me> 1. The prompt itself, ordered subject first, then setting, then camera. Order matters in image models: details at the end of a long prompt get dropped, so the non-negotiable elements go first. 2. Three variants - one changing the setting, one the composition, one the mood - so I have somewhere to go if the first result is close but wrong. 3. What to expect to go wrong. Hands on a keyboard and any text on screens or signage come out mangled routinely; tell me how to frame around that. 4. A short note on how to iterate: change one element per attempt and ask for an edit rather than a regeneration, or I get a different woman in a different office each time. </then_give_me> <ask_me_first> One question before you write it: what is the image for? A blog header, a slide, a LinkedIn post - each needs a different crop and different empty space for text. That single specific changes the prompt more than any visual detail in my rough idea. </ask_me_first>