Context7 Usage

Retrieve before claiming. Any statement about an external library's API, configuration, or behavior comes from a fetch, never from training-data memory: the memory is confident, plausible, and dated.

Two tools: resolve-library-id turns a library name into a Context7 ID; query-docs fetches for a specific topic. Skip the resolve step when the ID is already known.

When

• The question is about a library's API, config options, or recommended usage.
• Code references an external dependency whose current behavior needs confirming.
• A version upgrade is in scope: check the migration notes before writing the change.
• Debugging "why doesn't this API work": verify against current docs before concluding it is a bug.
• Writing a nixpkgs derivation with a language builder. Context7 against /nixos/nixpkgs is the authoritative source for buildGoModule, rustPlatform.buildRustPackage, and their hash attributes.

For project-local evidence, use Serena or Read instead: Context7 answers what the library does, not what this repository does.

Query specifically

A broad topic string returns unfocused results and invites the model back onto its own recall.

query-docs libraryId="/microsoft/typescript" query="tsconfig moduleResolution nodenext"
query-docs libraryId="/nixos/nixpkgs"        query="buildGoModule vendorHash"
query-docs libraryId="/rust-lang/rust"       query="Rust edition 2021 to 2024 migration"

Name the version explicitly whenever behavior differs across versions: the answer to "does this API exist" is version-dependent and a version-free query gets an answer for some version nobody chose.

Known IDs

Use directly, without resolving.

Reading the result

Prefer official or primary documentation over derived material. State uncertainty plainly when the docs are unavailable or ambiguous rather than filling the gap from recall: an unavailable doc is a gap to report, not a prompt to guess.

Where Context7 and the local code disagree, that is a finding to investigate, not a conflict to resolve by preferring one. And project conventions outrank generic defaults from docs: the documentation says what is possible, the repository says what is done here.

A returned API shape may come from a pre-release channel the project does not use. An indexed library often carries docs for a release candidate alongside its stable line, and the retrieved snippet does not announce which one it belongs to: a renamed constructor or a moved import path reads as the current API when it is the next one. Check the returned shape against the version actually installed (the lockfile, not the manifest range) before writing code from it. Where they differ, that disagreement is the finding, and the lockfile wins.

Related

• fact-check: external verification for non-library claims
• serena-usage: project-local evidence, a complement rather than a substitute
• nix-ecosystem: nixpkgs packaging, always paired with a Context7 fetch