Verified against Perplexity Pro · 2026-08-07
Explain a technical concept grounded in official documentation, not third-party tutorials
A technical-explainer prompt that requires every claim about a specific tool, API, or protocol's behavior to be checked against its own official documentation or source, with third-party tutorials explicitly used only to check for outdated or version-specific drift.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Explain this technical concept, but ground every specific behavioral claim in the tool's own official documentation, source code, or official changelog — not in third-party tutorials, Stack Overflow answers, or blog posts, which frequently describe an older version's behavior without saying so. CONCEPT / FEATURE How React Server Components handle data fetching and caching by default TOOL / VERSION Next.js 15 App Router WHY I NEED THIS Deciding whether our existing data-fetching pattern needs to change after upgrading from Next.js 13 MY CURRENT UNDERSTANDING (correct me if this is wrong or outdated) I believe fetch calls in Server Components are cached indefinitely by default unless explicitly opted out. RULES - For any claim about specific behavior, default values, or configuration options, cite the official documentation page or the specific source file/changelog entry, not a tutorial's paraphrase of it. - If the official documentation is ambiguous, incomplete, or contradicts itself between pages, say so explicitly rather than picking whichever reading sounds cleaner. - You may use third-party tutorials or forum posts specifically to flag "this changed in version X and a lot of older tutorials still describe the old behavior" — that's a legitimate and useful use of secondary sources, distinct from using them as the primary evidence for how the feature currently works. - If my current understanding above is based on outdated behavior, name specifically what changed and in which version, rather than just correcting me without explaining why my prior understanding was reasonable at some point. OUTPUT FORMAT 1. A clear explanation of how the concept actually works in the specified version, with inline citations to official sources. 2. A short "common misconception" note if third-party content commonly describes this differently, explaining specifically why the common version is wrong or outdated. 3. A minimal, correct example if relevant, verified against the same official source rather than adapted from a tutorial's example.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Technical tutorials and forum answers have an extremely long shelf life on the open web relative to how fast the tools they describe actually change — a Stack Overflow answer from three major versions ago still ranks well for the same search query today, and a search-grounded answer engine has no inherent reason to prefer the currently-accurate official doc over the more heavily-linked, better-SEO'd tutorial describing an old default. Explicitly anchoring every behavioral claim to official documentation or source rather than secondary explainers routes retrieval toward the one source type that's actually authoritative about current behavior, while still permitting third-party content for the specific, legitimate task of flagging version drift — a distinction that matters because banning secondary sources entirely would also throw away one of the most useful signals available: a tutorial explicitly warning that behavior changed is itself evidence worth surfacing, just not evidence about what the current behavior is. Requiring the model to name what changed and in which version, rather than just correcting an outdated understanding, matters for a practical reason specific to technical work — a developer's mental model of a tool is frequently correct for the version they learned it on, and treating it as simply wrong without dating the actual change makes it harder to know whether other related assumptions from around that same era also need rechecking. And flagging documentation that's ambiguous or self-contradictory rather than silently picking a reading matters because official docs are themselves imperfect artifacts, often lagging behind a feature's actual shipped behavior or containing pages written by different authors at different times that were never fully reconciled — treating the documentation as infallible just because it's the primary source would trade one blind spot for another.
Verified against
Perplexity Pro Sonar Pro · 2026-08-07
Changelog
- 2026-08-07 — Initial publish, verified against Perplexity Pro Sonar Pro search.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
