Fusion Dependency Review

Dependency Review

Structured review workflow for dependency update PRs. Produces consistent research notes that incorporate existing PR discussion, multi-lens analysis, and an actionable verdict with explicit maintainer confirmation before any merge action.

When to use

Use this skill when a dependency PR needs review and you want a consistent, auditable decision process.

Typical triggers:

• "Review this dependency PR"
• "Should we merge this dependency update?"
• "Check this Renovate/Dependabot PR"
• "Review one of our open dependency PRs"
• "What changed in this library bump?"
• "Is this dependency update safe to merge?"
• A PR title contains dependency update patterns (for example chore(deps):, fix(deps):, bump, update)
• The user shares a PR URL for a dependency update

When not to use

Do not use this skill for:

• Feature PRs or application code reviews (use standard code review workflows)
• Dependency automation or bot configuration
• Approving/merging without explicit user confirmation
• Deciding organizational dependency policy

Required inputs

Collect before starting the review:

• Repository owner and name
• PR number or URL for the dependency update, or a copied PR summary that includes package name, version change, changed files, and CI status
• Optional: specific review concerns or areas of focus from the maintainer

If required details are missing, ask concise clarifying questions from references/questions.md.

If the PR target is missing or ambiguous:

• Ask only the minimal follow-up question needed to identify the target PR.
• When repository context is known, use GitHub MCP to list likely open dependency PRs and let the user choose instead of guessing.
• Keep the shortlist concise and decision-friendly: include PR number, title, dependency/package hint, author, and CI state when available.

Auto-extract from the PR when available:

• Package(s) being updated and version range (from → to)
• Changelog/release notes URL
• CI status
• Changed files and dependency ecosystem
• Existing top-level PR comments, review comments, and unresolved thread state

Instructions

Preferred advisor orchestration

When the runtime supports skill-local advisors, prefer this execution shape instead of a single long linear pass:

1. Run agents/target-pr-advisor.md first when the PR target is missing or ambiguous so the review starts from one explicit dependency PR. 2. Run agents/research-advisor.md to normalize the PR context, existing discussion, source list, and research notes. 3. Fan out the lens advisors in parallel with the same normalized inputs:

• agents/security-advisor.md
• agents/code-quality-advisor.md
• agents/impact-advisor.md

4. Chain the combined research and lens outputs into agents/verdict-advisor.md for recommendation, confidence, handoff, and confirmation wording. 5. Chain into agents/source-control-advisor.md only if the accepted next step requires PR patching, rebase, conflict resolution, or merge-readiness work.

Keep the lens advisors narrow and independent. The parent skill owns the unified review and should preserve disagreement between advisors instead of flattening it early.

Workflow summary

1. Resolve the target PR with agents/target-pr-advisor.md and the concise prompts in references/questions.md. 2. Gather context and build the shared evidence packet with agents/research-advisor.md, assets/review-tracker.md, and assets/research-template.md. 3. Run agents/security-advisor.md, agents/code-quality-advisor.md, and agents/impact-advisor.md in parallel with the same normalized research packet. 4. Use agents/verdict-advisor.md to produce the recommendation, confidence, follow-up, and explicit maintainer prompt. 5. Use agents/source-control-advisor.md only after the verdict is accepted and only when branch work is required. 6. Follow references/instructions.md for the detailed live-PR contract: target selection, checkpoint comments, decision gates, and handoff timing.

Assets

• assets/research-template.md: research-comment structure for change summary, breaking changes, known issues, and sources
• assets/verdict-template.md: verdict structure for lens assessments, recommendation, confidence, and follow-up items
• assets/review-tracker.md: working checklist and tracker for context, validation, lens outcomes, and handoff decisions

References

• references/instructions.md: detailed execution contract for target selection, live-PR checkpoints, and decision sequencing
• references/questions.md: concise follow-up questions for choosing the target dependency PR and scoping the review

Advisors

• agents/target-pr-advisor.md: resolves the exact dependency PR to review or returns a shortlist for user selection
• agents/research-advisor.md: first pass; builds the shared evidence packet for all later advisors
• agents/security-advisor.md: parallel lens pass; checks security posture and attack-surface changes
• agents/code-quality-advisor.md: parallel lens pass; checks upstream stability, regressions, and API drift
• agents/impact-advisor.md: parallel lens pass; checks repository blast radius, CI, and follow-up work
• agents/verdict-advisor.md: chained synthesis pass; turns research and lens outputs into one decision
• agents/source-control-advisor.md: conditional final pass; handles rebase, sync, validation reruns, and push safety when patching the PR

If helper advisors are unavailable, follow the same orchestration inline: research first, lenses next, verdict after that, and source-control last only when mutation is needed.

Expected output

If the PR target is unresolved, return:

• A concise shortlist of candidate dependency PRs when live PR search is available
• The minimal follow-up question required to let the user choose the correct PR
• Explicit status: Awaiting user PR selection

If the PR target is resolved, return a structured review containing:

• Package name, version change, and update type
• Existing PR discussion summary (top-level comments, review-thread themes, unresolved concerns)
• Research summary (changelog highlights, breaking changes, known issues)
• Security assessment with evidence
• Code quality assessment with evidence
• Impact assessment with evidence
• Verdict: recommendation, rationale, confidence, and follow-up items
• Handoff recommendation when follow-up work should become a tracked issue
• Explicit action prompt for the maintainer

Safety & constraints

• This skill is mutation-capable. Repository-local workflow instructions take precedence over inline guidance when they conflict.

Never:

• Merge or approve a dependency PR without explicit user confirmation
• Create a merge commit by merging the base branch into a Dependabot or Renovate PR branch
• Guess which PR to review when multiple plausible dependency PRs exist
• Skip the research checkpoint comment or final verdict comment on a live PR
• Ignore existing reviewer concerns because they are inconvenient or duplicative
• Claim CI passed or security is clear without checking actual status
• Expose secrets or tokens in comments or logs
• Dismiss security concerns for convenience
• Fabricate changelog entries or version details not found in sources

Always:

• Ask minimal follow-up questions when the target PR is missing or ambiguous
• Present evidence for each assessment (link to changelog, CVE, CI status)
• List candidate dependency PRs for user selection when repository context exists but the PR target does not
• Fetch existing PR comments and review threads via GitHub MCP before analysis on a live PR
• Reuse one shared research packet across advisors instead of rediscovering the same facts in each pass — this includes PR metadata, changed files, CI status, and existing discussion
• Do not re-fetch PR comments or review threads independently in each advisor; pass the pre-fetched data from the research advisor to all lens advisors
• Prefer parallel lens analysis when the runtime supports it, then chain synthesis after all lens outputs are ready
• Post the research checkpoint comment to the PR before any branch mutation on a live PR
• Post the final verdict comment to the PR before any approval or merge on a live PR
• Make branch-sync or rebase needs explicit before patching the PR
• Rebase dependency PR branches onto the latest base branch when refresh is required; do not merge the base branch into the PR branch
• Make follow-up work explicit rather than burying it in review notes
• Respect the maintainer as the final decision-maker
• Keep review output in a consistent, repeatable structure

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 incomplete

Guardrails

• Do not claim impact is low without checking the actual diff and CI state
• Do not bury follow-up work inside prose; make it explicit
• Do not recommend merge; that belongs to verdict synthesis

Research Advisor

Use this advisor before scoring any review lens.

Role

Collect the evidence needed for a dependency update review and normalize it into one research summary. Stay read-only and evidence-first; this advisor prepares the record but does not decide the final recommendation.

Inputs

• Repository owner/name and PR number or URL
• Package name, ecosystem, current version, target version
• Changed files and CI status if already known
• Maintainer concerns or suspected risks, if any
• Existing top-level PR comments and review threads when the review targets a live PR

If the PR target is not yet known, hand control back to the parent skill so it can use agents/target-pr-advisor.md to ask a minimal follow-up question or present a shortlist of candidate dependency PRs.

Source priorities

Prefer portable, source-backed signals in this order:

1. Existing top-level PR comments and review threads fetched through GitHub MCP 2. Upstream changelog or release notes 3. Security advisories from GitHub or the package ecosystem 4. Issue tracker or discussion threads for regressions in the target version 5. Manifest and lockfile diff for transitive changes, peer dependency shifts, or install-script changes 6. Repository CI status and dependency graph evidence when available

Workflow

1. If the PR identifier is missing or ambiguous, stop and ask the parent skill to resolve the target first through agents/target-pr-advisor.md. 2. For a live PR review, fetch existing top-level PR comments and review threads through GitHub MCP before any lens scoring or verdict drafting. 3. Summarize the current PR discussion: maintainer requests, reviewer concerns, unresolved threads, and already-answered or outdated items. 4. Confirm the exact version jump and update type. 5. Summarize release-note changes between the old and new version. 6. Record breaking changes, deprecations, and migration steps. 7. Look for known regressions or open issues against the target version. 8. Capture notable transitive dependency changes visible in the diff. 9. Draft findings into the research template with explicit sources, discussion context, and unknowns, then prepare the same content as a PR-comment-ready research checkpoint that keeps the exact title prefix format # 🤖 Bip Bop - <title>.

Portable boundaries

Carry forward the reusable patterns only:

• Ask a minimal follow-up question or present a candidate PR shortlist through agents/target-pr-advisor.md before research when the target PR is not yet known
• Fetch existing PR comments and review threads before analysis for a live PR
• Research first, then lens scoring, then verdict
• Structured notes instead of ad hoc comments
• For a live PR, the completed research packet must be posted as a research checkpoint comment before any rebase, push, approval, or merge.
• Explicit consent gate before any approval, merge, or PR mutation

Do not import repository-specific branch, rebase, push, or package-manager automation into the review contract unless the current repository explicitly requires it.

Output contract

Return:

• Normalized context: package, versions, ecosystem, update type, changed files, CI status
• Existing discussion summary: top-level comment themes, review-thread themes, unresolved concerns, already-answered items
• Research summary: changelog highlights, breaking changes, known issues, transitive changes
• Source list with enough detail to re-check the evidence
• PR-comment-ready research checkpoint body
• Explicit unknowns or missing evidence

Use the exact title prefix format # 🤖 Bip Bop - <title> for the PR-comment-ready research checkpoint body.

Guardrails

• Do not fabricate changelog entries or issue reports
• Do not claim a source was checked if it was not
• Do not guess between multiple plausible dependency PRs; require explicit user selection
• Do not start lens scoring for a live PR until existing PR comments and review threads have been fetched or explicitly escalated as unavailable
• Do not proceed into mutation planning for a live PR if the research checkpoint comment has not been posted or explicitly escalated as blocked
• Stay read-only until the maintainer asks for a mutation step

Security Advisor

Use this advisor when the dependency review needs a security-specific pass before the final verdict.

Role

Interrogate the target dependency version for vulnerability reduction, new attack surface, and supply-chain risk. Return a lens assessment only; do not approve, merge, or overwrite the final verdict.

Inputs

• Package name, ecosystem, current version, and target version
• PR diff summary, changed files, and CI status if known
• Any advisories, changelog links, or known risk signals already collected

Evidence priorities

1. GitHub Security Advisories or the ecosystem advisory database for the package and target version 2. Upstream changelog or release notes describing security fixes, removals, or sensitive behavior changes 3. Manifest and lockfile diff for new direct or transitive dependencies, widened ranges, and install-script changes 4. Package ownership, publisher, or issue-tracker signals when publish patterns look unusual

Workflow

1. Confirm whether the update fixes an existing vulnerability or is security-neutral. 2. Check advisories against the target version instead of assuming newer is safer. 3. Inspect the diff for new dependencies, widened attack surface, or sensitive runtime/install behavior. 4. Look for supply-chain anomalies such as maintainer churn, ownership transfer, or suspicious publish cadence. 5. Produce one of clear, concern, or blocking with concise evidence.

Assessment scale

• clear: No active advisory found for the target version, and new attack surface is absent or low-risk and explained.
• concern: A manageable new dependency, limited source coverage, or a minor security question remains, but no blocker is proven.
• blocking: Active advisory in the target version, suspicious supply-chain signal, or removal of security-relevant behavior without a safe replacement.

Output contract

Return:

• Assessment
• Two to four evidence bullets
• Unresolved questions if evidence is partial
• Explicit note when more sources are needed

Guardrails

• Do not mark clear without checking real sources
• Do not treat lack of evidence as proof of safety
• Do not recommend merge; that belongs to verdict synthesis

Source Control Advisor

Use this advisor when the dependency review moves from analysis into PR patching, conflict resolution, branch refresh, or merge-readiness checks.

Role

Keep source-control steps explicit and safe when a dependency PR branch needs maintenance. Focus on branch state, rebase need, validation checkpoints, and push safety. This advisor does not decide the dependency verdict and does not mutate git state without explicit maintainer confirmation.

Inputs

• Base branch and head branch, or a PR number that can resolve them
• Current mergeability or conflict status and any stale-branch signal
• Whether the goal is review-only, PR patching, revalidation, or merge preparation
• Whether the research checkpoint comment is already posted and whether the final verdict comment will need refresh after sync
• Any local or staged changes and the validation plan that must pass before and after sync

Evidence priorities

1. PR mergeability or conflict state from GitHub or local git status 2. Base and head divergence, especially whether the PR branch is behind the base branch 3. Local worktree cleanliness and uncommitted changes that would be affected by rebase 4. Repository policy or maintainer direction about rebase-only behavior and force-push approval 5. Whether the required PR comment checkpoints already exist or still need to be posted 6. Post-sync validation requirements before approval or merge

Workflow

1. Confirm whether source-control mutation is actually needed. Stay read-only if the review can finish without branch changes. 2. Confirm the research checkpoint comment is already posted before any git mutation on a live PR. If not, stop and hand back to the parent skill. 3. Check branch state: mergeable, conflicted, behind base, or stale. 4. Prefer the smallest safe sync step:

• Rebase onto the base branch is the required sync method when patching an existing dependency PR branch that fell behind.
• Never merge the base branch into a Dependabot or Renovate dependency PR branch.
• If a rebase causes the dependency diff to widen beyond the intended package update, stop and reconstruct the minimal intended delta instead of accepting unrelated lockfile churn.

5. If a rebase or conflict resolution is needed, checkpoint local changes first and make the revalidation plan explicit. 6. After patching or rebasing, rerun the focused validation plan, then hand the updated evidence back so the final verdict comment can be refreshed before any approval or merge. 7. Ask for explicit maintainer confirmation before rebase, force-push, or merge.

Output contract

Return:

• Branch state summary
• Whether source-control action is needed
• Recommended sync method and why
• Whether the research checkpoint is satisfied and what the final verdict comment must reflect after sync
• Required confirmations before push, force-push, or merge
• Post-sync validation steps

Guardrails

• When operating inside a repository with repo-local workflow instructions, defer to those rules for commit conventions, validation commands, changeset requirements, and branch-refresh policy. Repo-local instructions take precedence over inline guidance in this advisor.
• Do not use destructive recovery commands such as git reset --hard
• Do not force-push without explicit maintainer confirmation
• Do not start git mutation on a live PR until the research checkpoint comment is posted
• Keep git operations non-interactive and scoped to the dependency PR branch
• Never merge the base branch into a dependency PR branch; keep dependency PR history linear
• Preserve unrelated local changes and call out blockers before rebasing
• Do not recommend merge until the final verdict comment has been refreshed with any post-sync validation results
• Do not conflate "branch is current" with "dependency is safe to merge"

Target PR Advisor

Use this advisor before research when the request does not already identify one exact dependency PR.

Role

Resolve the dependency PR to review without guessing. Normalize explicit PR links or numbers when they exist; otherwise, produce a small, decision-friendly shortlist and the minimum follow-up question needed for the user to choose the correct PR.

Inputs

• Repository owner/name when known
• PR URL or PR number when provided
• Package or dependency hint, if any
• Maintainer concerns, author hints, or bot hints when available

Evidence priorities

1. Explicit PR URL or PR number from the user 2. Repository context that can be used to list or search open PRs 3. Dependency-update signals in title, author, labels, or branch name 4. Package-name hints from the user request 5. CI state or mergeability signals that help the user distinguish candidates

Workflow

1. If the user already provided a PR URL or PR number, normalize owner, repo, and PR number and return a resolved target. 2. If the repository is unknown, ask which repository to inspect before listing candidates. 3. If the repository is known but the PR is not, use GitHub MCP to search or list likely open dependency PRs. 4. Prefer likely dependency candidates first: bot-authored PRs, titles with deps, bump, update, or ecosystem-specific dependency wording. 5. Keep the shortlist concise. Include PR number, title, dependency or package hint, author, and CI state when available. 6. If exactly one candidate clearly matches the user hint, return it as the resolved target. If multiple plausible candidates remain, stop and ask the user to choose. 7. If live GitHub PR access is unavailable, ask the user for a PR URL, PR number, or pasted PR summary before research starts.

Output contract

Return either:

• Resolved target: owner, repo, PR number, and why it matches

Or:

• Candidate shortlist of likely dependency PRs
• Minimal follow-up question needed for user selection
• Explicit status: Awaiting user PR selection

Guardrails

• Do not guess between multiple plausible dependency PRs
• Do not start research, lens analysis, or verdict synthesis before the target PR is resolved
• Keep the shortlist small and decision-friendly
• Stay read-only; selection is not approval to mutate the PR

Verdict Advisor

Use this advisor after research and the three lens assessments exist.

Role

Synthesize the research, security, code quality, and impact findings into one coherent dependency-review decision. Preserve disagreements instead of averaging them away. This advisor owns the confidence model, follow-up handoff, and final action gate, but it still does not approve or merge without explicit maintainer confirmation.

Inputs

• Package name, versions, ecosystem, and update type
• Existing PR discussion summary, including unresolved review threads and maintainer requests, when the review targets a live PR
• Research summary and source list
• Security, code quality, and impact assessments with evidence
• Repository CI status, changed files, and maintainer concerns when available

Workflow

1. Verify the research summary, existing discussion summary for a live PR, and all three lens outputs are present, or call out what is missing. 2. Keep the review unified by surfacing the strongest positive and negative signals together with any still-open reviewer concerns. 3. Apply recommendation rules:

• Any blocking lens means the verdict must be hold or decline.
• Unresolved reviewer concerns without an evidence-based resolution usually prevent a straight merge recommendation.
• Concerns with no blocker usually mean merge with follow-up or hold, depending on the evidence gaps.
• All-clear findings can support merge when CI and blast radius support it.

4. Apply the confidence model:

• high: evidence is consistent, CI is green, no blocker exists, and the blast radius is low or clearly bounded
• medium: no blocker exists, but at least one concern remains, impact is moderate, or source coverage is partial
• low: major ambiguity, failing or unknown CI, missing release notes, or materially conflicting findings

5. Make follow-up work explicit. If the review surfaces work beyond the PR itself, hand off through fusion-issue-authoring as a Task, Bug, or User Story. 6. Produce a final PR-comment-ready verdict that summarizes the work done since the research checkpoint, the current validation state, and the requested maintainer action, using the exact title prefix format # 🤖 Bip Bop - <title>. 7. End with an explicit action prompt asking the maintainer whether to approve, hold, decline, or create follow-up work.

Recommendation semantics

• merge
• merge with follow-up
• hold
• decline

Handoff rules

• Migration, cleanup, or operational work after the upgrade -> Task
• Regression, incompatibility, or broken behavior in the target version -> Bug
• Broader consumer-facing or workflow change triggered by the update -> User Story

Output contract

Return:

• Package summary
• Existing discussion status / unresolved concerns summary
• Research summary
• Lens assessments with evidence
• Recommendation
• Rationale
• Confidence
• Follow-up items
• Handoff recommendation when needed
• PR-comment-ready final verdict comment body
• Explicit confirmation prompt

Use the exact title prefix format # 🤖 Bip Bop - <title> for the PR-comment-ready final verdict comment body.

Guardrails

• Never auto-approve or auto-merge
• Never claim CI, security, or impact is clear without cited evidence
• Do not ignore unresolved review threads unless the evidence packet explains why they are outdated or already addressed
• Do not proceed to approval or merge on a live PR until the final verdict comment has been posted
• If sources conflict, reflect the conflict in confidence or recommendation
• Bias ambiguous or high-risk cases toward hold until the missing evidence is resolved

🤖 Bip Bop - Dependency Update Research

Post this filled template to the PR as the research checkpoint comment before any branch mutation, rebase, push, approval, or merge.

PR Snapshot

Existing PR Discussion

Upstream Delta

<!-- What changed upstream, the release character, and the changelog or release-note source. -->

Breaking Changes And Migration Work

<!-- Concrete breakage, deprecations, peer shifts, or migration work. Use "None identified" if clean. -->

Known Issues And Stability Signals

<!-- Regressions, rollback chatter, issue warnings, or "None found." Note if the release is too fresh for strong signal. -->

Dependency Graph And Transitive Changes

<!-- New or removed packages, peer changes, install-script changes, or unusual lockfile churn. -->

Branch And Validation Notes

<!-- Branch state, likely rebase need before patching, and focused validations to rerun after sync. -->

Early Read

• Security signal: <clear / concern / blocking>
• Quality signal: <clear / concern / blocking>
• Impact signal: <clear / concern / blocking>
• Likely verdict direction: <merge / merge with follow-up / hold / decline>

Sources Checked

• [ ] Existing PR comments: <link or note>
• [ ] Review threads / review comments: <link or note>
• [ ] Upstream changelog or release notes: <link or note>
• [ ] Security advisories: <link or note>
• [ ] Issue tracker or regressions: <link or note>
• [ ] PR diff and changed files: <link or note>
• [ ] CI or validation evidence: <link or note>

Dependency PR Review Tracker

Use this tracker while reviewing a dependency PR so the research, lens analysis, validation, and follow-up path stay explicit.

Quick workflow

• [ ] Fetch existing top-level PR comments and review threads before analysis
• [ ] Summarize existing discussion, unresolved concerns, and already-answered items
• [ ] Capture PR context and update type
• [ ] Check branch state and whether rebase or sync is needed before patching
• [ ] Record the dependency package, versions, and changed files
• [ ] Gather release notes, changelog, advisories, and known-issue sources
• [ ] Summarize research findings
• [ ] Post the research checkpoint comment to the PR before any branch mutation
• [ ] Score security, code quality, and impact lenses
• [ ] Determine recommendation and confidence
• [ ] Identify required follow-up work
• [ ] Post the final verdict comment to the PR before any approval or merge action
• [ ] Ask for explicit maintainer confirmation before any approve/merge action

Context

Sources consulted

Validation plan

Repository-specific checks

(paste relevant commands here)

Source-control plan

(note whether branch refresh, rebase, conflict resolution, or push confirmation is needed)

PR / package-specific checks

(paste focused validation here)

Lens tracking

Verdict

Follow-up handoff

If additional work is required, make the handoff explicit.

Final action gate

• [ ] Existing PR comments and review threads were reviewed before lens scoring
• [ ] Research summary is complete
• [ ] Research checkpoint comment posted to the PR before any rebase, push, approval, or merge action
• [ ] Lens assessments have evidence
• [ ] Unresolved reviewer concerns are reflected in the recommendation or explicitly rebutted
• [ ] Recommendation and confidence are consistent with the evidence
• [ ] Any required branch sync or rebase is explicit before patching
• [ ] Follow-up work is explicit instead of implied
• [ ] Final verdict comment posted to the PR before any approval or merge action
• [ ] Maintainer confirmation requested before any rebase, push, force-push, approve, or merge action

🤖 Bip Bop - Dependency Update Verdict

Decision Snapshot

Work Done Since Research Checkpoint

• Branch action: <none / rebased onto <base> / conflict resolved / validation-only>
• Validation rerun: <commands and outcome>
• PR state now: <mergeable / conflicted / waiting on CI / ready for maintainer decision>

Existing Discussion Status

• Top-level PR comments reviewed: <yes / no>
• Review threads reviewed: <yes / no>
• Open reviewer concerns: <!-- summarize unresolved threads or ongoing objections, or "None" -->
• Items judged outdated or already answered: <!-- summarize briefly, or "None" -->

Lens Calls

Security

• Call: <clear / concern / blocking>
• Why it matters: <!-- CVE fix, target-version advisory, attack-surface change, or "no material security issue found" -->
• Evidence:
• <!-- advisory link, changelog note, or diff signal -->
• <!-- optional second supporting point -->

Code quality

• Call: <clear / concern / blocking>
• Why it matters: <!-- release stability, API breakage, regression chatter, or "routine maintenance release" -->
• Evidence:
• <!-- upstream CI, changelog, migration note, or issue link -->
• <!-- optional second supporting point -->

Impact

• Call: <clear / concern / blocking>
• Why it matters: <!-- blast radius, CI effect, downstream consumer risk, or follow-up need -->
• Evidence:
• <!-- repo CI, changed-file scope, or dependency usage note -->
• <!-- optional second supporting point -->

Rationale

<!-- Short explanation that reflects the strongest positive and negative signals without repeating the research snapshot. -->

Blockers And Follow-Up

Blockers to clear before merge

<!-- Use "None" if nothing blocks merge. Include branch sync or rebase need here when relevant. -->

Follow-up after merge

<!-- Use "None" if clean. Keep every item explicit and actionable. -->

• [ ] <!-- e.g. Update configuration for new API -->
• [ ] <!-- e.g. Monitor for regressions in affected area -->

Issue handoff

<none / Task / Bug / User Story via fusion-issue-authoring>

Maintainer Confirmation

• Posting gate: Post this verdict summary to the PR before any approval or merge.
• Requested action: <approve / hold / decline / create follow-up issue>
• Confirmation prompt: Please confirm the next action before any rebase, push, approval, or merge.
• Decision note: <!-- maintainer records the final decision or PR comment summary here -->

Changelog

0.1.3 - 2026-03-24

patch

• #126 `1470bc8` - Add repository-policy handoff section for governance alignment

• Add explicit "Repository-policy handoff" section that defers commit, validation, changeset, and PR rules to repo-local instructions
• Update source-control-advisor to also defer to repo-local workflow instructions

Resolves equinor/fusion-core-tasks#581

0.1.2 - 2026-03-17

patch

• #85 `c8ba3df` - Make all GitHub-API-consuming skills more conservative with token usage.

• fusion-issue-authoring: concrete session-cache flow for labels and assignee candidates; per-session budget table
• fusion-issue-solving: expanded low-token strategy with session-cache references and budget awareness
• fusion-github-review-resolution: token budget guidance for thread-heavy reviews; cache PR metadata once
• fusion-issue-task-planning: session-cache delegation rules and batch-size warning for large task plans
• fusion-dependency-review: explicit data-reuse rules across parallel advisor fan-out
• fusion-discover-skills: tighter GraphQL budget and call-count cap for discovery sessions

resolves equinor/fusion-core-tasks#797

0.1.1 - 2026-03-11

patch

• #73 `c0070d2` - Require the dependency review research and verdict outputs to use the Bip Bop title prefix.

• align the advisor guidance with the required PR comment title format
• update the research and verdict templates to start with the Bip Bop heading prefix

0.1.0 - 2026-03-10

minor

• #69 `9503fd8` - Add experimental dependency review skill

• Structured research template for dependency update PRs
• Helper advisors for research, security, code quality, impact, source control, and verdict synthesis
• Multi-lens review analysis: security, code quality, impact
• Reusable verdict template with recommendation, rationale, confidence, and follow-up
• Review tracker/checklist asset for consistent dependency PR triage
• GitHub MCP retrieval of existing PR comments and review threads before analysis
• Minimal follow-up questions and candidate dependency PR listing when the target PR is unclear
• Focused advisor/reference files for target-PR selection and detailed workflow sequencing
• High-confidence evaluation coverage for dependency review
• Advisor-driven source guidance, confidence rules, remediation handoff, and safe PR patching flow
• Mandatory PR research checkpoint comments before mutation and final verdict comments before merge or decision
• Evaluation prompt for dependency review validation
• Explicit maintainer confirmation before any merge action

resolves equinor/fusion-core-tasks#523

Detailed workflow

Use this reference for the expanded execution contract. Keep SKILL.md focused on activation, high-level orchestration, outputs, and safety; use this file when the run needs step-by-step sequencing.

Step 0 — Resolve the target PR

1. If the user already provided a PR URL or PR number, normalize owner, repo, and PR number from that input. 2. If the request is ambiguous (for example review the dependency PR), ask only the minimum follow-up needed to identify the target. 3. When repository context is known but the PR is not, use GitHub MCP to search or list open dependency PRs and present a shortlist for the user to choose from. 4. Prefer likely dependency-update candidates first: bot-authored PRs, titles with deps, bump, update, or ecosystem-specific dependency wording. 5. If multiple plausible PRs remain, do not guess. Wait for the user to choose the PR before continuing. 6. If live PR access is unavailable, ask the user to provide a PR URL, PR number, or pasted PR summary before starting research.

Step 1 — Gather PR context

1. After a single target PR is selected, fetch PR metadata: title, description, changed files, CI status, labels. 2. Fetch existing top-level PR comments and review threads through GitHub MCP before any analysis, using PR tools that list both timeline comments and threaded review feedback so everything is captured. 3. Summarize the current PR discussion: maintainer requests, reviewer concerns, unresolved threads, prior agent comments, and decisions already made. 4. If live comment or review-thread retrieval fails, stop before analysis and tell the maintainer that the required PR discussion context could not be loaded. 5. Identify the dependency being updated: package name, ecosystem, current version, target version. 6. Determine the update type: patch, minor, or major. 7. Pull the diff to understand what files changed, typically lockfiles, manifests, or code adaptations. 8. Determine whether the PR branch is current, mergeable, or likely to require rebase before patching or revalidation. 9. If live PR access is unavailable, normalize the user-provided summary into the same fields and continue only if the summary is sufficient.

Step 2 — Research and prepare the evidence packet

1. Start from the PR discussion summary created in Step 1 and refine it to highlight maintainer instructions, prior reviewer findings, unanswered questions, and unresolved review threads, clearly distinguishing open concerns from resolved or outdated discussion. 2. Summarize release notes or changelog changes between the old and new version. 3. Flag breaking changes, deprecations, peer shifts, or migration steps. 4. Check for known regressions or open issues against the target version. 5. Capture notable transitive dependency changes visible in the diff. 6. When the ecosystem provides audit tooling such as npm audit, cargo audit, or pip-audit, include that output as an additional evidence source. 7. Start from assets/review-tracker.md and fill the context, discussion inventory, validation plan, and source inventory first. 8. Draft detailed findings into assets/research-template.md either in .tmp/ or as a PR comment draft, keeping the exact title prefix format # 🤖 Bip Bop - <title>.

Step 3 — Run lens analysis and synthesize the verdict

1. Run agents/security-advisor.md, agents/code-quality-advisor.md, and agents/impact-advisor.md in parallel with the same normalized research packet. 2. Treat the lens advisors as evidence producers only; the parent skill still owns the unified review. 3. Chain the research output and lens outputs into agents/verdict-advisor.md for the recommendation, confidence, follow-up handoff, and explicit maintainer prompt. 4. If any lens has a blocking assessment, the recommendation must not be merge without addressing the blocker first. 5. Unresolved reviewer concerns or open review threads without an evidence-based resolution should reduce confidence and usually prevent a straight merge recommendation. 6. Treat the verdict as a comment-ready artifact. If patching, rebasing, or focused validation changes the branch state, fold those results into the final verdict before posting it.

Step 4 — Live PR checkpoints and maintainer decision gates

1. Post the research checkpoint comment before any source-control mutation, rebase, push, approval, or merge. 2. If the runtime cannot post the research checkpoint comment, stop before mutation and tell the maintainer that the PR record could not be updated. 3. Post the final verdict comment before any approval, hold, decline, or merge action. Refresh it with any patching or validation results before posting. 4. Include the existing discussion summary, unresolved reviewer concerns or rationale for treating them as resolved or outdated, lens assessments, recommendation, confidence, follow-up items, and explicit confirmation prompt in the final verdict comment, and keep the exact title prefix format # 🤖 Bip Bop - <title>. 5. If the runtime cannot post the final verdict comment, stop before approval or merge and tell the maintainer that the PR record could not be updated. 6. If branch patching is required before approval or merge, use agents/source-control-advisor.md only after the verdict is accepted so branch-sync planning, rebase need, validation reruns, and push confirmation stay tied to the chosen next action. 7. Before any rebase, push, force-push, approval, or merge, ask for explicit maintainer confirmation. 8. If the maintainer approves merge, then approve and/or merge the PR via MCP. 9. If the maintainer requests hold, add a comment noting the hold reason and any follow-up criteria. 10. If the maintainer declines, add a comment with the rationale and close if requested. 11. If follow-up work is identified, propose a handoff through fusion-issue-authoring so the follow-up becomes an explicit Task, Bug, or User Story instead of an informal note.

Clarifying questions

Use the smallest set of questions needed to start a useful dependency PR review.

Resolve the target PR

• Which repository and PR should be reviewed?
• Do you already have a PR URL or PR number?
• If multiple dependency PRs are open, should I list the likely candidates for you to choose from?
• Which dependency or package name should I use to narrow the candidate PR list?

Review focus

• What decision do you want from this review: merge, merge with follow-up, hold, or decline?
• Are there specific concerns to prioritize: security, CI failures, breaking changes, regressions, or blast radius?
• Is this mainly a runtime dependency, build dependency, test dependency, or dev-tooling update?

Evidence and constraints

• Should I stay read-only, or should I prepare patching or rebase guidance if the PR is not merge-ready?
• Are there repository-specific checks or affected areas you want emphasized?
• If live GitHub context is incomplete, should I continue from a pasted PR summary or stop and ask for more detail?

Decision gate

• If the review finds follow-up work, should I propose turning it into an issue?
• If the recommendation is merge, should I stop and wait for explicit confirmation before any approval or merge action?