context7-usage

name	context7-usage
description	Context7 MCP documentation retrieval patterns for up-to-date library and API references. Use this skill whenever current library docs, API signatures, version-specific behavior, or migration notes are needed.
version	2.0.0

Provide consistent, efficient usage patterns for Context7 MCP so agents can retrieve current documentation and avoid stale API assumptions. Context7 covers thousands of libraries with live documentation. mcp__plugin_claude-code-home-manager_context7__resolve-library-id - Resolve library names to Context7-compatible IDs before fetching docs mcp__plugin_claude-code-home-manager_context7__query-docs - Fetch focused documentation for specific topics, versions, or APIs

<when_to_use> User asks about a library's API, config options, or best practices Code references an external dependency and current behavior needs verification Migrating between library versions (check breaking changes) Debugging "why doesn't this API work" — verify against current docs before assuming a bug ANY time you'd otherwise rely on training-data memory for library syntax </when_to_use>

Resolve the library to a Context7-compatible ID mcp__plugin_claude-code-home-manager_context7__resolve-library-id Library ID string (e.g., /microsoft/typescript, /nixos/nixpkgs) Fetch targeted documentation with a specific topic mcp__plugin_claude-code-home-manager_context7__query-docs Current documentation for the requested topic

<known_library_ids> Pre-resolved IDs for frequently used libraries in this repository. Use these directly without calling resolve-library-id. </known_library_ids>

Standard two-step: resolve library ID, then fetch docs with a focused topic. Step 1: resolve-library-id for "typescript" → returns "/microsoft/typescript" Step 2: query-docs context7CompatibleLibraryID="/microsoft/typescript" topic="tsconfig moduleResolution nodenext" When behavior differs by version, specify the version in the topic or use a versioned library ID. query-docs id="/microsoft/typescript" topic="TypeScript 6.0 breaking changes module resolution" query-docs id="/nixos/nixpkgs" topic="buildGoModule Go 1.26" Before upgrading a dependency, check migration notes. query-docs id="/microsoft/typescript" topic="TypeScript 5 to 6 migration breaking changes" query-docs id="/rust-lang/rust" topic="Rust edition 2021 to 2024 migration" For nixpkgs language packaging (buildGoModule, rustPlatform, etc.), always use Context7. query-docs id="/nixos/nixpkgs" topic="buildGoModule vendorHash cargoHash" query-docs id="/nixos/nixpkgs" topic="rustPlatform.buildRustPackage importCargoLock"

<decision_tree name="context7_usage"> Do you need current library/framework API behavior? Use known_library_ids list for direct query-docs call Call resolve-library-id first, then query-docs Use Serena or Read/Bash tools instead </decision_tree>

<best_practices> Always use Context7 before making claims about external library APIs — training data may be stale Use specific topic strings (not generic) for focused, relevant results Check migration docs when upgrading library versions For nixpkgs language packaging, Context7 is the authoritative source — use it before writing any derivation Prefer known library IDs to avoid resolve step when possible </best_practices>

<anti_patterns> Assuming API behavior from training data without retrieval Always query Context7 for any library syntax, config options, or behavior questions Using overly broad topic strings ("typescript docs", "rust docs") Be specific: "TypeScript 6.0 verbatimModuleSyntax", "Rust async fn in trait 1.75" Guessing library IDs without using resolve-library-id Use known_library_ids for common libraries, resolve-library-id for unknown ones </anti_patterns>

Keep guidance evidence-based and version-aware — retrieve before claiming Use Context7 for ANY external library API claim; never rely on training-data memory alone Prefer project conventions over generic defaults from docs Specify the exact version when querying version-sensitive behavior

<error_escalation inherits="core-patterns#error_escalation"> Library ID not found — try alternative name or resolve-library-id Context7 returns empty or irrelevant results — refine topic string Conflicting information between Context7 and local code — flag for investigation Unsafe or misleading API guidance affecting security or correctness </error_escalation>

Use resolve-library-id before query-docs when library ID is not in known_library_ids Prefer official or primary documentation sources State uncertainty when docs are unavailable or ambiguous Relying on stale memory of API signatures without retrieval Generic topic strings that return unfocused results

<related_skills> Use with external verification workflows for non-library claims Use for project-local evidence gathering (complement, not substitute) For nixpkgs packaging queries — always pair with Context7 </related_skills>

<related_agents> Use for local codebase context before external doc lookup Use for synthesis when multiple doc sources conflict Cross-validates claims retrieved from Context7 against project code </related_agents>