AgentSkillsCN

check-deps

验证项目依赖项是否使用最新的稳定版或 LTS 版本。将实际安装的版本与当前可用版本进行比对。适用于添加依赖项、升级软件包,或当 Claude 引用某个库的 API 时使用。当正在添加依赖项,或当库的使用模式可能已经过时时,该功能会自动激活。

SKILL.md
--- frontmatter
name: check-deps
description: >-
  Verifies that project dependencies use the latest stable or LTS versions. Checks actual
  installed versions against what is currently available. Use when adding dependencies,
  upgrading packages, or when Claude references a library API. Activates when dependencies
  are being added or when library usage patterns may be outdated.
allowed-tools: Read, Bash, Glob, Grep, WebSearch, WebFetch
<!-- NOTE: This skill intentionally allows model invocation (auto-activation) so Claude checks versions whenever dependencies are added or used. -->

Check Dependencies

The principle: never assume library versions or API signatures from training data. Your training data has a cutoff — always verify against the registry. See "Dependencies and Versions" in the project's CLAUDE.md for the full policy. This skill provides the mechanics.

When to Check

  • Before adding a new dependency to the project.
  • When writing code that uses a library's API and you are not 100% certain of the current API surface.
  • When the user asks you to check or update dependencies.
  • When you notice a dependency that looks outdated during research.

How to Check

  1. Read the dependency manifest. Identify the currently installed version.

    • package.json / package-lock.json (Node.js)
    • go.mod (Go)
    • Cargo.toml / Cargo.lock (Rust)
    • requirements.txt / pyproject.toml / poetry.lock (Python)
    • pom.xml / build.gradle (Java)
    • *.csproj / Directory.Packages.props (C#/.NET)
    • Or whatever dependency manifest exists for the project's ecosystem.
  2. Check the latest stable/LTS version. Use the appropriate method:

    • npm view {package} version (Node.js)
    • go list -m -versions {module} (Go)
    • cargo search {crate} (Rust)
    • pip index versions {package} (Python)
    • Search the web for the latest release if CLI tools are unavailable.
  3. Compare and report. If the installed version is significantly behind, flag it. If you are adding a new dependency, use the latest stable version — not whatever version your training data remembers.

  4. Verify API compatibility. If upgrading a dependency, check the changelog or migration guide for breaking changes. Do not blindly upgrade and assume the API is the same.

<example title="Checking a Node.js dependency"> # 1. Read what's installed # package.json shows: "express": "^4.18.2"

2. Check what's current

$ npm view express version

Returns: 5.1.0

3. Compare — major version behind (4.x → 5.x), this is significant

Express 5 has breaking changes: removed app.del(), changed path matching

4. Report to user:

"Your project uses Express 4.18.2, but Express 5.1.0 is the latest.

This is a major version jump with breaking changes — the path matching

engine changed and several deprecated methods were removed.

I'd recommend staying on 4.x for now unless you want to plan a migration.

For a new project, I'd start with 5.x."

</example> <rules> - Never hardcode a version number from memory. Always verify against the registry or official documentation. Your training data may be months or years out of date. - When in doubt, check the official documentation or registry. - Prefer LTS versions over bleeding-edge when both exist (e.g., Node.js LTS). - If a major version upgrade introduces breaking changes, inform the user and discuss before upgrading. - Do not downgrade dependencies without explicit user approval. </rules>