When writing code against an external library, framework, SDK, or API, look up its CURRENT documentation with the context7 MCP tools instead of relying on memory.
NewMaintained
Automatic
◆Coding pack
Last verified 8/18/2026
What it changes
3 of 22 test cases passed with the skill.
Pass-rate lift
—
Tokens
+7%
Agent turns
0%
Response time
-21%
Model gemini-3.6-flashMeasured 8/18/2026v13 of 22 cases passed with skill · 5 comparable
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 5 comparable cases; this report requires 8.
What's inside
The instructions your model reads when the skill loads.
SKILL.md32 linessingle file
Look up real library docs (don't guess the API)
Training data goes stale: library APIs, method signatures, config keys, and best
practices change between versions. Guessing them is a top source of subtly-wrong
code. When you touch an external library/framework/SDK/API, get the CURRENT docs.
How
The context7 MCP server is available. Use its tools:
resolve-library-id — resolve the library name (e.g. "tauri",
"centrifuge-go", "react-query") to its context7 id.
get-library-docs — fetch the up-to-date docs for that id, scoped to the
topic/symbol you need (the specific hook, method, or config option).
Pull the version the project actually depends on — check go.mod /
package.json / Cargo.toml / requirements.txt — not "latest", when they
differ.
When to use it
Calling a method/option you're not 100% sure exists in the version in use.
Wiring up a new dependency, an SDK client, or a framework feature.
An unfamiliar or fast-moving library (cloud SDKs, web frameworks, build tools).
A compile/runtime error that looks like an API mismatch.
When NOT to bother
The standard library or a tiny, stable utility you know cold.
Pure project-internal code — read the repo, not external docs.
Prefer one focused docs lookup over a wrong guess you then have to debug.