/dependabot

name: dependabot
description: >-
  Comprehensive guide for configuring and managing GitHub Dependabot. Use this skill when
  users ask about creating or optimizing dependabot.yml files, managing Dependabot pull requests,
  configuring dependency update strategies, setting up grouped updates, monorepo patterns,
  multi-ecosystem groups, security update configuration, auto-triage rules, or any GitHub
  Advanced Security (GHAS) supply chain security topic related to Dependabot. For pre-commit
  dependency vulnerability scanning in AI coding agents via the GitHub MCP Server, this skill
  references the Advanced Security plugin (`advanced-security@copilot-plugins`). Use this skill
  when an agent needs to scan dependencies for known vulnerabilities before committing.

Dependabot Configuration & Management

Overview

Dependabot is GitHub's built-in dependency management tool with three core capabilities:

1. **Dependabot Alerts** — Notify when dependencies have known vulnerabilities (CVEs) 2. **Dependabot Security Updates** — Auto-create PRs to fix vulnerable dependencies 3. **Dependabot Version Updates** — Auto-create PRs to keep dependencies current

All configuration lives in a **single file**: `.github/dependabot.yml` on the default branch. GitHub does **not** support multiple `dependabot.yml` files per repository.

Configuration Workflow

Follow this process when creating or optimizing a `dependabot.yml`:

Step 1: Detect All Ecosystems

Scan the repository for dependency manifests. Look for:

| Ecosystem | YAML Value | Manifest Files | |---|---|---| | npm/pnpm/yarn | `npm` | `package.json`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock` | | pip/pipenv/poetry | `pip` | `requirements.txt`, `Pipfile`, `pyproject.toml`, `setup.py` | | uv | `uv` | `pyproject.toml`, `uv.lock` | | Docker | `docker` | `Dockerfile` | | Docker Compose | `docker-compose` | `docker-compose.yml` | | GitHub Actions | `github-actions` | `.github/workflows/*.yml` | | Go modules | `gomod` | `go.mod` | | Bundler (Ruby) | `bundler` | `Gemfile` | | Cargo (Rust) | `cargo` | `Cargo.toml` | | Composer (PHP) | `composer` | `composer.json` | | NuGet (.NET) | `nuget` | `*.csproj`, `packages.config` | | .NET SDK | `dotnet-sdk` | `global.json` | | Maven (Java) | `maven` | `pom.xml` | | Gradle (Java) | `gradle` | `build.gradle` | | Terraform | `terraform` | `*.tf` | | OpenTofu | `opentofu` | `*.tf` | | Helm | `helm` | `Chart.yaml` | | Hex (Elixir) | `mix` | `mix.exs` | | Swift | `swift` | `Package.swift` | | Pub (Dart) | `pub` | `pubspec.yaml` | | Bun | `bun` | `bun.lockb` | | Dev Containers | `devcontainers` | `devcontainer.json` | | Git Submodules | `gitsubmodule` | `.gitmodules` | | Pre-commit | `pre-commit` | `.pre-commit-config.yaml` |

Notes:

• pnpm and yarn both use the `npm` ecosystem value.
• Prefer `uv` ecosystem value when `uv.lock` is present; otherwise use `pip`.

Step 2: Map Directory Locations

For each ecosystem, identify where manifests live. Use `directories` (plural) with glob patterns for monorepos:

directories:
  - "/"           # root
  - "/apps/*"     # all app subdirs
  - "/packages/*" # all package subdirs
  - "/lib-*"      # dirs starting with lib-
  - "**/*"        # recursive (all subdirs)

Important: `directory` (singular) does NOT support globs. Use `directories` (plural) for wildcards.

Step 3: Configure Each Ecosystem Entry

Every entry needs at minimum:

- package-ecosystem: "npm"
  directory: "/"
  schedule:
    interval: "weekly"

Step 4: Optimize with Grouping, Labels, and Scheduling

See sections below for each optimization technique.

Monorepo Strategies

Glob Patterns for Workspace Coverage

For monorepos with many packages, use glob patterns to avoid listing each directory:

- package-ecosystem: "npm"
  directories:
    - "/"
    - "/apps/*"
    - "/packages/*"
    - "/services/*"
  schedule:
    interval: "weekly"

Cross-Directory Grouping

Use `group-by: dependency-name` to create a single PR when the same dependency updates across multiple directories:

groups:
  monorepo-deps:
    group-by: dependency-name

This creates one PR per dependency across all specified directories, reducing CI costs and review burden.

Limitations:

• All directories must use the same package ecosystem
• Applies to version updates only
• Incompatible version constraints create separate PRs

Standalone Packages Outside Workspaces

If a directory has its own lockfile and is NOT part of the workspace (e.g., scripts in `.github/`), create a separate ecosystem entry for it.

Dependency Grouping

Reduce PR noise by grouping related dependencies into single PRs.

By Dependency Type

groups:
  dev-dependencies:
    dependency-type: "development"
    update-types: ["minor", "patch"]
  production-dependencies:
    dependency-type: "production"
    update-types: ["minor", "patch"]

By Name Pattern

groups:
  angular:
    patterns: ["@angular*"]
    update-types: ["minor", "patch"]
  testing:
    patterns: ["jest*", "@testing-library*", "ts-jest"]

For Security Updates

groups:
  security-patches:
    applies-to: security-updates
    patterns: ["*"]
    update-types: ["patch", "minor"]

Key behaviors:

• Dependencies matching multiple groups go to the **first** match
• `applies-to` defaults to `version-updates` when absent
• Ungrouped dependencies get individual PRs

Multi-Ecosystem Groups

Combine updates across different package ecosystems into a single PR:

version: 2

multi-ecosystem-groups:
  infrastructure:
    schedule:
      interval: "weekly"
    labels: ["infrastructure", "dependencies"]

updates:
  - package-ecosystem: "docker"
    directory: "/"
    patterns: ["nginx", "redis"]
    multi-ecosystem-group: "infrastructure"

  - package-ecosystem: "terraform"
    directory: "/"
    patterns: ["aws*"]
    multi-ecosystem-group: "infrastructure"

The `patter