What this prompt does
This prompt sets up automated dependency management for a [language]/[framework] project with [dep_count] dependencies. It first compares Dependabot and Renovate, then configures your [chosen_tool] with a real update [schedule], grouped PRs using your [grouping_strategy], auto-merge rules, security-only updates for production dependencies, and a dashboard issue for tracking pending work.
It works because it turns a flood of update noise into a manageable stream. Grouping related updates by [grouping_strategy] (lint tools together, testing together) collapses dozens of separate PRs into a few reviewable ones, and auto-merging passing patch and minor updates clears the routine churn automatically. The [ignored_deps] placeholder pins things you can't safely bump, major versions get separate PRs with migration notes so breaking changes are reviewed deliberately, and a dashboard issue keeps pending work visible — so updates stop piling into a security and maintenance backlog.
When to use it
- Dependency updates have piled up into a security and maintenance backlog
- You're drowning in individual update PRs and want them grouped sensibly
- Choosing between Dependabot and Renovate and want the trade-offs laid out
- You want to auto-merge passing patch/minor updates but review majors carefully
- Certain
[ignored_deps]must stay pinned and you need rules to exclude them - You want a single dashboard issue tracking all pending updates
Example output
You get a complete configuration: a Dependabot-versus-Renovate comparison, the full config file for [chosen_tool] with a [schedule] and PRs grouped by [grouping_strategy], auto-merge rules for patch/minor with passing CI, security-only update handling for production dependencies, separate major-version PRs with migration notes, ignore rules for [ignored_deps], custom labels and reviewers, a lockfile-maintenance schedule, a dashboard tracking issue, and an onboarding guide for the team.
Pro tips
- Set
[dep_count]and[language]/[framework]accurately so the grouping and ecosystem rules fit your real package manager - Choose
[grouping_strategy]to match how you reason about updates; grouping by ecosystem keeps related bumps in one reviewable PR - Be conservative with auto-merge — patch and minor with green CI is usually safe, but hold majors for manual review and migration notes
- List
[ignored_deps]explicitly (a pinned bundler, a separately-managed runtime) so automation never breaks a fragile compatibility - Pick a
[schedule]your team can absorb; a weekly batch on a quiet day beats a daily trickle that gets ignored and stacks up - Add a test pipeline that runs extended checks on update PRs, so an auto-merged minor bump can't quietly break something CI would have caught
- Route security-only updates for production dependencies on a faster track, since those matter more than routine version churn in dev tooling
- Keep the dashboard issue visible so updates that can't auto-merge don't silently rot in the backlog