What the standard is (why it's called that)
What this skill requires iscurrent best practice—the approach that is recommended and adopted now, not merely an answer that runs. These are three different claims:
- Correct / runs—it compiles and returns the correct value.
- Not outdated—it doesn't use anything deprecated.
- Best practice / idiom—it's what maintainers and the community recommend today.
Agents most easily fail silently at the highest level: the code runs, so it's shipped straight away, yet it's built on outdated APIs or non-idiomatic style. It passes "is it correct" but fails "should it be done this way now."Closing that 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 way"—is a means to that end. The skill's name is the goal itself, not a label.
Why it's hard, and where judgment shows
Reaching this standard on memory alone is hard. Training knowledge has a cutoff and gets fuzzy on version details. In fast-changing areas—frameworks, SDKs, toolchains, idioms—you willconfidently give the wrong answer, 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 the web" itself; that principle already exists in the standing rules. What it addresses is the hard scenarios where models tend to fail: anticipating your own blind spots, recovering gracefully after being shown to be wrong, and making sure what ultimately lands is 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're worth something but not fully reliable. In scenarios where the stakes aren't low, treat them as prompts to verify:
- Version-sensitive or time-varying facts: the API surface, CLI flags, config schema, environment variables of some library/framework/SDK, or whether a feature is deprecated.
- Fast-changing areas: areas where the correct answer has changed over the past year or two.
- "Best practice / idiom"-type questions: the question itself implies the answer is a matter of convention and drifts over time, which is exactly where outdated knowledge most easily gives itself away.
- Before writing non-trivial code against an external API: don't write it straight from memory; confirm the interface's current state first.
External signals—reality has already told you you're wrong (highest weight)
These areEstablished fact, not a 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 does not 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 repeatedly fails, the fix does not work, and you find yourself repeatedly trying variants on the same idea. This is likewise an established fact, sometimes more objective than the other party's emotions, because it carries no emotion, only a hard fact that refuses to cooperate.
Once an external signal appears, its weight is at the highest level. Do not make excuses for it. "You are wrong" has only two sources—the other party tells you directly, or reality refuses to cooperate, and both outweigh 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 very same memory or assumption that was 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 repeatedly fails.
Once you are told you are wrong, whether by the other party or by repeated failure, stop relying on the same set of memories and assumptions. Verify first, then act. The information source that just produced the wrong result is not trustworthy to produce the right result again. Go obtain solid evidence.
Triage first, then react (do not 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"; it does not tell you "specifically what is wrong." Classify first, and start with the lowest-cost check:
| Error type | Manifestation | Correct response |
|---|---|---|
| Understanding / instruction error | Did not do what the other party asked, misunderstood the requirement, changed the wrong place, over-engineered | Read the requirement and context again. 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 against authoritative sources(the case for searching). |
| Repeated failure | The same test / build / command repeatedly fails, the fix does not work | Stop; do not repeat the same guess. First check whether your own reasoning is based on outdated knowledge (verify the current API / configuration). If it is not a knowledge gap,escalate to a systematic debugging process, because continuing to guess is useless. |
Re-reading local context is low-cost and has no side effects; when unsure, do this step first. 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 verifiable locally: if the answer is in the installed source code, lockfile, or a local changelog, read it directly; do not go online to search for something already available 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 highly authoritative, version-aligned sources 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 the parts the first two cannot cover. For how to judge whether what you find is trustworthy, see the next section.
When the verification workload is large (multiple topics, cross-checking multiple sources), you can dispatch background subagents to read, keeping the main thread moving—the cost constraint on verification should not become a reason not to verify.
Always align versions. An authoritative answer for the wrong version is still a wrong answer.
Hierarchy of evidence: real-world practice > tests > claims
When judging "what approach is correct," evidence falls into three tiers; when tiers conflict, trust the higher tier:
- Large-scale real-world survival evidence— approaches repeatedly chosen and retained by a large number of real users in high-stakes scenarios (years surviving in production, install base, real-world retrospectives). No test can construct the real-world distribution: a test is you constructing samples to spot-check reality; real-world practice is reality spot-checking you. When leaderboard scores and real-world reputation conflict, trust real-world practice.
- Controlled test evidence— benchmarks, experiments, self-tests. Valuable, but only covers the situations you thought of.Using a few self-tests to refute large-scale real-world practice is the most typical misuse of this tier.
- Claims and reasoning— what documentation says, what blogs write, what you deduce yourself. Without backing from the first two tiers, these are merely propositions to be verified.
Add a firewall: survival evidence must pass a survivorship-bias check—a large install base may also be marketing and default effects, but "long-term, high-stakes survival" is still the strongest signal available.
What you should really pursue: the current best practice
Verification is not "find an answer that works and call it done." The goal is thecurrent, recommended, idiomaticapproach, which is also why this skill is called best-practices. "It works" and "this is what you should do 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 (deprecations, changed defaults, old idioms replaced by new ways).
- Prefer primary sources. Official docs, 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 authoritative. The yardstick for judging what is primary:Whoever owns the claim, go verify it with them—API behavior belongs to the maintainer's repository and docs, platform rules belong to the platform's official pages, and someone's opinion belongs to their own original text.
- Corroborate across multiple sources; don't just look at the first result. Especially for "best practices"-type questions, opinions often diverge; before acting, cross-verify across sources and check against the official position.
- Don't search to confirm a conclusion you already hold. If you already half-believe some answer, a biased query will only feed you "agreement." Search neutrally and let the results correct you—that is the whole point of verification.
What this skill deliberately does not do
It does not build a knowledge base, nor does it cache verification results. Existing memory systems already persist genuinely reusable, project-related facts—leave that to them. Don't reinvent the wheel, and don't cache version-sensitive facts; those facts will themselves go out of date, and being trusted while outdated is even more dangerous. Verify when it's time to verify, and move on once done.
There is one boundary to keep clear: when a verification conclusion is meant to support a deliverable (spec, report, decision), write the conclusiontogether with its sourcesinto that task's working document (when the workspace uses the .issues/<YYYY-MM-DD-主题>/ draft directory, put it there. Before writing to disk, first make sure the draft directory is ignored:git check-ignore .issues If it fails, append .issues/ to .git/info/exclude(ignore locally, don't touch the shared .gitignore) and tell the user in one sentence. In a non-git environment there is no commit risk, so write directly.), letting the citations travel with the deliverable—this is not a cached knowledge base; the document belongs to that task and is archived with the task once it expires.