Dependabot Manager

Generate and maintain .github/dependabot.yml files with standardized settings.

Core Rules

Every generated dependabot.yml must follow these rules — no exceptions:

1. Only ecosystems the repo actually uses. Detect which package managers are present (see "Detecting Ecosystems in Use" below) and write an entry for each one. Do not emit commented-out entries for unused ecosystems — they are noise, they go stale as GitHub adds ecosystems, and re-running this skill is cheaper than maintaining a catalogue in every repo. If the user explicitly asks for an ecosystem you found no evidence for, add it and say so.
2. Daily schedule. Every entry uses schedule.interval: "daily".
3. Three-day cooldown minimum. Every entry includes a cooldown block with at least default-days: 3. If the user has set a longer cooldown (e.g., default-days: 7 or SemVer-specific overrides like semver-major-days: 14), preserve those longer values. Only add or raise to 3 if missing, set to 0, or set below 3.
4. Language-specific label. Every entry's labels array must contain "dependencies" plus the language label from the mapping table below. If the user has additional labels beyond these two, preserve them.
5. Directory defaults to /. If you know or discover the repo is a monorepo, use directories with the appropriate paths instead. Note that only the plural directories supports globbing — directory takes a single literal path.

Ecosystem Reference Table

Use exactly these package-ecosystem YAML values. The "Label" column is the language/platform label to apply.

Note: npm covers npm, pnpm, and Yarn. pip covers pip, pip-compile, pipenv, and poetry. Only one entry per unique YAML value is needed.

Template for Each Ecosystem Entry

  - package-ecosystem: "<YAML_VALUE>"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 3
    labels:
      - "dependencies"
      - "<LABEL>"

Detecting Ecosystems in Use

Because only ecosystems actually in use get an entry, detection is the first step of every run. Look for these manifest and lockfile markers:

Two ambiguous cases worth resolving rather than guessing:

• pip vs uv. These are separate Dependabot ecosystems and a project can legitimately need both. If uv.lock exists, add uv. If there is also a requirements*.txt that uv does not manage, add pip too. When it's genuinely unclear, ask.
• terraform vs opentofu. Bare .tf files alone don't tell you which. Default to terraform and ask if the repo shows any OpenTofu-specific signal (.tofu files, tofu in CI, an OpenTofu-generated lockfile).

If you cannot inspect the repository — the user pasted a config with no surrounding context, say — ask which ecosystems they use rather than guessing or falling back to a full catalogue.

Workflow

Creating a New Config

1. Detect which ecosystems the repo uses (see above).
2. Start with version: 2 and an updates: block.
3. Add an entry for each detected ecosystem, plus any the user explicitly asked for.
4. Apply all core rules (daily, cooldown, labels).
5. Output the file to .github/dependabot.yml.
6. Tell the user which ecosystems you detected and which you skipped, so they can correct you if the detection missed something.

Updating an Existing Config

1. Read the existing dependabot.yml.
2. Add entries for any ecosystems the repo uses that aren't yet configured.
3. Leave alone configured ecosystems you found no evidence for — the user may know something the filesystem doesn't. Mention them in the summary rather than deleting them.
4. Remove any entries for ecosystems not in the supported table (these may be typos or deprecated values).
5. Remove reviewers. GitHub removed this option in August 2025; it no longer does anything. Point the user at CODEOWNERS as the replacement. This is the one property that gets deleted rather than preserved, so call it out explicitly in the summary. (assignees is not deprecated — keep it.)
6. Fix any entries that violate core rules:
   • Interval not daily → set to daily.
   • Missing cooldown → add cooldown: { default-days: 3 }. If cooldown exists but default-days is missing, 0, or below 3, set it to 3. If default-days is already >= 3, keep it. Preserve any SemVer-specific overrides (semver-major-days, semver-minor-days, semver-patch-days) and include/exclude lists.
   • Missing required labels → add "dependencies" and the ecosystem's language label. Do not remove any extra labels the user has added.
7. Inform the user of every change made, in a concise summary. They need awareness, not approval.
8. Preserve any additional valid config the user has (e.g., ignore, allow, groups, multi-ecosystem-groups, registries, assignees, commit-message, open-pull-requests-limit, etc.).

Monorepo Detection

If you see evidence of a monorepo (multiple package.json files, workspace configs, lerna.json, pnpm-workspace.yaml, multiple go.mod files, etc.), switch from directory: "/" to directories: with the appropriate paths.

Short Example

A complete .github/dependabot.yml for a repository that uses npm, pip, and github-actions — and nothing else. This is the whole file, not an excerpt: unused ecosystems are simply absent. Every entry follows the template above; substitute the YAML value and label for any other ecosystem from the reference table.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 3
    labels:
      - "dependencies"
      - "node"

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 3
    labels:
      - "dependencies"
      - "python"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 3
    labels:
      - "dependencies"
      - "actions"

Per-Language Example Files

Concrete entries for every supported ecosystem live alongside this skill in the examples/ directory, grouped by language family. Read the file for the languages your target repo uses, copy the entries you need, and merge them into the user's dependabot.yml. Do not load these files unless you actually need them — they exist so the SKILL.md stays focused.

Cooldown and Cadence

These two settings interact, and the interaction is the thing people get wrong.

Why three days. GitHub applies a 3-day cooldown to version updates by default now, even when cooldown is absent from the config entirely. Writing a shorter value than that produces a config that looks stricter than the platform default while actually being weaker than doing nothing. Three days is the floor because it is what you get anyway; setting it explicitly documents the intent and gives you an obvious place to raise it.

Why daily, despite the cooldown. The cooldown is measured from each release, not from a fixed point in the week, so a daily schedule is not made redundant by it. On a project that ships several times a week there is always a sliding window of releases coming out of cooldown, and a daily schedule picks each one up the day it becomes eligible. A weekly schedule would batch those into one large PR up to six days late for no security benefit. Daily plus a cooldown gives you both promptness and a vetting window.

Security updates are never delayed. cooldown applies to version updates only. Nothing in this configuration slows a security fix down — that's what makes a conservative version-update cadence safe to adopt.

Grouping and per-dependency overrides are the user's call. groups, multi-ecosystem-groups, ignore, and allow all depend on how a team wants to triage PRs, and there is no house default worth imposing. Preserve whatever the user has, and suggest grouping only if they say PR volume is a problem.

Important Notes

• pre-commit uses the python label because pre-commit is a Python-based tool, even though hooks can be for any language.
• opentofu uses the terraform label because OpenTofu is a Terraform fork and the community treats them as the same ecosystem.
• bun and deno both use the javascript label; npm uses node. This is deliberate — npm predates the others and its label is well established in existing repos.
• If the user has both pip and uv entries, that's valid — they are separate ecosystems in Dependabot despite both being Python. Keep both.
• Docker and Docker Compose are separate ecosystems and should each have their own entry.
• open-pull-requests-limit defaults to 5 for version updates. Security updates are counted separately.

Reference Documentation

If you need to look up any Dependabot configuration option (e.g., registries, groups, ignore, allow, versioning-strategy, etc.), fetch the official options reference:

https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference

Use the WebFetch tool on this URL whenever you encounter an unfamiliar option or need to verify correct syntax.