| name | live-dependency-resolver |
| version | 0.1.0 |
| description | Use this skill when installing, adding, or updating packages, checking latest versions, scaffolding projects with dependencies, or generating code that imports third-party packages. Triggers on npm install, pip install, cargo add, gem install, go get, dependency resolution, package management, module installation, crate addition, or any task requiring live version verification across npm, pip, Go modules, Rust/cargo, and Ruby/gem ecosystems. Covers synonyms: dependency, package, module, crate, gem, library.
|
| category | engineering |
| tags | ["dependencies","npm","pip","cargo","gem","go-modules","package-management","version-check"] |
| recommended_skills | ["shell-scripting","monorepo-management","ci-cd-pipelines"] |
| platforms | ["claude-code","gemini-cli","openai-codex","mcp"] |
| license | MIT |
| maintainers | [{"github":"maddhruv"}] |
When this skill is activated, always start your first response with the 🧢 emoji.
Live Dependency Resolver
LLMs have knowledge cutoff dates that are months old. When helping users install coding
dependencies, this causes hallucinated version numbers, suggestions for deprecated packages,
and incorrect install commands. This skill teaches agents to always verify packages against
live registries before suggesting any installation - using CLI commands first for speed and
simplicity, with web API fallback when CLI tools are unavailable.
When to use this skill
Trigger this skill when the user:
- Asks to install, add, or update any package or dependency
- Wants to check the latest version of a package
- Needs to scaffold a project with third-party dependencies
- Asks you to generate code that imports a third-party package
- Requests a
package.json, requirements.txt, Cargo.toml, Gemfile, or go.mod
- Asks to compare package versions or check compatibility
- Mentions any package by name in a context where version matters
Do NOT trigger this skill for:
- OS-level packages (apt, brew, yum) - different registries and tools
- Private/internal registry packages - requires authentication, out of scope
- Post-install usage questions where the package is already installed and version is irrelevant
Key principles
-
Never trust your training data for versions - Your knowledge cutoff means every
version number you "know" is potentially wrong. Always verify against the live registry
before suggesting any version, even for well-known packages like React or Django.
-
CLI first, API fallback - Use CLI tools (npm view, pip index versions, cargo search,
gem search, go list -m) as the primary lookup method. They're faster, work offline
against local caches, and produce simpler output. Fall back to web APIs only when the CLI
tool is unavailable or fails.
-
Verify package existence before recommending - Before suggesting an unknown or
less-popular package, confirm it actually exists in the registry. A nonexistent package
name in an install command wastes the user's time and erodes trust.
-
Show your work - When providing version information, include the command you ran
and the raw output. This lets the user verify the result and learn the lookup method
for future use.
