auto-merge-dependabot
Skill2 starsChanged 4 months agoMITView on GitHub
This skill should be used when the user asks to "merge dependabot PRs", "review dependabot", "auto-merge dependencies", "handle dependabot", "merge dependency updates", "check dependabot PRs", or wants to automatically review and merge open Dependabot pull requests. Also triggered by the /auto-merge-dependabot command.
In this repository20 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- best-ofSkill
- codestorySkill
- codex-2nd-opinionSkill
- cpSkill
- extract-design-systemSkill
- investigateSkill
- is-skillSkill
- pm-autofix-prSkill
- pm-crSkill
- pm-deepenSkill
- pm-planSkill
- pm-riskSkill
- pm-simplifySkill
- pm-triageSkill
- rebase-prSkill
- review-offlineSkill
- upscaleSkill
- vibeSkill
- wigoSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 4 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 21
If this fails, report the error and stop — the user likely needs to authenticate with gh auth login or is not inside a Git repository.
- Distinctive: line 31
If there are no open Dependabot PRs, inform the user and stop.
- Distinctive: line 55
All checks passed: Good to merge.
- Very specific: line 65
Only lockfile and manifest changes (e.g., package-lock.json, Cargo.lock, go.sum, Gemfile.lock, poetry.lock, requirements.txt): Low risk.
- Very specific: line 72
If CONFLICTING: Flag for rebase (will comment @dependabot rebase in Step 5).
- Very specific: line 73
If MERGEABLE or UNKNOWN: Continue with other checks.
- Very specific: line 110
Use --squash to keep the commit history clean.
- Distinctive: line 112
If a merge fails due to merge conflicts, do not close the PR.
- Distinctive: line 142
If any PRs were skipped, ask the user: "Would you like me to review any of the skipped PRs in more detail, or merge specific ones despite …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Auto-Merge Dependabot PRs
Review all open Dependabot pull requests in the current repository. Assess each PR for risk, and automatically merge those that are safe. Report any PRs that were skipped with clear reasoning.
Workflow
Step 1: Identify Repository
Determine the current GitHub repository using:
gh repo view --json nameWithOwner -q '.nameWithOwner'If this fails, report the error and stop — the user likely needs to authenticate with gh auth login or is not inside a Git repository.
Step 2: List Open Dependabot PRs
Fetch all open PRs authored by Dependabot:
gh pr list --author 'app/dependabot' --state open --json number,title,url,headRefName,body,labels,additions,deletions,files --limit 100If there are no open Dependabot PRs, inform the user and stop.
Present a summary table to the user:
## Open Dependabot PRs
| # | Title | Files Changed | +/- |
|---|-------|---------------|-----|Step 3: Review Each PR
For each PR, assess the risk by checking:
- Version bump type — Parse the PR title/body for semver information:
- Patch (e.g., 1.2.3 → 1.2.4): Low risk. Auto-merge candidate.
- Minor (e.g., 1.2.3 → 1.3.0): Low risk. Auto-merge candidate.
- Major (e.g., 1.2.3 → 2.0.0): High risk. Skip and flag.
- CI status — Check if CI checks have passed:
gh pr checks <number> --json name,state- All checks passed: Good to merge.
- Any check failed: Skip and flag.
- Checks still pending: Skip and flag.
- Security advisories — Look at the PR body for GitHub security advisory mentions. Dependabot security updates should be prioritized.
- Scope of changes — Review the changed files:
gh pr diff <number> --name-only- Only lockfile and manifest changes (e.g.,
package-lock.json,Cargo.lock,go.sum,Gemfile.lock,poetry.lock,requirements.txt): Low risk. - Source code changes or configuration changes beyond dependency files: Flag for review.
- Only lockfile and manifest changes (e.g.,
- Merge conflicts — Check if the PR has conflicts:
gh pr view <number> --json mergeable -q '.mergeable'- If
CONFLICTING: Flag for rebase (will comment@dependabot rebasein Step 5). - If
MERGEABLEorUNKNOWN: Continue with other checks.
- If
Classify each PR into one of:
- SAFE TO MERGE: Patch/minor bump, CI passes, only dependency file changes, no conflicts.
- NEEDS REBASE: Has merge conflicts — will request Dependabot rebase.
- NEEDS REVIEW: Major bump, CI failures/pending, or unexpected file changes.
Step 4: Present Review Summary
Present the review results clearly:
## Review Summary
### Safe to Merge
| # | Title | Reason |
|---|-------|--------|
### Needs Manual Review
| # | Title | Concern |
|---|-------|---------|Step 5: Merge Safe PRs
For each PR classified as NEEDS REBASE, comment to request a rebase:
gh pr comment <number> --body "@dependabot rebase"For each PR classified as SAFE TO MERGE, merge it:
gh pr merge <number> --squash --autoUse --squash to keep the commit history clean. Use --auto so that GitHub waits for required status checks before merging.
If a merge fails due to merge conflicts, do not close the PR. Instead, comment on it to request a rebase:
gh pr comment <number> --body "@dependabot rebase"Record it as "Requested rebase" and continue with the remaining PRs.
For other merge failures (non-conflict errors), record the error and continue.
Step 6: Final Report
Present a final summary:
## Results
### Merged
- #<number>: <title> ✓
### Requested Rebase (Conflicts)
- #<number>: <title> — commented @dependabot rebase
### Skipped (Needs Review)
- #<number>: <title> — <reason>
### Failed to Merge
- #<number>: <title> — <error>If any PRs were skipped, ask the user: "Would you like me to review any of the skipped PRs in more detail, or merge specific ones despite the concerns?"
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

