Dependencies need moving — an EOL or deprecation notice, a security advisory, "upgrade to vX", "how far behind are we". Also on "upgrade dependencies". Skip for new dependencies (superstack-decide), lockfile-only patch bumps, and updating the superstack plugin itself (the plugin manager's job).
Scanned 9/19/2026
Install to Claude Code
npx -y skills add debabsah/superstack --skill superstack-deps --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Superstack Deps?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/debabsah-superstack-deps)More formats (shields.io, HTML) on the badges page.
---
name: superstack-deps
description: Dependencies need moving — an EOL or deprecation notice, a security advisory, "upgrade to vX", "how far behind are we". Also on "upgrade dependencies". Skip for new dependencies (superstack-decide), lockfile-only patch bumps, and updating the superstack plugin itself (the plugin manager's job).
---
# superstack-deps
The platform moves under every project. An upgrade is ordinary work with one distinguishing risk: the breaking change you didn't read about — so the method is inventory, batches, and a checkpoint per batch.
## The method
1. **See green first, then inventory — printed.** Run the project's named verify command *before* any bump: a post-bump red you can't attribute is two hours of bisecting a failure that predated you (scope's rule, applied here). Then the inventory: what's depended on, current vs latest, EOL/advisory flags, and which dependencies are load-bearing vs incidental. When the work spans sessions, the inventory lives at the top of the task file (`.superstack/tasks/<slug>.md`) — dated, so the next session diffs against it instead of re-deriving it.
2. **Batch by risk, not alphabet.** Patch-safe bumps travel together; each major travels **alone**, with its breaking-change digest read from the actual changelog — opened, not guessed (R1: the changelog is a file you haven't opened yet).
3. **Each batch ends at a checkpoint:** the project's named verify command green, then a commit — so any batch is a legal stopping point and execution moves verified-state to verified-state (the plan shape). Rollback per batch is the commit revert — which stays true only if batches are pure: **no drive-by refactors inside an upgrade commit.**
4. **A big migration is a campaign.** Framework major, runtime jump, anything spanning sessions: open a plan file and run superstack-execute — this skill is its inventory-and-batching front end, not a substitute for the campaign loop.
5. **A pin is a decision.** What stays behind, stays behind *with its reason recorded* (a superstack-decide record or the overlay's Conventions, with a revisit trigger) — pinned-with-reason ages into a plan; silently stale ages into an incident.
## The ledger
What moved (versions, before → after), what the verify command showed per batch, and what remains behind with its why. `Assumed:` covers the transitive surface honestly — a green suite proves what the suite covers, not the dependency tree's whole behavior.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!