dependabot-review
starsforks
How to install dependabot-review?
thibautbaissac/rails_ai_agents/dependabot-review
$npx -y skills add ThibautBaissac/rails_ai_agents --skill dependabot-reviewReviews Dependabot gem upgrade PRs for breaking changes, codebase impact, and merge readiness. Use when user pastes a Dependabot PR URL, asks about a gem version bump, or wants to audit open dependency PRs ("which dep PRs are safe to merge", "audit our deps", "check dependabot").
SKILL.md
| 1 | # Dependabot Gem Upgrade Review |
| 2 | |
| 3 | Current repo: !`gh repo view --json nameWithOwner -q .nameWithOwner 2>/dev/null || echo "(unknown — run from inside the repo)"` |
| 4 | |
| 5 | Review Dependabot PRs and give the developer a concise, scannable verdict: what changed upstream, what could break (and how to fix it), what each gem touches in the codebase, and whether to merge. |
| 6 | |
| 7 | Trigger phrases for audit mode: "review all open dependabot PRs", "which dependabot PRs are ready to merge", "audit our dep upgrades", "go through the open dep PRs", "check dependabot", any request for a status/report on pending dependency updates. Trigger single-PR mode on any GitHub PR URL related to dependabot, gem upgrades, or "bump" in the title. If the intent is ambiguous, default to audit mode. |
| 8 | |
| 9 | ## Choosing a mode |
| 10 | |
| 11 | Pick the mode based on what the user asked for: |
| 12 | |
| 13 | - **Single-PR mode** — the user pasted a specific Dependabot PR URL or otherwise referenced one PR. Run the single-PR workflow below. |
| 14 | - **Audit mode** — the user asked about *all* open Dependabot PRs (phrases like "audit our deps", "review open dependabot PRs", "which dep upgrades are safe to merge"). Run the audit workflow. Do **not** ask the user to paste URLs — discover them with `gh`. |
| 15 | |
| 16 | If the intent is ambiguous (e.g., "review dependabot"), default to audit mode since it's the superset and shows what's available. |
| 17 | |
| 18 | ## Audit workflow (multiple PRs) |
| 19 | |
| 20 | ### Step A1: Discover open Dependabot PRs |
| 21 | |
| 22 | Determine the repo from the current working directory (`gh repo view --json nameWithOwner -q .nameWithOwner`). Then list open Dependabot PRs: |
| 23 | |
| 24 | ```bash |
| 25 | gh pr list --author "app/dependabot" --state open \ |
| 26 | --json number,title,url,createdAt,headRefName,labels \ |
| 27 | --limit 50 |
| 28 | ``` |
| 29 | |
| 30 | The `app/` prefix in the author filter is required — Dependabot authors as the bot account `app/dependabot`. If `gh` returns an empty list, tell the user "No open Dependabot PRs in <repo>." and stop. |
| 31 | |
| 32 | Before diving into analysis, surface the scope to the user in one line: "Found N open Dependabot PRs. Analyzing each now…" — this sets expectations when there are many to crunch through. |
| 33 | |
| 34 | ### Step A2: Analyze each PR |
| 35 | |
| 36 | For every PR returned, run the **single-PR workflow** (Steps 1-3 below) to gather bump type, changelog highlights, and codebase impact. Keep each analysis tight — you'll be producing per-PR sections for a combined report, not standalone documents. |
| 37 | |
| 38 | You can fetch independent PRs in parallel where the tool call structure allows it. |
| 39 | |
| 40 | ### Step A3: Produce the consolidated report |
| 41 | |
| 42 | Emit the report in this order: |
| 43 | 1. A short preamble: "Reviewed N open Dependabot PRs in <repo>." |
| 44 | 2. A **summary table** (see the "Audit summary table" section below for the shape). |
| 45 | 3. A **Details** section with one subsection per PR, each following the single-PR output format (but condensed — keep per-PR detail to ~15-25 lines). |
| 46 | 4. A closing **Overall recommendation** block: which PRs to merge now, which to investigate, which to hold. Group by verdict so the dev can work top-to-bottom. |
| 47 | |
| 48 | ### Step A4: Offer to post findings as PR comments |
| 49 | |
| 50 | After the consolidated report, follow the shared **"Posting findings to PRs"** section below. For audit mode, the opt-in prompt covers the whole batch ("yes / no / selective"), and the comment body for each PR is drawn from that PR's per-PR detail section in Step A3. |
| 51 | |
| 52 | ### Audit summary table |
| 53 | |
| 54 | The summary table is the first thing the dev reads — its job is to let them triage the whole batch in under a minute. Render it as a GitHub-flavored markdown table with these exact columns, in this order: |
| 55 | |
| 56 | | Column | Contents | |
| 57 | |------------|-----------------------------------------------------------------------| |
| 58 | | `#` | PR number, linked as `[#9170](url)` | |
| 59 | | `Gem` | Gem name. For multi-gem PRs, comma-separate (e.g., `rspec-core, rspec-expectations`) | |
| 60 | | `Bump` | `old → new` (e.g., `7.2.4 → 8.0.10`) | |
| 61 | | `Type` | `patch`, `minor`, or `major`. Prefix with `🔒` if the PR addresses a security advisory | |
| 62 | | `Age` | Days since `createdAt` (e.g., `3d`, `21d`) | |
| 63 | | `Verdict` | Abbreviated: `Merge`, `Verify`, `Investigate`, `Hold` | |
| 64 | | `Why` | One short clause (≤ 10 words). Concrete, not generic — e.g., "dev-only, no breaking changes" beats "looks safe" | |
| 65 | |
| 66 | **Sort order:** primary key is verdict in the order `Merge → Ver |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
