The system prompt behind my indie game recommendations carries one instruction I care about more than the rest: 2-4 "avoid if" caveats (e.g. "avoid if you dislike permadeath"). It's been in there since I wrote the generator on 2026-04-23, sitting alongside the summary, similar-games and "good for" fields.
This is a post about why that one requirement matters more than its size suggests, and where it falls apart. Fair warning up front: the caveats currently on the site are committed placeholders, not model output — I come back to that below.
The marketing-speak problem
Pull up almost any indie game directory site and you'll find the same shape of copy: every game is "breathtaking", "innovative", "unforgettable". The third-party recommendation engines built on top of Steam are particularly bad at this — they default to the marketing voice of the developer's own store page.
I noticed it as soon as I started building Find Games Like, the indie-games half of a three-site experiment I'm running. The catalogue is 120 indie titles, and the summaries sitting in games.json today come straight from Steam's own short descriptions — which read exactly like the back of a Steam keyword search: lots of adjectives, zero specific information about who shouldn't play.
Generic AI tone matches generic marketing tone, because both are trying to maximize the chance that any given reader thinks the product is for them. That's exactly the wrong objective for a recommendation engine. A good recommendation is most useful when it filters out the wrong audience.
The actual prompt rule
Here's the shape of it. The system prompt in apps/indie-games/src/etl/generate-content.ts asks for four things per game, and the fourth is the one that does the work:
1. A 2-3 sentence editorial summary (no hype, focus on what the game actually does)
2. 3-5 similar games players might also enjoy (names only)
3. 3-5 "good for" audience descriptors (e.g. "players who enjoy tight platforming")
4. 2-4 "avoid if" caveats (e.g. "avoid if you dislike permadeath")
One numbered line out of four. The prompt also names avoid_if (string[]) in the required JSON shape — but nothing enforces that at runtime. parseOrFallback() keeps the model's array only if (Array.isArray(p.avoid_if)); if the key is missing or comes back as anything else, it silently substitutes the generic fallback caveats. So the model can quietly skip it, and I'd never see an error.
The reason the prompt demands it rather than treating it as optional: having to name who shouldn't play should push the model toward the game's actual properties instead of flattery, and a caveat anchors the positive lines around it in something checkable. That's the theory the field is built on. It isn't a measured result yet — see the next section.
What's actually in the data
Here's the uncomfortable part. The 120 entries committed to apps/indie-games/src/data/games.json are placeholders, not generated output. The generator only calls the API when ANTHROPIC_API_KEY is present, and it hasn't been. Every single game carries the same two caveats:
Celeste — "You prefer AAA production values" / "You dislike experimental mechanics"
Hades — "You prefer AAA production values" / "You dislike experimental mechanics"
Hollow Knight — "You prefer AAA production values" / "You dislike experimental mechanics"
That is exactly the failure mode the rule exists to prevent: a caveat that names no property of the game at all, repeated 120 times. A placeholder that looks like content is worse than an empty field, because nothing about the page tells you it's empty.
What I want out of the field is a caveat that names something a reader can check against their own preferences — permadeath, run length, a deliberately cryptic map. Not "if you don't like indie games" or "if you don't like Metroidvanias", which is what a lazy version of this prompt would produce, and not the AAA-production-values line the site is shipping today.
Why the rule should work
There's a credibility mechanic here that's older than directory sites: admitting weakness signals integrity. A recommender that only ever says good things either has bad taste or is hiding something. A recommender that says "this is great, but it's not for you if X" is making a calibrated claim — which makes the positive part of the claim more believable.
The same instinct shows up in product copy when it's done well. Patagonia's "Don't Buy This Jacket" Black Friday ad is the canonical example. App Store reviews that lead with "I had to stop using this because…" are the most useful ones in the entire reviews section. Restaurant guides that explicitly note service quirks alongside food quality feel more trustworthy than ones that only star-rate.
The "avoid if" pattern is just the directory-listing version of that instinct, applied at the prompt layer instead of relying on individual writers to remember to do it.
Where it breaks down
Not every game has a meaningful caveat. Some titles are genuinely broad-appeal — short narrative games, cozy farming sims, party games for groups. My prompt demands 2-4 caveats for every entry regardless, which is a standing invitation to invent one. Stardew Valley is the obvious case: I can't think of an honest "avoid if" for it beyond "you don't enjoy slow-paced games", which is approximately useless.
The fix I want is a rule that permits an empty avoid_if array when no honest caveat exists, instead of forcing one onto every entry. It isn't in the prompt yet — the instruction still says 2-4 — and I have no compliance numbers to quote, because the generator hasn't run against the API.
Two other places this technique fails:
Taste-driven domains where there's no objective basis for caveats. Recommending books for a particular mood, or recommending restaurants for a particular cuisine — the caveat would be tautological ("avoid if you don't like mystery novels"). The technique needs a domain where some audience traits genuinely conflict with the product.
When the underlying knowledge is wrong. A model can land the caveat on the wrong axis entirely — flagging "puzzle complexity" for a game whose real stress point is a time-loop timer. Wrong-axis caveats are arguably worse than no caveats: they look authoritative while pointing the reader at a fictional concern. I haven't solved this. The generator already passes each game's Steam genres and short description in the user turn; the next step I'd try is feeding it the game's actual Steam tags too, so the caveat has something concrete to attach to.
Where to apply it beyond games
I think the same pattern applies to almost any directory or recommendation site:
- OSS alternatives to SaaS: "Stay on the SaaS if your team has fewer than three engineers and no DevOps capacity."
- AI tools directories: "Avoid this model if your workload is latency-sensitive at scale."
- Restaurant guides: "Skip on a date — the lighting is industrial and tables are loud."
- Book recommendations: "Skip if you've already read X — the thesis overlaps significantly."
What these share is a mental model where the audience has a specific trait, the product has a specific limitation, and a useful directory makes that mapping explicit instead of leaving every reader to discover it post-purchase.
What I'm watching
I don't have data yet on whether "avoid if" caveats actually translate into more reader trust. Find Games Like is eight days old and traffic is essentially zero — I'll publish real engagement numbers (comments, time on page, return visits) at the 30-day mark.
The falsifiable claim is: pages with caveats should outperform pages without them on engagement metrics. If that turns out to be wrong by month two, I'll need to revisit the assumption that honesty-as-trust-signal works in directory contexts the way it works in book reviews.
Until then: the requirement stays in the prompt, and adding a real check for it — instead of falling back to the template — is on the list. The placeholder caveats come out the first time the generator runs with a key attached.
Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.
Top comments (0)