dependency-policylisted

# Dependency & Supply-Chain Policy ## Activation Scope - Apply whenever a dependency is added, upgraded, removed, or audited, and when editing package manifests, lockfiles, or CI/build steps that fetch dependencies. - This skill owns third-party dependency and supply-chain risk. Runtime application security is owned by security-policy; commit/PR mechanics by git-policy. --- ## Add Dependencies Deliberately - Prefer the standard library or existing project utilities before adding a dependency. - Justify every new dependency: real need, active maintenance, healthy adoption, compatible license, and acceptable transitive footprint. - Avoid trivial micro-packages that add supply-chain surface for little value; a small amount of owned code can beat a risky dependency. - Watch for typosquatting and confusable names; verify the exact package name, owner, and repository before installing. --- ## Pin & Reproduce - Always commit the lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, etc.); it is the source of truth for what actually installs. - Use reproducible, locked installs in CI and release (e.g. `npm ci`, not `npm install`), so builds are deterministic. - Pin versions deliberately; avoid loose ranges for anything security-sensitive. Upgrade intentionally, not implicitly. - Keep one package manager per project; do not mix lockfiles from different managers. --- ## No Fragile Remote Dependencies - Do not depend on code fetched from arbitrary remote URLs o