How do I install the Dep Check skill?

Run npx skillmds@latest add jrittelmeyer/dep-check in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Dep Check safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Dep Check?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Dep Check free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Dep Check?

jrittelmeyer (@jrittelmeyer) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Dep Check by jrittelmeyer — Agent Skill

Name: Dep Check
Author: jrittelmeyer

Dep Check

Registry-verify a dependency before adding or upgrading it — check the real published version, tags, and release age; enforce a release-age window; exact-pin frequent publishers; sanity-check peers and maintenance. Use when adding or bumping a dependency, picking a version, or triaging a Renovate/Dependabot PR. Never pick versions from blog posts or model memory.

jrittelmeyer a506923 2 files · 7.4 KB Updated Sep 17, 2026

File contents

dep-check

Model memory and blog posts are stale the day they're written; the package registry is the only source of truth for what a dependency's current version is. This skill front-loads a two-minute check that prevents the expensive failure modes: installing a just-published broken release, a prerelease masquerading as current, an abandoned package, or a silent breaking major.

Adapter: .claude/ai-dev-kit.config.json (depPolicy, ecosystem, legacy packageManager); defaults: 7-day window, judgment-based pinning.

1. Query the registry, not the web

Use the adapter's ecosystem.registryQuery when set; otherwise the per-ecosystem recipes in references/registries.md (npm-family · PyPI · crates.io · Go · NuGet · Maven · RubyGems · Composer · engine asset stores) — pick the section for the repo's manifest files.
Get three facts: the current stable version, the tag/channel landscape (latest can lag or lead; next/beta/canary/pre-releases must never be installed by accident), and the candidate's publish date.
One registry query beats any number of web searches for "what's the latest X".

2. Apply the release-age window

Prefer the newest version older than the window (default ~7 days, adapter depPolicy.releaseAgeDays). A just-published release can still be unpublished, yanked, broken, or — worst case — hijacked; a week of ecosystem soak is cheap insurance.
Exception: the newer release contains a fix you specifically need → take it and say so explicitly in the commit/PR body.

3. Pin policy

Exact-pin packages that publish frequently (adapter depPolicy.exactPin, plus judgment: multiple releases per month → pin exact) — a loose range on a fast publisher makes every fresh install a lottery.
Otherwise follow the project's prevailing range style (read a few neighbors in the dependency manifest).

4. Sanity checks before installing

Peers/host range: the package's declared peer or host-framework ranges vs what the project has installed.
Deprecation: the registry's deprecation/yank flag — a deprecated package needs a replacement, not an install.
Maintenance: last-publish date and repo activity as an abandonment proxy.
Graceful degradation: if the dep introduces an env-gated integration, the project must still build and run with that env unset — verify it.

5. Renovate / Dependabot PR triage

Re-check release age at merge time, not PR-open time.
Read the changelog/release notes for breaking changes on any major (and on fast-moving minors).
Check the project's memory/docs for standing holds before merging a major — some majors are deliberately gated on an upstream event; merging them early re-breaks a settled decision.

6. Record the decision

State in the commit/PR body: the version chosen, the pin style, the release date, and why (window respected / fix-needed exception / hold respected).

---name: dep-checkdescription: Registry-verify a dependency before adding or upgrading it — check the real published version, tags, and release age; enforce a release-age window; exact-pin frequent publishers; sanity-check peers and maintenance. Use when adding or bumping a dependency, picking a version, or triaging a Renovate/Dependabot PR. Never pick versions from blog posts or model memory.---# dep-checkModel memory and blog posts are stale the day they're written; the packageregistry is the only source of truth for what a dependency's current versionis. This skill front-loads a two-minute check that prevents the expensivefailure modes: installing a just-published broken release, a prereleasemasquerading as current, an abandoned package, or a silent breaking major.Adapter: `.claude/ai-dev-kit.config.json` (`depPolicy`, `ecosystem`, legacy`packageManager`); defaults: 7-day window, judgment-based pinning.## 1. Query the registry, not the web- Use the adapter's `ecosystem.registryQuery` when set; otherwise the per-ecosystem recipes in [references/registries.md](references/registries.md) (npm-family · PyPI · crates.io · Go · NuGet · Maven · RubyGems · Composer · engine asset stores) — pick the section for the repo's manifest files.- Get three facts: the current stable version, the tag/channel landscape (`latest` can lag or lead; `next`/`beta`/`canary`/pre-releases must never be installed by accident), and the candidate's **publish date**.- One registry query beats any number of web searches for "what's the latest X".## 2. Apply the release-age window- Prefer the newest version **older than the window** (default ~7 days, adapter `depPolicy.releaseAgeDays`). A just-published release can still be unpublished, yanked, broken, or — worst case — hijacked; a week of ecosystem soak is cheap insurance.- Exception: the newer release contains a fix you specifically need → take it and say so explicitly in the commit/PR body.## 3. Pin policy- Exact-pin packages that publish frequently (adapter `depPolicy.exactPin`, plus judgment: multiple releases per month → pin exact) — a loose range on a fast publisher makes every fresh install a lottery.- Otherwise follow the project's prevailing range style (read a few neighbors in the dependency manifest).## 4. Sanity checks before installing- **Peers/host range:** the package's declared peer or host-framework ranges vs what the project has installed.- **Deprecation:** the registry's deprecation/yank flag — a deprecated package needs a replacement, not an install.- **Maintenance:** last-publish date and repo activity as an abandonment proxy.- **Graceful degradation:** if the dep introduces an env-gated integration, the project must still build and run with that env unset — verify it.## 5. Renovate / Dependabot PR triage- Re-check release age *at merge time*, not PR-open time.- Read the changelog/release notes for breaking changes on any major (and on fast-moving minors).- **Check the project's memory/docs for standing holds** before merging a major — some majors are deliberately gated on an upstream event; merging them early re-breaks a settled decision.## 6. Record the decisionState in the commit/PR body: the version chosen, the pin style, the releasedate, and why (window respected / fix-needed exception / hold respected).

Frequently asked questions