メニュー
Manages third-party dependencies safely — vetting, pinning, updating, and supply-chain risk. Use when adding a library, upgrading or removing one, reacting to a security advisory, auditing what a project pulls in, or reviewing a PR that changes the dependency tree.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Meta-skill that routes a task to the right engineering skill. Load this at the start of a session or when unsure which skill applies — it maps intent to the process that should govern the work.
Catches breaking changes between services before they ship, by testing the contract each consumer actually depends on instead of spinning up the whole system. Use when services deploy independently, when a provider API change could break a consumer, or when end-to-end integration tests are too slow and flaky to guard every service boundary.
Proves whether a change actually moves the metric, with a valid A/B test instead of a guess — a hypothesis, a primary metric, a pre-computed sample size, guardrail metrics, and an honest readout. Use when shipping a change meant to improve a number (conversion, retention, performance), running an A/B or holdout, or deciding whether a feature "worked."
Decouples deploy from release using feature flags — ship code dark, roll out gradually, kill instantly, and remove the flag once it's done. Use when releasing risky or large changes, rolling out by percentage/cohort, delivering A/B variants, or when stale flags are accumulating as debt.
Finds security risks at design time — before code exists — by mapping the system, enumerating how it could be attacked, and deciding what to do about each threat. Use when designing a feature that touches auth, data, money, or external input, when changing a trust boundary, or when a security-sensitive change needs a structured risk pass rather than a code-level review.
Designs durable, curated memory that an agent carries across sessions — what to persist, how to scope and retrieve it, and how to stop it from drifting or poisoning later runs. Use when an agent needs to remember decisions, preferences, or project facts beyond one context window, or when stale/over-generalized memory is corrupting its behavior.
| name | dependency-hygiene |
| description | Manages third-party dependencies safely — vetting, pinning, updating, and supply-chain risk. Use when adding a library, upgrading or removing one, reacting to a security advisory, auditing what a project pulls in, or reviewing a PR that changes the dependency tree. |
Every dependency is code you didn't write running with your privileges — plus every transitive package it pulls in. It's leverage and liability at once: you ship faster, but you inherit bugs, breaking changes, license obligations, and supply-chain attack surface.
Treat dependencies like hiring: justify the need, vet before adopting, pin for reproducibility, review on a cadence, and remove what you no longer use. Panic upgrades under a CVE deadline are expensive; small regular updates are cheap.
Pairs with [[hardening]] for vulnerability response, [[pipeline-ops]] for CI gates and reproducible builds, [[version-upgrade]] for researched version bumps, [[migration-path]] for breaking upgrades that affect callers, [[review-gate]] when reviewing dependency PRs, [[simplify]] when deciding to own code instead of import it, and [[decision-docs]] when a dependency choice is hard to reverse (core framework, datastore driver, auth library).
npm audit, OSV, GitHub Dependabot alert)package.json, requirements.txt, go.mod, Cargo.toml, etc.Skip for vendored code you fully control with no package manager entry, or trivial config-only changes with no dependency tree impact. Still apply when the "config" pulls a new tool into CI.
Work in order. Don't add to the lockfile until justification and vetting pass.
Ask "do we need a package for this?" first ([[simplify]]).
| Prefer owning | Prefer a dependency |
|---|---|
| A few lines of stable logic | Complex, security-sensitive domain (crypto, auth) |
| Standard library covers it | Well-maintained standard for the ecosystem |
| One-off transform with no edge cases | Active maintenance burden you'd carry forever |
| Already have a dep that does it | Dep is the de facto standard (test runner, linter) |
A one-function package (is-odd, left-pad) is rarely worth a new supply-chain edge. A wrong choice
in auth, ORM, or HTTP client is costly to unwind — justify and record ([[decision-docs]]).
Removing is hygiene too. Dead dependencies still get audited, scanned, and confused about in reviews. Delete unused deps in the same PR that stops using them.
Run this checklist before the first install. For upgrades, re-check if the package changed
maintainers, license, or major behavior.
Maintenance & trust
License
Footprint
npm ls, pip show, go mod graph)bundlephobia, build diff)Security history
Fit
Reject or escalate: unmaintained, license unclear, huge transitive tree for a trivial helper, suspicious publish history, or duplicate of an existing dep.
The lockfile is the contract. Everyone — dev, CI, production build — must resolve the same tree.
package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock,
Cargo.lock, go.sum, etc.)npm ci, pip install -r requirements.txt from lock, etc.)^ / >=) without a lockfile — builds drift silentlyDocument the install command in README or CI config. "Works on my machine" often means different lock states.
For applications: lock everything. For libraries published to others: follow ecosystem conventions
(often wider ranges in package.json but lock in dev/CI).
Fewer, well-chosen dependencies beat a pile of overlapping ones.
lodash and underscoreimport { x } from 'lib/x' not whole-barrel when it mattersfetch, crypto, standard library before polyfill packagesWhen two deps conflict (duplicate transitive versions), resolve explicitly — overrides/resolutions are
a conscious choice with a reason, not a silent npm install --force.
Regular small upgrades beat annual "dependency week" or emergency CVE fire drills.
Cadence suggestion:
| Tier | Examples | Cadence |
|---|---|---|
| Security patch | CVE fixes | As soon as vetted + CI green |
| Patch/minor | bug fixes, safe minors | Weekly–monthly automated PRs |
| Major | framework majors | Planned sprint with migration plan |
| Dev-only | linters, test tools | Keep reasonably current; less urgent |
After upgrade: run full test suite, smoke critical paths, watch production after deploy ([[launch-readiness]]).
Security scan is a merge gate, not a quarterly spreadsheet ([[pipeline-ops]]).
npm audit, pnpm audit, pip-audit, cargo audit, govulncheck, OSVScan results are starting points. Verify:
Dependencies are a top attack vector — typosquats, compromised publishes, malicious postinstall scripts.
Before merge / on alert:
react-dom vs react_dom) is commonignore-scripts in CI where safenpm, pnpm, cargo) enabled; review lockfile diffs in PRsIn PR review ([[review-gate]]), a lockfile-only change with thousands of lines needs scrutiny — not rubber-stamp. Unexpected new packages or version jumps on trusted names warrant a web search.
Runtime: dependencies don't get secrets from your env unless you give them. Minimize env exposure in CI scripts that install packages.
A dependency PR is not "just a version bump."
Check:
Approve when justified, vetted, and verified — not when "it's just a dep."
Add a new dependency
CVE / advisory response
Major version upgrade
Audit existing tree
Monorepo / polyglot