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 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?"
• PR title contains dependency update patterns (e.g. chore(deps):, fix(deps):, bump, update)
• User shares a PR URL for a dependency update

When not to use

• 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:

• Repository owner and name
• PR number or URL, or a copied PR summary including package name, version change, changed files, and CI status
• Optional: specific review concerns or areas of focus

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

If 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 user choose.
• Keep shortlist concise: 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 target PR with agents/target-pr-advisor.md and concise prompts in references/questions.md. 2. Gather context and build 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 recommendation, confidence, follow-up, and explicit maintainer prompt. 5. Use agents/source-control-advisor.md only after verdict is accepted and only when branch work is required. 6. Follow references/instructions.md for 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 and normalize evidence for dependency update review. Read-only, evidence-first; prepares record, does not decide 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 PR comments and review threads (live PR)

Unknown PR target: return to parent skill (agents/target-pr-advisor.md).

Source priorities

Portable, source-backed signals (priority 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. Ambiguous PR: stop, return to parent skill via agents/target-pr-advisor.md. 2. Live PR: fetch all PR comments and review threads via GitHub MCP before lens scoring. 3. Summarize PR discussion: maintainer requests, reviewer concerns, unresolved threads, outdated items. 4. Confirm exact version jump and update type. 5. Summarize release notes (old → new). 6. Record breaking changes, deprecations, migration steps. 7. Look for known regressions or open issues against target version. 8. Capture notable transitive dependency changes in diff. 9. Draft findings with sources, discussion context, unknowns. Same content as PR-comment-ready checkpoint. Title: # 🤖 Bip Bop - <title>.

Portable boundaries

Reusable patterns:

• When target PR unknown: ask minimal follow-up or present shortlist via agents/target-pr-advisor.md
• 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, post completed research packet as checkpoint comment before any rebase, push, approval, or merge
• Explicit consent gate before any approval, merge, or PR mutation

Don't import repo-specific branch/rebase/push/package-manager automation unless repo 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 detail to re-check 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

• Don't fabricate changelog entries or issue reports
• Don't claim source checked if not
• Don't guess between multiple plausible PRs; require explicit user selection
• No lens scoring until PR comments/threads fetched or escalated as unavailable
• No mutation planning until checkpoint comment posted or escalated as blocked
• Read-only until maintainer asks for 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 research, security, code quality, impact into dependency-review decision. Preserve disagreements. Owns confidence model, handoff, action gate. Never approve/merge without explicit maintainer confirmation.

Inputs

• Package name, versions, ecosystem, and update type
• PR discussion summary (unresolved threads, maintainer requests, 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 research, PR discussion, and three lens outputs present. Flag missing. 2. Surface strongest +/- signals and open reviewer concerns. 3. Apply recommendation rules:

• Any blocking lens → verdict must be hold or decline
• Unresolved reviewer concerns usually prevent merge
• Concerns without blocker: merge with follow-up or hold by evidence gaps
• All-clear + green CI + bounded blast radius: can support merge

4. Apply confidence model:

• high: consistent evidence, green CI, no blocker, low/bounded blast radius
• medium: no blocker, but concern remains, moderate impact, or partial source coverage
• low: ambiguity, failing/unknown CI, missing release notes, conflicting findings

5. Hand off follow-up via fusion-issue-authoring (Task, Bug, or User Story). 6. Final PR comment: work since checkpoint, validation state, requested action. Title: # 🤖 Bip Bop - <title>. 7. End with explicit action prompt: approve / hold / decline / create follow-up.

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
• Don't ignore unresolved threads unless packet explains why outdated/addressed
• No approval/merge until verdict comment posted
• Conflicting sources: reflect in confidence/recommendation
• Bias ambiguous/high-risk to hold until evidence 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.4 - 2026-05-07

patch

• #170 `5e43223` - Apply caveman-compress prose style to SKILL.md, agents, and references.

• Drop articles, filler, hedging from SKILL.md activation body
• Compress research-advisor and verdict-advisor agent files
• Compress instructions and questions references

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

Expanded execution contract. Keep SKILL.md focused on activation, orchestration, and safety; use this file for 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 request ambiguous (e.g. review the dependency PR), ask only minimum follow-up to identify target. 3. When repo known but PR unknown, use GitHub MCP to list open dependency PRs for user to choose. 4. Prefer likely dependency-update candidates first: bot-authored PRs, titles with deps, bump, update, or ecosystem-specific wording. 5. Multiple plausible PRs: don't guess. Wait for user to choose before continuing. 6. If live PR access unavailable, ask for PR URL, PR number, or pasted 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 all existing PR comments and review threads via GitHub MCP before analysis (timeline + threaded review feedback). 3. Summarize the current PR discussion: maintainer requests, reviewer concerns, unresolved threads, prior agent comments, and decisions already made. 4. If retrieval fails, stop before analysis and notify maintainer that 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 diff to see changed files (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 no live access, normalize user-provided summary into the same fields and continue only if sufficient.

Step 2 — Research and prepare the evidence packet

1. Refine the Step 1 discussion summary: highlight maintainer instructions, prior reviewer findings, unanswered questions, and unresolved threads. Distinguish 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 without evidence-based resolution reduce confidence and usually prevent a merge recommendation. 6. Treat the verdict as a comment-ready artifact. Fold patching/rebase/validation results into the final verdict before posting.

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 minimum 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?