update-dependencies

Update Dependencies

Upgrade project dependencies, researching breaking changes for major version updates.

Optional filter: $ARGUMENTS (e.g., react, Alamofire, serde tokio)

Task Tracking

At the start, use TaskCreate to create a task for each phase:

1. Run /review-dependencies skill
2. User strategy selection
3. Research breaking changes
4. User confirmation
5. Execute upgrades
6. Apply migrations and sync out-of-manifest records
7. Run /run-checks skill
8. Exercise upgraded schema against the real store
9. Report results
10. Recommend next steps

Phase 1: Review Dependencies

Run the /review-dependencies skill to detect package managers and discover available updates. If no updates are available, stop.

Phase 2: User Strategy Selection

Before summarizing, set aside packages whose version tracks a pinned runtime or platform rather than the newest release, such as runtime type definitions and platform SDKs. Find the pin the project declares (version manager file, engines field, container base image, CI setup step) and hold any version beyond it until the pin moves.

A package whose newer releases raise their own declared runtime or platform minimum above the project's is not set aside on that basis.

Present a summary showing:

• Count and list of major updates (with current → target versions)
• Count of minor updates
• Count of patch updates
• Packages set aside, each with the pin that governs it
• Packages whose newer releases need a higher runtime or platform minimum, each with the minimum they need

Before the strategy question, use AskUserQuestion to ask for each package that needs a higher minimum whether to raise the project's minimum, naming the versions or devices that lose support and the dependents that must raise theirs in lockstep, or to cap the package at the last release the current minimum admits. A project that declares no minimum counts as below every package's declared minimum: there, the raise option declares the package's minimum as the project's pin, in a version manager file, the engines field, or a CI setup step, and the cap option holds the package at the last release before it raised its minimum. Add a Get a second opinion option, which runs the /consult-codex skill for what each option commits to and what reversing it costs. Then resolve the choice with that answer in hand, re-asking when it stays the user's. Apply a raise only when the package is upgraded.