Reference Anchor
Give it a concrete reference; it works ten times better than adjectives.
Give it a concrete reference; it works ten times better than adjectives. Rather than saying "make it cleaner," say "reference a specific part of a specific thing."
What you'll run into:
- You pile on adjectives, and the result is still the generic template look
- You go back and forth for five rounds, describing the same thing with a different set of adjectives each time
- You have a rough picture in your head but can't put it into words
The problem with adjectives is that they describe feelings, and feelings differ from person to person. "Clean" to you means more whitespace; to it, maybe fewer elements. "Professional" to you means high information density; to it, maybe a darker blue palette. You are using the same word for different things.
A reference has no such ambiguity. It's an objective thing—you can point at it and say "like this," or point and say "not this."
What to anchor
| What to anchor | How to say it | Why it beats adjectives |
|---|---|---|
| Structure | Reference an email client's left nav plus list plus detail | "Clear layout" can't say how many columns |
| Density | Match the information density of a task manager's list | "Clean" might mean more whitespace or fewer items |
| Tone | Reference how a certain product writes error messages | "Friendly" is a direction, not a standard |
| Code style | Reference an existing file in the project | "Stay consistent" without saying with what says nothing |
| Negative reference | Don't make it like that kind of page, and why | Elimination can converge faster than positive description |
The last row is often skipped. One "not like this" example can lock the direction more than three positive examples—a screenshot of "don't make it like this" usually converges faster than three positive images. But you have to say why you don't want it, or it reads as a passing remark.
How to give it
- Point to a specific part, not the whole product. "Reference product X" is too big; "reference its task-list screen" is actionable.
- Say what to borrow and what not to. Borrow the structure, not the features; borrow the density, not the palette. Without that clarity, it copies the features too (see borrow the form).
- Use screenshots. If you can show an image, show one—a screenshot is far more precise than a paragraph. And after sharing it, point out which part you care about.
- References from inside the project work best. "Follow the existing OrderList component's pattern" is the strongest anchor—it's right there in the codebase, with zero room for interpretation.
- Have it paraphrase first. Ask it to state what it plans to borrow and what to skip; you catch the misread in seconds.
- Don't give too many at once. Past three or four references, it can't tell which one is authoritative. Rank them: structure first, density and palette after. Ranked references plus a paraphrase step catch almost all misreads on the spot.
Package these rules into a reusable template:
Build: [what to build]
Reference targets:
- Structure: [specific part of a specific product], what I care about is [specific point]
- Density: [specific part of a specific product]
- Code style: the existing [specific file path] in this project
Explicitly NOT borrowing:
- Its feature list. My feature scope is in [spec file]
- Its color palette. Colors use the project's existing design tokens
First restate: what you plan to borrow and what to skip,
and your understanding of "the specific point I care about."
I'll confirm before you start.