external-grounding

name	external-grounding
description	This skill should be used when implementation or review depends on external, version-sensitive facts: libraries, SDKs, APIs, CLIs, cloud services, security advisories, changelogs, release notes, or documentation that may have changed. It anchors local versions, ranks source quality, checks version fit and conflicts, and turns confirmed facts into implementation constraints before code changes.
compatibility	Designed for Claude Code, Codex, Opencode, and Agent Skills-compatible coding agents with file, search, shell, web, and git access. If web access is unavailable, use local package source/types, lockfiles, vendored docs, CLI help/version output, and mark external facts inconclusive when not confirmed.
license	MIT

External Grounding

Model memory is not evidence for external, version-sensitive facts. Old SDK shapes, stale security guidance, renamed CLI flags, and changed cloud APIs can look plausible while being wrong. Use this skill to turn external facts into implementation constraints before code changes.

This skill is not a generic web-search checklist. Its job is to decide whether an external claim is applicable to this project, this version, and this risk level.

Boundary with evidence-gated-review

external-grounding confirms external facts: package versions, SDK method names, API contracts, CLI options, cloud-service behavior, deprecation dates, affected versions, or security guidance.

evidence-gated-review uses those facts to evaluate claims: whether a reviewer is right, whether a bug cause is confirmed, whether a CI failure is explained, or whether a proposed fix closes the risk.

The handoff from this skill should be a set of external constraints. The handoff from evidence-gated review should be a decision about claims, causes, or fixes.

When to use

• Library, SDK, framework, runtime, or CLI behavior may have changed.
• The task depends on official docs, changelogs, release notes, migration guides, deprecation notices, cloud-provider behavior, API schemas, or security advisories.
• Local code and remote docs appear to disagree.
• The user says not to trust model memory, asks for current docs, or mentions stale knowledge risk.
• A security, compatibility, or migration decision depends on affected versions or dates.

When NOT to use

• Stable language basics or pure local code semantics.
• Trivial edits where no external fact changes the answer.
• User-provided specifications that are the source of truth and do not depend on external services or libraries.
• General code review claims that can be proven entirely from local code and tests; use evidence-gated review instead.

Core model

External Surface   the external dependency, API, CLI, service, or security guidance in scope
Stale Risk         why model memory or unversioned docs may be unsafe
Local Anchor       local package/API/runtime/CLI/spec version and where it came from
External Claim     a claim from docs, changelog, source, advisory, issue, or example
Source Quality     authority level and date/version/source notes
Version Fit        whether the claim applies to the local anchor
Conflict Check     docs vs local types/source/runtime/issues/advisories
Runtime Probe      cheap local verification when available
Decision           confirmed / version-mismatched / stale / conflicted / inconclusive
Handoff            implementation constraints, source URLs or local paths, and remaining uncertainty

Use the lightest version of this model that still prevents stale external facts from becoming code.

Workflow

1. Define the external surface

Name the exact external thing being relied on. Keep the scope narrow enough to verify.

Examples:

• @anthropic-ai/sdk message creation API, not "Anthropic docs"
• AWS CLI s3 sync --checksum-mode, not "AWS behavior"
• Cookie SameSite guidance for browser authentication, not "web security"
• A checked-in OpenAPI response schema, not "the API"

If multiple external surfaces matter, handle them as separate claims or batches.

2. Record stale risk

Explain why model memory is unsafe here. Typical reasons:

• The package has recent major releases or migration guides.
• The docs default to latest but the project may not use latest.
• Security guidance depends on affected versions, dates, or deployment context.
• A local type checker, runtime, or CLI rejects what docs appear to allow.
• A cloud provider, SaaS API, or SDK can change outside the repository.

3. Anchor locally first

Before treating remote documentation as applicable, find the local anchor when possible:

• dependency manifest and lockfile version
• installed package source or type definitions
• runtime version, generated client, checked-in schema, vendored docs, or migration guide
• CLI --version / help output
• API version pinned in config, headers, environment, generated code, or docs

If there is no local anchor, record that explicitly. Do not silently substitute "latest".

4. Collect external claims

For each relevant source, write the claim as a narrow statement that could be wrong.

Good:

EG-001: `client.messages.create` accepts `system` as a top-level parameter in @anthropic-ai/sdk v0.x/v1.x.

Bad:

The SDK docs say how to use messages.

5. Rank source quality

Separate applicability from authority.

Local applicability anchors:

1. Installed package source, generated client code, type definitions, lockfile, runtime version, CLI --version or help output
2. Repository-pinned specs or vendored docs, such as OpenAPI schemas, SDK-generated files, checked-in migration guides

High-authority external sources:

3. Official documentation for the exact local version
4. Official API reference for the exact local version
5. Official changelog, release notes, migration guide, deprecation notice
6. Vendor security advisory, GHSA, CVE entry, vendor bulletin, or cloud-provider security notice

Medium-authority sources:

7. Maintainer-authored GitHub issue, PR, discussion, or comment
8. Official examples that declare compatible versions
9. Framework sample apps tied to the target release

Low-authority sources:

10. Blog posts
11. StackOverflow or Q&A answers
12. Tutorials without date or version
13. Docs for latest when the local project is not on latest
14. Remote main branch source unless matched to the installed tag or commit

Unversioned documentation is not automatically current for the local project. Blog posts and Q&A answers are hints, not authority.

6. Check version fit and conflicts

For each claim, compare the source against the local anchor:

• Does the source name the same major/minor version, API version, CLI version, or release range?
• Does a changelog or migration guide say the behavior changed?
• Do local installed types/source agree with the docs?
• Do security advisories list this project as affected or unaffected?
• Do examples declare a compatible version, or are they just current snippets?

Prefer stronger local evidence over remote latest docs when they disagree about what this project can compile or run.

7. Run cheap runtime or type probes when available

If a local probe can confirm applicability without side effects, use it or explain why it was skipped.

Examples:

• inspect installed type definitions or generated clients
• run tsc --noEmit, a tiny compile check, or language-specific type check
• run python -c "import pkg; print(pkg.__version__)"
• run cli --version or cli help <subcommand>
• run a minimal non-network snippet against local code

Do not hit production endpoints, mutate cloud resources, replay payments, or call external services with side effects without explicit user approval. If safe probing is impossible, mark the fact inconclusive or hand it to evidence-gated review with a proposed safe probe.

8. Decide before implementation

Use these labels:

• confirmed — the external claim matches the local anchor and no stronger counter-evidence was found.
• version-mismatched — the claim may be true for another version, but not for the local package/API/CLI/runtime.
• stale — the source predates a relevant release, migration, advisory, or deprecation, or lacks date/version information for a time-sensitive fact.
• conflicted — credible sources disagree, or docs and local types/runtime disagree.
• inconclusive — the needed fact could not be verified with available tools, network, or evidence.

Only confirmed claims become implementation constraints. version-mismatched, stale, conflicted, and inconclusive claims must not be used as if true.

Promotion rule

Do not promote an external claim into an implementation constraint unless:

• the local anchor is known, or the absence of a local anchor is explicitly recorded
• the source has enough authority for the risk level
• the source version/date fits the local project
• stronger local evidence does not contradict it
• conflicts are resolved or marked conflicted
• any cheap local probe has been run, or the reason it was skipped is stated

No-network fallback

If web access is unavailable, use local anchors first: lockfiles, installed package source/types, vendored docs, CLI version/help output, generated clients, OpenAPI specs, README files, and changelogs already present in the repository.

If the needed external fact still cannot be confirmed, mark it inconclusive instead of relying on model memory.

Output format

Use this structure for standard grounding. For small tasks, keep it concise but preserve the same decisions.

External grounding
- External surface:
- Stale risk:
- Local anchor:

Claims
- EG-001:
  Claim:
  Source:
  Source quality:
  Version fit:
  Conflict check:
  Runtime/type probe:
  Decision:

Implementation constraints
- Use:
- Do not use:
- Required migration or compatibility note:
- Verification needed during execution-loop:

Handoff
- Confirmed facts:
- Conflicted or inconclusive facts:
- URLs / local paths:

Handoff to other skills

When implementation is next, hand off to execution-loop with Use / Do not use / Verification needed constraints.

When a bug cause, review comment, CI failure, or security claim still needs proof, hand off to evidence-gated-review with the confirmed external facts and the unresolved claims.

Stop condition

This skill is complete when:

• every external surface in scope has a local anchor or explicit missing-anchor note
• important external claims have source quality, version fit, conflict check, and decision
• only confirmed claims are listed as implementation constraints
• stale, version-mismatched, conflicted, or inconclusive facts are clearly separated from usable facts

Do not proceed as though a fact is current merely because it matches model memory.