managing-dependencies

Governs adding, bumping, and pinning npm dependencies under pnpm supply-chain policies.

Updated Sep 15, 2026
One-click install
npx skills add https://github.com/tomada1114/quick-reply-drill --skill managing-dependencies-tomada1114
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: managing-dependencies
Source: https://github.com/tomada1114/quick-reply-drill/tree/main/.agents/skills/managing-dependencies
Command: npx skills add https://github.com/tomada1114/quick-reply-drill --skill managing-dependencies-tomada1114

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Adding or bumping a package in this repository is a permanent supply-chain commitment, and the pnpm configuration enforces strict gates — a release-age cooldown, install-script rulings, strict peer ranges, and a TypeScript version ceiling — that fail installs in ways that are easy to misdiagnose. This Skill tells you exactly what review record a new runtime dependency needs, how to verify a change before it lands, and what each policy failure actually means. ## Core Features & Use Cases - Dependency review checklist: Records why a builtin cannot replace the package, maintainer continuity, license compatibility, transitive surface, install scripts, and which dependency field it belongs in. - Verification workflow: Runs pnpm install, check:quick, build, and coverage in order, plus the targeted module test suite that surfaces a bump first. - Policy interpretation: Explains minimumReleaseAge cooldown behavior, allowBuilds rulings, strictPeerDependencies exceptions, and the manual pin process for .mcp.json's MCP server. - Use Case: When pnpm install fails because a freshly published version violates the release-age cooldown, use this Skill to understand the failure and either wait, pick an older range, or follow the documented exception process. ## Quick Start Ask the AI to review whether a specific package may be added to package.json and what verification steps the change requires before landing.

Frequently Asked Questions about managing-dependencies

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new runtime dependency to a pnpm project?▼

Add it with pnpm add, never by hand-editing package.json, and record a review covering maintainer status, license, transitive package count, install scripts, and which dependency field it belongs in. Commit the manifest and regenerated pnpm-lock.yaml together.

Why does pnpm install fail on a freshly published package version?▼

The minimumReleaseAge cooldown in pnpm-workspace.yaml blocks versions published too recently. A SemVer range silently resolves to an older cooled version, while an exact pin on a young version fails outright; urgent security fixes need a documented minimumReleaseAgeExclude exception.

Should dependencies use SemVer ranges or exact pins?▼

Runtime dependencies declare SemVer ranges, never exact pins, because a range plus pnpm-lock.yaml reproduces the install and gives the release-age cooldown an older version to fall back to. The one exception is .mcp.json's MCP server, which needs an exact manual pin since it sits outside pnpm's graph.

Why does a dependency install script fail the pnpm install?▼

strictDepBuilds with allowBuilds intentionally fails installs when a dependency runs an unreviewed lifecycle script. Each entry in allowBuilds records a ruling on what the script does and whether it is needed; both true and false are deliberate decisions.

Can I upgrade TypeScript to the latest version?▼

No. typescript is capped by typescript-eslint's peer range, which limits at a minor version, and strictPeerDependencies turns exceeding it into an install failure. Raising the ceiling is a coordinated upgrade that waits for typescript-eslint to raise its own peer range first.