Automated skill for reviewing, validating, and safely merging Dependabot pull requests in the Fusion Framework monorepo.
Dependencies
This skill uses:
pnpm-dependency-analysis
skill for impact assessment and blast radius calculation
npm-research
skill for changelog, security, and breaking changes analysis
Operating Modes
Default to
Full
mode unless the user explicitly chooses Audit-only or Validate.
Audit-only
Research + build/test/lint locally. Comments optional. No post/push/merge.
Validate
Install + build + test + lint. Prepare comments. All actions gated by consent.
Full
End-to-end with required comments, consent-gated push/merge.
Templates
Template
Path
When
Mode
File
Available PRs List
templates/available-prs-list.template.md
Step 1
All: If interactive PR selection
Display to user
Research
templates/research-comment.template.md
Step 5
Full: Required; Other: Optional
.tmp/gh-comment-research.md
Results
templates/results-comment.template.md
Step 13
Full: Required; Other: Optional
.tmp/gh-comment-results.md
Guardrails
Never
post comments, push, close, merge, or modify code without explicit user approval
Pause
on user unavailability;
stop
on build/test/lint/security failures
Maintain
linear history (force-with-lease with consent only)
Propose
code changes when needed; never auto-modify source
Workflow
Step 1: Select PR
If PR provided by user
(number or URL) → parse and store details (owner, repo, number, branch) → Skip to Step 2
If no PR provided
→
Execute:
gh pr list --author "app/dependabot" --state open --json number,title,createdAt
Parse PR titles to determine semver type:
MAJOR
Breaking changes, major version bumps (e.g.,
5.0.0
from
3.x.x
)
MINOR
New features, minor version bumps (e.g.,
1.2.0
from
1.1.x
)
PATCH
Bug fixes, patch version bumps (e.g.,
1.1.5
from
1.1.4
)
Categorize and display using
available-prs-list.template.md
with age and semver columns
Request user selection by PR number
User MUST explicitly choose PR
— never auto-select
Whenever a user asks to handle a Dependabot PR without providing a specific PR number or URL, run the PR listing flow above immediately before requesting further input.
Step 2: Create Worktree
Ensure worktree directory exists:
mkdir -p ../fusion-framework.worktree
Get PR branch name:
gh pr view --json headRefName --repo equinor/fusion-framework --jq '.headRefName'
Fetch the branch:
git fetch origin :
Create worktree:
git worktree add ../fusion-framework.worktree/pr-
cd ../fusion-framework.worktree/pr-
Step 3: Rebase Branch
git fetch origin main && git rebase origin/main
If rebase succeeds
→ Continue to Step 4
If lock file conflict
(pnpm-lock.yaml):
pnpm install
(regenerate lock file)
git add pnpm-lock.yaml
git rebase --continue
Continue to Step 4
If version conflict
(package.json dependencies incompatible):
Ask to post comment + close PR
If yes: post + close → Skip to Step 15
If structural/complex conflicts
:
Display details → Ask user → Stop if declined
Step 4: Research Dependencies
Parse PR for dependency updates
Check latest available version:
npm view versions --json
If Dependabot version is NOT the latest stable
:
Display: Dependabot suggests
X.Y.Z
, but latest stable is
A.B.C
Ask user: "Use Dependabot version or update to latest stable?"
If user chooses latest: Update package.json and run
pnpm install
If user chooses Dependabot version: Continue with existing PR changes
Use
pnpm-dependency-analysis
skill
(
.github/skills/pnpm-dependency-analysis/SKILL.md
) to:
Identify which workspaces are affected (
pnpm why PACKAGE --recursive --depth=0
)
Check resolved versions and detect inconsistencies
Determine blast radius (low/medium/high risk based on workspace count)
Verify dependency type (dev vs production)
Apply the
Quick Decision Tree
below to assess merge readiness
Use
npm-research
skill
(
.github/skills/npm-research/SKILL.md
) to:
Research changelog (GitHub releases, CHANGELOG files, npm registry)
Check security advisories (npm audit, GitHub advisories, Snyk)
Identify breaking changes (semver analysis, PR research when needed)
Review related PRs if release notes reference specific changes
Analyze peer dependency changes and new dependencies
Analyze codebase compatibility
Identify if code changes needed (document only; don't modify)
Quick Decision Tree (Dependabot Triage)
Step 4.1: Identify the package
From PR title like "build(deps): bump lodash from 4.x to 5.x"
PACKAGE
"lodash"
pnpm
why
"
$PACKAGE
"
--recursive
--depth
=
0
Step 4.2: Assess spread
1–2 workspaces
Low risk, check one changelog
3–5 workspaces
Medium risk, test carefully
6+ workspaces
High risk, core shared dep — review thoroughly
Step 4.3: Determine dependency type
pnpm
why
"
$PACKAGE
"
--recursive
--json
|
jq
-r
'.[] | "(.workspace): (.dependencyType)"'
devDependencies only
→ usually safer (unless it's eslint, typescript, vite, vitest, jest, rollup, playwright, storybook)
dependencies
→ production impact — more caution needed
Both
→ requires full testing
Step 4.4: Check version consistency
pnpm
why
"
$PACKAGE
"
--recursive
--json
|
jq
-r
'.[] | "(.workspace)\t→ (.version)"'
All same version
→ good, consistent
Multiple versions
→ check if workspace: controls it or if overrides are needed
Very different
(e.g., v4 vs v5) → potential bugs, test before merge
Merge Decision Checklist
Before approving Dependabot PRs:
Run
pnpm why --recursive --depth=0
to see spread
Check if marked
workspace:
(almost always safe) or has mixed versions (riskier)
For high-spread packages (6+), skim the package's CHANGELOG for breaking changes
For tooling (eslint, vite, etc.), verify lint/build still works
For major version bumps in production deps, request test results or run locally
Safe to merge immediately (low friction)
✅ One or two workspaces affected
✅ Uses
workspace:
or workspace protocol
✅ Only appears in
devDependencies
✅ Patch or minor version bump
Requires careful review (plan ahead)
⚠️ 5+ workspaces affected
⚠️ Appears in production (
dependencies
)
⚠️ Major version bump
⚠️ Touches core tools (eslint, typescript, vite, vitest)
Escalate to team (discuss before merge)
🚫 Package used as shared library (everyone depends on it)
🚫 Multiple conflicting versions after upgrade
🚫 Breaking changes with no migration path
🚫 Touches build or CI infrastructure
Risk / Blast Radius Reference
Indicator
Risk Level
Action
1–2 workspaces only
Low
Usually safe to merge
≥ 6–8 workspaces
High
Review changelog + test carefully
Only in
devDependencies
Lower
Safe unless eslint, typescript, vite, vitest, jest, rollup, playwright, storybook
Uses
workspace:
or
workspace:^x.y.z
Very Low
Almost always safe (controlled at workspace root)
Many different resolved versions
Medium
Consider
pnpm.overrides
or
.npmrc
resolutions before merging
Hub node (many packages → it)
High
Core shared dep — high breakage risk
Deep/long chains in
pnpm why
Medium–High
Transitive breakage possible
Appears in multiple config files (eslint, vite, etc.)
Medium
Tooling change — lint/format/build risk
Step 5: Post Research Comment
(Full: Required; Other: Optional)
Format using template → Create
.tmp/gh-comment-research.md
Show to user → Ask: "Post research comment?"
If yes:
gh pr comment -F .tmp/gh-comment-research.md
→ Clean up
Step 6: Install Dependencies
pnpm install --frozen-lockfile
(clean node_modules if lock changed)
Step 7: Build Project
pnpm build
→ Stop on failure
Step 8: Run Tests
pnpm test
→ Stop on failure
Step 9: Run Linting
npx biome format --fix
git add .
npx biome check --diagnostic-level=error
→ Stop on failure
Step 10: Generate Changeset
(if
.changeset
exists)
Parse PR for package changes
Determine if changeset is needed:
Create changeset if
:
Dependency affects a compiled/built package (CLI, Dev-Portal, vite-plugins, etc.)
Consumers can manually update the package (not just a transitive dependency)
DevDependency updates that affect build output or tooling behavior
Skip changeset if
:
Changes only affect workspace tooling (root package.json, turbo.json, CI configs)
Test-only changes with no impact on package functionality
Generate using
changeset rules
Use
patch
bump for devDependency updates
Prefix with "Internal:" for non-API changes
List affected packages in frontmatter
Include brief summary of dependency changes
Show to user → Ask: "Create changeset?"
If yes: Stage files
Step 11: Propose Code Changes
(if needed from Step 4)
Document required changes + rationale
Propose exact modifications → Ask: "Approve modifications?"
If yes: Commit with clear message
Step 12: Rebase & Push Changes
(Always execute)
cd ../fusion-framework.worktree/pr-
git fetch origin main
(ensure latest main)
git rebase origin/main
(resolve any conflicts if needed)
Show status:
git status --porcelain
Ask: "Push rebased branch?"
If yes:
git push origin HEAD --force-with-lease
(to PR branch)
Step 13: Post Validation Results
(Full: Required; Other: Optional)
Format using template → Create
.tmp/gh-comment-results.md
Show to user → Ask: "Post validation results?"
If yes:
gh pr comment -F .tmp/gh-comment-results.md
→ Clean up
Step 14: Merge PR
(Full mode only)
Show merge details + branch protection status
Ask: "Merge PR now?"
If yes:
gh pr merge --squash --admin
Step 15: Cleanup
cd
(return to main repo)
git worktree remove ../fusion-framework.worktree/pr-
(or
--force
if dirty)
Summarize results