Fusion Dependency Review
Run an upstream-focused dependency upgrade review that scores stability and API risk before merging a version bump.
Overview
Fusion Dependency Review is an agent skill most often used in Ship (also Build) that assesses whether a target package version looks well-tested, stable, and API-safe for your repo before you merge an upgrade.
Install
npx skills add https://github.com/equinor/fusion-skills --skill fusion-dependency-reviewWhat is this skill?
- Five-step workflow: characterize release, API impact, test signals, regression scan, then assess
- Evidence prioritizes changelogs, CI signals, BREAKING/DEPRECATED/REMOVED markers, and community rollback chatter
- Returns a lens-only verdict: clear, concern, or blocking—with concise evidence
- Explicitly separates quality assessment from the final repository recommendation
- Five-step review workflow from release characterization through regression scan
- Three-tier assessment scale: clear, concern, blocking
Adoption & trust: 787 installs on skills.sh; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to merge a dependency bump but cannot tell if the upstream release is a quiet breaking rewrite or a well-tested maintenance drop.
Who is it for?
Maintainers upgrading npm, PyPI, or similar deps who want a structured upstream-quality pass before code review or CI promotion.
Skip if: Greenfield projects with no existing lockfile or when you only need license/legal review without version-risk analysis.
When should I use this skill?
A package name, ecosystem, current and target versions, and changelogs are available and you need a focused upstream quality and stability pass.
What do I get? / Deliverables
You receive a clear, concern, or blocking quality lens backed by changelog and regression evidence, ready to combine with other fusion review skills.
- Single lens assessment: clear, concern, or blocking with cited evidence
- Concise notes on API markers and regression signals—not a final merge recommendation by itself
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Dependency upgrades are canonically gated at review/ship time, though the same lens applies when refreshing packages during build. Review is where release notes, breaking markers, and regression signals are weighed without collapsing into a single merge/reject verdict alone.
Where it fits
Evaluate a new major client SDK before wiring it into backend integrations.
Attach a clear/concern/blocking lens to a dependency PR for human reviewers.
Prioritize CVE fix upgrades where rollback chatter suggests a bad patch release.
Re-assess a hotfix dependency bump after community regression reports appear.
How it compares
Use as a dedicated upstream stability lens instead of asking a generic reviewer to guess semver risk from the diff alone.
Common Questions / FAQ
Who is fusion-dependency-review for?
Solo builders and small teams who regularly bump dependencies and want Equinor-style fusion advisory steps without skipping changelog and regression diligence.
When should I use fusion-dependency-review?
In Ship review before merging Renovate or Dependabot PRs; in Build integrations when adopting a new major SDK; and in Operate iterate when patching production CVE-related upgrades.
Is fusion-dependency-review safe to install?
Review the Security Audits panel on this Prism page and limit agent network access to trusted registry and changelog sources you approve.
SKILL.md
READMESKILL.md - Fusion Dependency Review
# Code Quality Advisor Use this advisor when the review needs a focused upstream quality and stability pass. ## Role Assess whether the target version looks well-tested, stable, and compatible enough for this repository to consume. Return a lens assessment only; do not collapse quality findings into the final recommendation by yourself. ## Inputs - Package name, ecosystem, current version, and target version - Release notes, changelog links, and upstream issue references - Repository diff summary and any known usage points in the consuming codebase ## Evidence priorities 1. Upstream release notes and changelog entries 2. Upstream CI or release-quality signals when available 3. API markers such as `BREAKING`, `DEPRECATED`, `REMOVED`, or migration notes 4. Early community feedback, regressions, or rollback reports for the target version 5. Test-suite coverage changes or dropped test targets between the old and new version when visible ## Workflow 1. Characterize the release: maintenance update, feature expansion, refactor, or rewrite. 2. Check for API changes that could affect the consuming repository. 3. Look for evidence that the target version is tested and intentionally released. 4. Scan for regressions, rollback chatter, or open compatibility issues. 5. Produce one of `clear`, `concern`, or `blocking` with concise evidence. ## Assessment scale - `clear`: Well-signaled release, no relevant API breakage, and no meaningful regression evidence. - `concern`: Manageable API change, very fresh release with limited feedback, or partial quality evidence. - `blocking`: Known regressions, failing upstream quality signal, or API surface changes that likely require substantial adaptation. ## Output contract Return: - Assessment - Two to four evidence bullets - Compatibility notes for this repository, if any - Unresolved questions if the stability picture is incomplete ## Guardrails - Do not confuse a changelog summary with proof that the release is stable - Do not hide breaking changes just because the update is semver-minor - Do not recommend merge; that belongs to verdict synthesis # Impact Advisor Use this advisor when the review needs a repository-specific blast-radius and follow-up pass. ## Role Assess how risky the update is to merge in this repository, including CI behavior, code touch points, downstream consumers, and follow-up work. Return a lens assessment only; the final recommendation stays with verdict synthesis. ## Inputs - Package name, ecosystem, current version, and target version - Changed files, manifest/lockfile diff, and repository CI status - Any known usage paths, downstream consumers, or migration requirements ## Evidence priorities 1. Repository diff and changed-file scope 2. CI status for the PR or an equivalent validated signal 3. Direct usage points or dependency-role context in the repository 4. Downstream consumer impact and explicit post-merge tasks 5. Deployment pipeline or build-system implications when the dependency plays a role in release or bundling ## Workflow 1. Determine the blast radius: lockfile-only, manifest change, or code adaptation. 2. Check whether the repository CI is green, red, pending, or unknown. 3. Identify direct usage sites, downstream consumers, or deployment surfaces that could be affected. 4. Call out follow-up work such as config changes, migration tasks, or monitoring needs. 5. Produce one of `clear`, `concern`, or `blocking` with concise evidence. ## Assessment scale - `clear`: Low blast radius, green CI, no downstream breakage, and no meaningful follow-up. - `concern`: Limited code or config work, moderate spread, or manageable follow-up items. - `blocking`: Failing CI, significant adaptation required, or downstream breakage without a mitigation plan. ## Output contract Return: - Assessment - Two to four evidence bullets - Follow-up work that should stay visible in the final verdict - Unresolved impact questions if repository evidence is incomp