merge-deps

Work the dependency-bot queue — read the bot's open requests and the repo's security advisories, establish which updates are actually safe, and merge the ones the repo has opted into. Manual invocation only: nothing here fires on its own; merging is opt-in, and a major bump always waits for a human. The forge is chosen by config (the root forge key): GitHub through gh, where the queue is Dependabot's, and GitLab through glab, where it is the one account the config names.

Opted out? If the repo config sets mergeDeps to false, this skill is disabled for the repo — stop immediately and tell the user the merge-deps skill is turned off in .tituskirch-skills.json. An absent mergeDeps block is not disabled; it means report-only. Check .mergeDeps == false on the resolved config before any action. A missing jq or config exits non-zero too, so a pass is not evidence the config was read.

Workflow

1. Detect (read the repo — never assume)

• Forge and host — from the root forge key (github → gh, gitlab → glab; anything else → say it is not supported and stop) plus the host resolved per repo: forgeHost, else the origin remote, else whatever the CLI is already authenticated against (REFERENCE.md). Confirm the repo is reachable — gh repo view --json nameWithOwner,defaultBranchRef or glab repo view. If it fails (no remote on that forge, wrong host, or the CLI not authenticated), stop, naming the host tried.
• The bot's own config — .github/dependabot.yml, or Renovate's config (renovate.json, .gitlab/renovate.json, the renovate key in package.json), for context only: which ecosystems exist, their base branches, their groups, their cooldown. It tells you what to expect; it is never a selection input and never a tier input. No such file → the bot may still be raising requests from a preset or a group-level config; carry on.
• Config — .tituskirch-skills.json at the repo root (optional, committed). Keys: REFERENCE.md.

2. Select — the dependency bot only

Select strictly by author. This is the skill's one hard constraint and it has no exceptions. The author is a constant on GitHub and a configured identity on GitLab, and the reasoning behind that asymmetry — including why the key can only ever narrow — is The queue's author: