dependabot-config

# Dependabot Configuration Skill Produces the canonical `.github/dependabot.yml` configuration for any project. Always emit the complete canonical config, never a partial one, unless the user explicitly overrides a specific field after reviewing it. --- ## Canonical Configuration The authoritative configuration to emit is: ```yaml version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "daily" cooldown: default-days: 7 semver-major-days: 7 semver-minor-days: 3 semver-patch-days: 2 include: - "*" - package-ecosystem: "github-actions" directory: "/" schedule: interval: "daily" cooldown: default-days: 7 include: - "*" ``` --- ## Cooldown Rationale Document this to the user when relevant: | Field | Value | Reasoning | | ------------------- | ----- | ------------------------------------------------------ | | `default-days` | 7 | Catch-all safety buffer for uncategorised updates | | `semver-major-days` | 7 | Breaking changes warrant the longest review window | | `semver-minor-days` | 3 | New features; moderate confidence, shorter delay | | `semver-patch-days` | 2 | Bug/security fixes; high confidence, fast-track | | `include: ["*"]` | — | Apply cooldown rules to all packages without exception | --- ## Workflow ### 1. Identify context - Determine whether a `.github/dependabot.yml` already exists in the project. - **Exists**: read the file, explain any differences from the canonical config, and check whether the file is Calavera-managed or its installed hash matches the recorded Calavera state. Only overwrite it with a file tool when those managed-file safety conditions are satisfied. If the file is unmanaged or has local edits, report the differences and do not force a write. - **Does not exist**: create `.github/dependabot.yml` with the canonical config using a file tool. ### 2. Check for non-npm ecosystems If the project uses additional package ecosystems (e.g. `pip`, `cargo`, `bundler`, `docker`, `composer`), add an additional `updates` block per ecosystem using the same schedule. Keep `npm` and `github-actions` blocks unchanged. Apply semver-specific cooldown fields only to semver-capable ecosystems; omit those cooldown fields for ecosystems such as `docker` and `composer`. Use the references file for additional ecosystem identifiers if needed. ### 3. Handle directory variations If the user's project has packages in subdirectories (e.g. a monorepo), ask which directories need coverage and emit one block per directory per ecosystem, keeping all other fields from the canonical config intact. ### 4. Write the file Write the config directly to `.github/dependabot.yml` in the project root using a file tool — do not present it as a fenced code block for the user to copy manually. Ensure the `.github/` directory exists before writing. After writing, confirm the file path to the user and follow with a concise explanation of what was configured and why — particularly the cooldown strategy — without repeating every field verbatim. --- ## Constraints - **Never omit the `cooldown` block** from any ecosystem entry. - **`semver-*` cooldown fields are only valid for package managers that use semver** (e.g. `npm`, `pip`, `cargo`). Do not include `semver-major-days`, `semver-minor-days`, or `semver-patch-days` for `github-actions` or any other non-semver ecosystem — Dependabot will reject the config. - **Never change the canonical values** unless the user explicitly requests it and provides a reason (e.g. a monorepo with a stricter release cadence). - **Always include `github-actions`** as an ecosystem, even if the user only asked about npm or another runtime ecosystem. - **YAML formatting**: two-space indentation, string values quoted, list items with `- ` prefix. Validate indentation before emitting — malformed YAML is a silent failure in Dependabot. --- ## Reference See `references/ecosystems.md` for the full list of Dependabot-supported `package-ecosystem` identifiers and their directory conventions.