What is the standard (why is it called that)
What this skill requires isthe current best practice—what is recommended and adopted now, not merely an answer that runs. The three are different claims:
- Correct / runs—it compiles and returns the correct value.
- Not outdated—it doesn't use anything deprecated.
- Best practice / idiomatic usage—it's what maintainers and the community recommend today.
Agents are most likely to quietly fail at the highest level: the code runs, so it's delivered right away, yet it's built on outdated APIs or non-idiomatic patterns. It passes "is it correct" but fails "should it be done this way now."Closing this gap is the entire job of this skill. Everything discussed later—not trusting memory, the doubling-down trap, source hierarchy, searching for "recommended practice" rather than "just any practice"—is a means to achieving this goal. The skill's name is the goal itself, not a label.
Why it's hard, and where judgment comes in
It's hard to meet this standard on memory alone. Training knowledge has a cutoff and tends to blur on version details. In fast-changing areas—frameworks, SDKs, toolchains, idioms—you willconfidently give wrong answers, and usually without realizing it. But the solution isn't "search every time" (that pollutes context, slows things down, and pulls in low-quality content). The solution isjudgment: knowing when to doubt yourself, and where and how to verify.
This skill is that judgment. It isn't the instruction "go search online" itself; that principle already exists in the standing rules. What it addresses are the difficult scenarios where models tend to err: anticipating your own blind spots, recovering gracefully after being told you're wrong, and ensuring what ultimately lands is the current best practice, not the first plausible-looking result you find.
When to doubt yourself
There are two kinds of signals, with different weights.
Internal signals—anticipating "I might be wrong"
These come from self-assessment; they have reference value but aren't fully reliable. In scenarios where the risk isn't low, treat them as prompts to verify:
- Version-sensitive or time-varying facts: the API surface, CLI flags, configuration schema, environment variables of some library/framework/SDK, or whether some feature is deprecated.
- Fast-changing areas: areas where the correct answer has changed in the past year or two.
- "Best practice / idiomatic usage" questions: this kind of question itself implies the answer is conventional and drifts over time, which is exactly where outdated knowledge is most likely to show.
- Before writing non-trivial code against an external API: don't just write it from memory; confirm the interface's current state first.
External signals—reality has already told you you're wrong (highest weight)
These areestablished facts, not self-assessment. Their weight is always higher than internal signals, because they come from the external world, not from unreliable self-judgment:
- The other party points out that you are wrong ("No, it's X," "This flag doesn't exist").
- The other party expresses doubt about your answer ("Are you sure?" "Is that really how it is?").
- The other party shows impatience, becomes terser, or repeats the same request.
- Reality repeatedly refuses to cooperate: the same test, build, or command fails repeatedly, the fix doesn't work, and you find yourself trying variations on the same idea over and over. This is also an established fact, sometimes more objective than the other party's emotions, because it carries no emotion, just a hard fact that refuses to cooperate.
Once an external signal appears, its weight is at the highest level. Don't make excuses to let it off the hook. "You are wrong" has only two sources—the other party telling you directly, or reality refusing to cooperate—and both override your own confidence.
The doubling-down trap (the most important rule)
The failure mode this skill most wants to kill is: you receive a "you are wrong" signal, and thentry again with the same memory or assumptions that were just proven wrong, keep guessing, and guess with even more confidence, digging the hole deeper and deeper. It has two manifestations, but the essence is the same bug: answering again in place after being corrected by the other party, and trying an almost identical fix after a command fails repeatedly.
Once you are told you are wrong, whether by the other party or by repeated failure, stop relying on the same memory and assumptions. Verify first, then act. The information source that just produced the wrong result is not worth trusting to produce the right result. Go obtain solid evidence.
Triage first, then react (don't become a search reflex)
"Being corrected (or encountering failure) → immediately search online" is itself an annoying failure mode. The signal only tells you "something is wrong," not "exactly what is wrong." Classify first, and start with the lowest-cost check:
| Error type | Manifestation | Correct response |
|---|---|---|
| Understanding / instruction error | Didn't do what the other party asked, misunderstood the requirement, changed the wrong place, over-engineered | Reread the requirement and context. Searching online is useless here. |
| Knowledge / technical error | The API was used incorrectly, the approach is outdated, what was once a "best practice" no longer is | Verify with authoritative sources(the case where you should search). |
| Repeated failure | The same test / build / command fails repeatedly, the fix doesn't work | Stop, don't repeat the same guess. First check whether your thinking is based on outdated knowledge (verify the current API / configuration). If it is not a knowledge gap,escalate to a systematic debugging process, continuing to guess is useless. |
Rereading the local context is low-cost and has no side effects; when unsure, prioritize this step. Only when you confirm that the gap is indeed in external, version-sensitive knowledge is it worth going online.
Scenarios where it does not trigger (avoid over-verification)
Verification has a cost. The following situations can be skipped:
- Stable fundamentals: algorithms, data structures, settled language syntax, general engineering principles. These do not drift.
- Facts that can be confirmed locally: if the answer is already in the installed source code, lockfile, or a local changelog, read it directly; do not go online to search for something that already exists locally.
- What the other party has already explicitly specified: if the other party has already told you the version, API, or approach, use it directly. Do not turn around and question an established condition.
Where to verify (source hierarchy)
Prefer sources with high authority and version alignment over generic searches. In order:
- Installed source code / changelog / lockfile—what actually exists in the project. Highest authority: it is the exact version currently in effect. The lockfile pins the version number, and the installed package source code is the real API. If there is currently no project context (pure Q&A, no repo to check), this layer does not apply; start directly from layer 2.
- Official documentation—via an MCP server or the project's own
llms.txt(if available), otherwise check the official documentation site. Verify whether the version described in the documentation matches the installed version. - Web search—last resort, used to fill in what the first two cannot cover. For how to judge whether what you find is trustworthy, see the next section.
Always align versions. An authoritative answer for the wrong version is still a wrong answer.
What is really being pursued: current best practices
Verification is not "stop once you find an answer that works." The goal iscurrent, recommended, idiomaticpractice, which is also why this skill is called best-practices. "It works" and "this is what should be done now" are two different claims, and satisfying only the former is not enough.
- Timeliness and version matter more than search ranking. The top-ranked result may be years out of date. Check its publication date and the version it targets; yesterday's best practice is often today's anti-pattern (deprecated, changed defaults, old idioms replaced by new approaches).
- Prefer primary sources. Official documentation, release notes, statements by the maintainers themselves, and the repository itself take precedence over SEO blogs and stale Q&A posts. A confidently written blog is not the same as authority.
- Cross-check from multiple sources; do not look only at the first result. Especially for "best practices" questions, opinions often diverge; before putting something into practice, cross-verify across sources and check it against the official position.
- Do not search to confirm a conclusion you already hold. If you are already half-convinced of an answer, a biased query will only feed you "agreement." Search neutrally and let the results correct you; that is the point of verification.
What this skill deliberately does not do
It does not build a knowledge base, nor cache verification results. Existing memory systems already persist genuinely reusable, project-related facts; leave it to them. Do not reinvent the wheel, and do not cache version-sensitive facts—those facts will themselves become outdated, and trusting them after they are outdated is even more dangerous. Verify when verification is needed, and move on once done.