GitHub Dependabot Setup

Use this skill when you need to create, review, or update .github/dependabot.yml.

This is a review-first skill. Do not copy a generic Dependabot file into a repo without first inspecting what the repo actually uses.

Default posture

• Inspect the target repository before drafting any config.
• Configure only the ecosystems and directories that actually exist in the repo.
• Treat private registries, beta features, and insecure execution settings as opt-in only.
• Keep the generated file minimal and explain any enterprise-specific settings that are included.

Working template and reference repo

The local file below is a working UHG example:

• ./template/dependabot.yml

Treat it as a reference implementation, not a universal default.

The bundled template intentionally defaults risky options off. Any use of beta ecosystems or insecure external code execution must be an explicit repo-level decision, not something copied in by default.

It is useful because it demonstrates a real enterprise setup with:

• multiple package ecosystems
• private Artifactory-style registries
• GitHub Actions updates
• timezone and scheduling examples

It is not safe to copy wholesale into every repo because it may include:

• ecosystems the target repo does not use
• registry names or secret names that do not exist in the target repo
• enable-beta-ecosystems
• insecure-external-code-execution: allow

In the template, these are shown as commented opt-in toggles. Only uncomment them when the target repository has been reviewed and the need is documented.

Use the local template only after checking which parts actually apply.

You can also review this known working example repo for additional context:

• optum-eeps/epl-arc-optum-runnerimage
• README
• Pinned Dependabot example

Use gh or other available GitHub tooling to inspect the repo if needed.

Review workflow

Step 1: Inspect the target repo

Identify the package ecosystems that are actually present. Check for files such as:

• package.json
• package-lock.json
• pnpm-lock.yaml
• yarn.lock
• requirements.txt
• pyproject.toml
• Gemfile
• pom.xml
• build.gradle
• Dockerfile
• .github/workflows/*.yml
• *.tf

Also inspect the repo layout to confirm whether updates should be rooted at / or split across subdirectories.

Step 2: Check registry and credential requirements

Before adding a registries: section, confirm:

• the repo actually uses private registries
• the registry URL is correct
• the required Dependabot secret names already exist or are part of the requested change
• the chosen registry type matches the package ecosystem

Do not invent secret names or cargo-cult them from another repo.

Step 3: Start from the minimal valid config

Prefer the smallest valid .github/dependabot.yml that matches the repo.

Good defaults:

• version: 2
• one updates: entry per ecosystem and directory actually in use
• explicit schedule
• reasonable open-pull-requests-limit

Only add these when justified:

• registries
• rebase-strategy
• versioning-strategy
• groups
• allow / ignore
• enable-beta-ecosystems
• insecure-external-code-execution: allow

If you enable either one, call it out explicitly in the output and explain why the safer default was not sufficient for that repository.

Step 4: Adapt the working example carefully

If the target repo resembles the bundled template, copy only the relevant pieces from ./template/dependabot.yml.

Examples:

• keep the npm block if the repo has Node manifests
• keep the github-actions block if workflows consume external actions
• keep a private registry block only if the repo actually resolves dependencies through that registry
• drop bundler, pip, maven, gradle, docker, or terraform entries when those ecosystems are absent

Step 5: Verify before finalizing

Before presenting or committing the file, verify:

• every configured ecosystem exists in the repo
• every directory path exists
• every registry name referenced by an update block exists under registries:
• every required secret name is intentional
• any risky option is explicitly justified

Output expectations

When using this skill, produce:

1. a short summary of the ecosystems detected in the target repo
2. the proposed .github/dependabot.yml
3. a short note explaining any non-default settings such as private registries, beta ecosystems, grouping, or insecure execution allowances

If required registry secrets or repo conventions are missing, say so clearly instead of guessing.

Safe defaults

Prefer these update blocks when applicable:

• npm
• github-actions
• docker
• terraform
• pip
• maven
• gradle
• bundler

But only include an ecosystem when the repo actually uses it.

Default to avoiding insecure-external-code-execution: allow unless the ecosystem genuinely requires it and the user wants that behavior.

Default to avoiding enable-beta-ecosystems unless the repo depends on a beta ecosystem or the example has already been validated for that repo family.