update-deps

Move a repo's dependencies to their newest allowed versions — minor by default, patch or major only when explicitly asked. Manual invocation only. The skill plans first and writes only after confirmation, and it never commits, pushes, opens a PR or merges — the verified working tree is the deliverable (why).

Its one principle, from which everything else follows:

The repo's own tooling and config decide what "allowed" means. A release-age gate, an exact pin, a declared constraint, a private registry — each is a deliberate choice to honour, never an obstacle to route around. What the skill does not move, it reports with the reason. Silence is the one failure mode this skill exists to prevent.

The sibling skill merge-deps triages the Dependabot queue — updates a bot already opened as PRs. This one performs the updates locally. Same domain, disjoint machinery; why they stay separate.

Workflow

1. Detect — read the repo, never assume

• Ecosystems, from lockfiles — pnpm-lock.yaml → pnpm, bun.lock/bun.lockb → bun, package-lock.json → npm, composer.lock/composer.json → Composer, Cargo.lock/Cargo.toml → Cargo (including a nested src-tauri/Cargo.toml), go.mod/go.sum → the Go toolchain. Full table: REFERENCE.md.
• packageManager in package.json overrides the lockfile guess — it is the repo's explicit statement. Where packageManagerStrict is set, a wrong manager is not a style slip; the install is rejected outright.
• The package-manager config is an input, not scenery — pnpm-workspace.yaml (pnpm 10+ keeps its settings there, not in .npmrc), .npmrc (auth, registries, scope routing), composer.json's config (minimum-stability, prefer-stable, repositories). Read them before planning; they change what the answer even is.
• A repo may carry several at once (PHP app + JS frontend) — each ecosystem is its own run, its own plan, its own report section.