feat(skills): global /renovate skill — agent-managed dependency updates across all projects

[ivy]

Problem

I hack on a lot of personal projects. I deploy containers. I use mise, chezmoi, lazy.nvim, Go tools, npm tools, GitHub Actions — every project has its own dependency surface. I want everything pinned and auto-updated so I don't get caught running stale versions.

Renovate is the right tool for this, but its config is brutally complex. The dotfiles repo's renovate.json5 is 464 lines — 30 hand-rolled regex managers just for lazy-lock.json, plus custom managers for every mise backend, chezmoi externals, Go tools, Node tools. It works, but nobody should have to write that by hand, and nobody should have to read the Renovate docs to do it.

A global /renovate skill lets an agent handle all of this. Walk into any repo, say /renovate, and the agent figures out what needs pinning and makes it happen.

Skill scope

Location: ~/.claude/skills/renovate.md (global — works in any project)

Core capabilities

1. Bootstrap — Detect what's in the repo (package.json, go.mod, Dockerfile, docker-compose, .mise.toml, lazy-lock.json, GitHub Actions, Helm charts, Terraform, etc.), generate an appropriate renovate.json5 with sane defaults:

   • Schedule (weekday mornings)
   • Automerge rules (minor/patch for low-risk, manual for major)
   • Grouping (related deps together)
   • Pin digests for Docker and Actions
   • Custom regex managers for anything Renovate doesn't handle natively

2. Diagnose — "Why isn't Renovate updating X?" Inspect the config, cross-reference against actual dependency files, identify gaps in manager coverage. Suggest fixes.

3. Extend — "I added a new dependency type." Generate the custom manager entry for it — correct matchStrings regex, right datasourceTemplate, right managerFilePatterns.

4. Audit — "What's unpinned?" Scan the repo for dependencies that aren't covered by any Renovate manager. Report gaps.

Design constraints

• The skill should work in any repo, not just dotfiles. It should detect the project type and adapt.
• It should encode Renovate best practices so the human never has to read Renovate docs.
• It should know about common non-standard dependency formats: mise tool backends (aqua, ubi, npm, pipx), chezmoi externals, lazy.nvim lockfiles, Go tool manifests, etc.
• Generated config should be readable — comments explaining each section, grouped logically.

Evidence of the pain

The dotfiles renovate.json5 demonstrates the problem at scale:

• Lines 64–128: Custom regex managers for mise backends (aqua, ubi, npm, pipx), cosign, Go tools, Node tools — each a bespoke regex because Renovate doesn't understand these formats natively
• Lines 129–176: Chezmoi external dependencies — pinned tarballs and git revisions for oh-my-zsh, zsh plugins, tmux config
• Lines 183–462: One regex manager per neovim plugin (~30 entries) because lazy-lock.json uses directory names as keys, not full GitHub paths, requiring a manual name→org/repo mapping

Every time a plugin is added or removed, the config needs a matching update. This is exactly the kind of maintenance agents should own.

Principle 6 consideration

"if a tool's plugin ecosystem requires 40 custom Renovate regex managers and still barely works, maybe the answer isn't more regex"

The skill should be smart enough to suggest structural alternatives when a dependency format is fighting Renovate — e.g., generating a Renovate-friendly intermediate file from lazy-lock.json instead of one manager per plugin. The goal is keeping things updated, not preserving a specific config pattern.

Success criteria

• /renovate in a fresh repo produces a working renovate.json5 with no human Renovate-doc-reading required
• /renovate in an existing repo identifies unpinned dependencies and fills coverage gaps
• The skill handles the common personal-project stack: Node, Python, Go, Rust, Docker, Actions, mise, Terraform, Helm
• Agent can maintain the config over time as dependencies are added/removed