Dependabot Config Helper

dependabot-config-helper

A Category 3 ops tool. The user runs this against a target repo (or a paste of an existing dependabot.yml) and gets either a from-scratch config or a reviewed-and-recommended-changes diff. Defaults come from dependabot-strategy research — config follows policy, not the other way around.

When to use

• Onboarding a new repo to Dependabot — generate a starting dependabot.yml.
• Existing repo's Dependabot has gone off-rails (PR storm, ignored alerts, no security update path) — refactor.
• Org-wide audit: are repos' configs consistent with the policy?
• Adding a new ecosystem (npm + adding Docker, or Python + adding Terraform).

When NOT to use

• Strategic / policy questions → dependabot-strategy.
• Individual alert triage / suppression → out of scope for v1.
• Multi-repo sweeps to rewrite configs at scale — possible but the user should review the generated configs individually for now.

Required inputs

• Target stack: list of ecosystems present in the repo (npm, Maven, pip, Docker, Terraform, Go, etc.).
• Regulatory exposure: same lens as copilot-rollout-playbook — PCI-DSS, SOX, GDPR. Affects schedule + auto-merge defaults.
• Team size + bandwidth: affects open-pull-requests-limit. Small team → smaller limit + monthly cadence. Large team → larger limit + weekly cadence.
• Private registries used (if any): for registries: block.
• Reviewer team handle: for the reviewers: field.

Bank-specific defaults (loaded from dependabot-strategy research)

These defaults come from the strategy research; they're not generic GitHub guidance.

• Schedule cadence per ecosystem:
  • npm / pip / Go / Maven / Gradle: weekly (active velocity, weekly batch tolerable)
  • Docker / Terraform: monthly (base-image / module updates have higher blast radius)
  • GitHub Actions: weekly (per the Mini Shai-Hulud lens — Action versions matter)
• Grouped updates:
  • Always group applies-to: security-updates separately from applies-to: version-updates
  • Within version updates: group minor + patch together; major updates always individual
• open-pull-requests-limit: default 5; for teams smaller than 5 devs, set to 3
• Cooldown: 3 days on new releases for high-stakes ecosystems (npm, pip, Maven). Catches the worst supply-chain-attack windows.
• Reviewers: route security-updates to @security-team; version-updates to the repo's CODEOWNERS-implied team
• Labels: security, dependency-update for trackability
• Target branch: default branch UNLESS the repo has a gated develop branch
• Commit message convention: chore(deps): prefix for version, fix(security): for security updates

Workflow

1. If generating: a. Take inputs. b. Apply org defaults per ecosystem. c. Compose the YAML. d. Output the file content + a one-paragraph rationale per ecosystem.
2. If reviewing: a. Read the existing config. b. Diff against org defaults. c. Output the findings list (each with current / expected / severity / remediation). d. Produce a recommended-changes diff.
3. Persist the reasoning note (both modes) — after presenting the config or diff in chat, write the sibling audit note via vault-writer.write_research to vault/research/dependabot/YYYY-MM-DD-dependabot-config-{repo-slug}.md (frontmatter per research.yml, topic: dependabot) so the generation/review reasoning is queryable next session.

Output

A complete .github/dependabot.yml ready to commit, with header comments explaining the policy basis. Plus a sibling note at vault/research/dependabot/YYYY-MM-DD-dependabot-config-{repo-slug}.md documenting the generation reasoning for audit (written in workflow step 3).

Composes with

• dependabot-strategy — defaults source.
• ghas-config-reviewer — the Dependabot section of the GHAS baseline is informed by this skill's output.
• repo-golden-path-scorer — golden-path scoring includes presence + currency of dependabot.yml.
• vault-writer.write_research — persists the reasoning note (workflow step 3).

Acceptance test (for step 18 done-criteria)

Generate a dependabot.yml for a hypothetical target (e.g., Payments Engineering: Java + npm + Docker, regulated-data exposure). Confirm:

• All declared ecosystems represented.
• Grouped updates split security vs version.
• Schedule cadence matches the per-ecosystem defaults.
• open-pull-requests-limit set.
• Reviewer routing present.
• Header comment documents the policy basis with a date.