| 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.1 |
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 libraryId="/microsoft/typescript" query="tsconfig moduleResolution nodenext"
When behavior differs by version, specify the version in the topic or use a versioned library ID.
query-docs libraryId="/microsoft/typescript" query="TypeScript 6.0 breaking changes module resolution"
query-docs libraryId="/nixos/nixpkgs" query="buildGoModule Go 1.26"
Before upgrading a dependency, check migration notes.
query-docs libraryId="/microsoft/typescript" query="TypeScript 5 to 6 migration breaking changes"
query-docs libraryId="/rust-lang/rust" query="Rust edition 2021 to 2024 migration"
For nixpkgs language packaging (buildGoModule, rustPlatform, etc.), always use Context7.
query-docs libraryId="/nixos/nixpkgs" query="buildGoModule vendorHash cargoHash"
query-docs libraryId="/nixos/nixpkgs" query="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>