Add dependabot-stack skill

[justwiebe]

Why

Dependabot's weekly grouped-update PRs arrive as several independent PRs that all touch the same lockfiles, so reviewing and merging them means resolving the same conflicts repeatedly. This skill orders them by file overlap and rebases them into one stack that merges bottom-up as a single chain.

The skill was written and used against fmi-atlas; it takes the repository from gh repo view (or an argument) so any RoleModel project can run it.

What Changed

• Add the dependabot-stack skill
• List it in the README and AGENTS.md skill inventories

Screenshots

N/A — no UI changes

[Copilot]

Pull request overview

Adds a new dependabot-stack skill to this skills repository, documenting a repeatable workflow for ordering and stacking weekly Dependabot PRs into a single gh-stack chain to minimize repeated lockfile conflict resolution.

Changes:

• Added skills/dependabot-stack/SKILL.md with a step-by-step procedure for ordering, rebasing (in a scratch worktree), force-pushing, and linking PRs via gh stack link.
• Listed the new skill in the README skills table.
• Added the new skill to the AGENTS.md skill inventory.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
skills/dependabot-stack/SKILL.md	New skill definition documenting the Dependabot PR stacking workflow.
README.md	Adds the new skill to the public skills index table.
AGENTS.md	Adds the new skill to the repository’s skill inventory list.

Suppressed comments (2)

skills/dependabot-stack/SKILL.md:101

• After git fetch origin <branch>..., local branches typically do not exist yet, so git checkout -q <branch-N> can fail. Consider creating/updating a local branch from origin/<branch> before rebasing so the instructions work reliably.

git checkout -q <branch-N>
git rebase <branch-N-minus-1>   # use origin/<branch> if no local branch exists yet

skills/dependabot-stack/SKILL.md:93

• Step 3 hard-codes main for the worktree base, but Step 0 notes that the default branch may not be main. This will fail on repos whose default branch is master (or something else). Capture the default branch name and use it here.

WT=$(mktemp -d)/stack-wt
git worktree add "$WT" main
cd "$WT"
git fetch origin <branch-1> <branch-2> ... <branch-N>

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (4)

skills/dependabot-stack/SKILL.md:36

• This section says to “clone it to a temp directory first and run those steps there”, but Step 0 already captured $ROOT / $ORIGINAL_BRANCH from the current checkout. If you change directories into a clone without recomputing those values, later steps (cleanup and “switch back” messaging) will be inaccurate/confusing.

Steps 3 and 4 rebase and push locally, so they need a checkout of `$REPO`. When
the user named a different repo than the current directory, clone it to a temp
directory first and run those steps there. `main` below stands for
`$DEFAULT_BRANCH`.

skills/dependabot-stack/SKILL.md:108

• git checkout -q <branch-N> can fail if the branch doesn’t already exist locally (a plain git fetch origin <branch> updates origin/<branch> but may not create a local branch). Since the next step rebases and then later force-pushes, it’s safer to explicitly create/reset the local branch from origin/<branch> before rebasing.

git checkout -q <branch-N>
git rebase <branch-N-minus-1>   # use origin/<branch> if no local branch exists yet

skills/dependabot-stack/SKILL.md:152

• If this skill is run against a different repo by cloning into a temp directory (as described in Step 0), $ORIGINAL_BRANCH may not exist in that checkout. This final step would read more accurately if it handled that case explicitly.

Then switch back to whatever branch the user was on before this skill ran:

```bash
git checkout "$ORIGINAL_BRANCH"

skills/dependabot-stack/SKILL.md:4

• The allowed-tools allowlist here doesn’t match the command patterns used elsewhere in this repo (e.g., Bash(git fetch:* / Bash(git push:* in skills/file-pr/SKILL.md:11 and skills/split-stack/SKILL.md:8). Entries like Bash(git fetch origin:*), Bash(git push origin:*), and Bash(cd:*) are likely too specific / nonstandard and may prevent the skill from executing the documented commands. Also, Step 0 mentions cloning a different repo, but cloning isn’t currently allowed by this list.

This issue also appears in the following locations of the same file:

• line 33
• line 107
• line 149

allowed-tools: Bash(gh pr list:*) Bash(gh pr diff:*) Bash(gh repo view:*) Bash(gh extension list:*) Bash(gh extension install github/gh-stack:*) Bash(gh stack:*) Bash(git worktree add:*) Bash(git worktree remove:*) Bash(git fetch origin:*) Bash(git checkout:*) Bash(git rebase:*) Bash(git push origin:*) Bash(git rev-parse:*) Bash(git branch:*) Bash(mktemp:*) Bash(cd:*)

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (3)

skills/dependabot-stack/SKILL.md:26

• Step 0's snippet runs gh repo view and git rev-parse unconditionally. If the skill is invoked outside a git checkout (which the text explicitly calls out as possible), this will fail before you can prompt the user for a repo. Consider guarding and emitting a clear message before exiting.

REPO="${ARGUMENTS:-$(gh repo view --json nameWithOwner --jq .nameWithOwner)}"
DEFAULT_BRANCH=$(gh repo view "$REPO" --json defaultBranchRef --jq .defaultBranchRef.name)
ROOT=$(git rev-parse --show-toplevel)
ORIGINAL_BRANCH=$(git branch --show-current)

skills/dependabot-stack/SKILL.md:52

• package.json isn't a lockfile, so calling it out as one is misleading for the overlap rules you’re describing here. Reword this to describe the dependency file family (package.json + its lockfile such as yarn.lock/package-lock.json/pnpm-lock.yaml).

Ordering is driven by file overlap, not just category: two PRs that touch the
same lockfile (`Gemfile.lock`, `yarn.lock`/`package.json`) MUST be adjacent in
the stack in a fixed priority order, because rebasing one on the other is what
avoids a manual lockfile-conflict resolution later. PRs touching disjoint files

skills/dependabot-stack/SKILL.md:4

• allowed-tools grants gh extension install github/gh-stack:*, which allows installing arbitrary extensions/flags. For least-privilege (and consistency with skills/split-stack/SKILL.md), restrict this to installing only github/gh-stack without a wildcard.

allowed-tools: Bash(gh pr list:*) Bash(gh pr diff:*) Bash(gh repo view:*) Bash(gh extension list:*) Bash(gh extension install github/gh-stack:*) Bash(gh stack:*) Bash(git worktree:*) Bash(git fetch:*) Bash(git checkout:*) Bash(git rebase:*) Bash(git push:*) Bash(git rev-parse:*) Bash(git branch:*) Bash(mktemp:*)

[wesrich]

Ran this today on RoleModel/nhcs (not fmi-atlas) — worked well overall, two small notes:

Step 2 priority list doesn't mention *-major-updates. We had a production-major-updates PR this week alongside the minor-updates groups. It's possible major-updates is meant to be excluded deliberately, since major bumps often need manual review rather than auto-stacking — if so, worth saying that explicitly (e.g. "major-updates PRs are left out of the stack on purpose; handle them separately") so it reads as a decision rather than a gap. If it wasn't intentional, it should be added to the priority list like the other groups.

Lockfile-conflict guidance undersells yarn conflicts. The note says to resolve Gemfile/package.json by hand then regenerate with bundle lock/yarn install. In our case package.json auto-merged fine, but yarn.lock's own dependency-metadata block conflicted independently — worth calling that out as a possible conflict site, not just the manifest files. Also, plain yarn install installs node_modules into the scratch worktree unnecessarily; yarn install --mode=update-lockfile regenerates the lockfile without that overhead.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (3)

skills/dependabot-stack/SKILL.md:5

• The skill frontmatter is missing metadata.triggers (required by AGENTS.md for skill activation) and allowed-tools doesn’t permit commands that the skill instructs the agent to run later (bundle lock, yarn install). This will make the skill harder to trigger automatically and may fail at runtime due to tool restrictions.

---
name: dependabot-stack
description: Group all open Dependabot PRs on a repository into a single ordered stack using gh-stack. Run weekly, after Dependabot's batch of grouped-update PRs lands. Use when asked to stack, organize, or clean up Dependabot PRs.
allowed-tools: Bash(gh pr list:*) Bash(gh pr diff:*) Bash(gh repo view:*) Bash(gh extension list:*) Bash(gh extension install github/gh-stack:*) Bash(gh stack:*) Bash(git worktree:*) Bash(git fetch:*) Bash(git checkout:*) Bash(git rebase:*) Bash(git push:*) Bash(git rev-parse:*) Bash(git branch:*) Bash(mktemp:*)
---

skills/dependabot-stack/SKILL.md:107

• The scratch worktree is created from the local $DEFAULT_BRANCH, but the skill never fetches the latest default branch from origin first. If the user’s local default branch is stale, the entire rebase stack can be based on an outdated commit and reintroduce conflicts or require a second rebase later.

WT=$(mktemp -d)/stack-wt
git worktree add "$WT" "$DEFAULT_BRANCH"
cd "$WT"
git fetch origin <branch-1> <branch-2> ... <branch-N>
git checkout -q -B <branch-1> origin/<branch-1>

skills/dependabot-stack/SKILL.md:26

• Step 0 says only an owner/name value in $ARGUMENTS should override the current checkout, but the snippet uses any non-empty $ARGUMENTS as the repo. That will break if the user passes flags like dry-run / no-pr-filter or any other non-repo argument.

The target repo defaults to the current checkout. Only when `$ARGUMENTS` names a
repo (`owner/name`) does that win:

```bash
REPO="${ARGUMENTS:-$(gh repo view --json nameWithOwner --jq .nameWithOwner)}"

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (5)

skills/dependabot-stack/SKILL.md:177

• This checkout currently uses $ORIGINAL_BRANCH, which can be empty (detached HEAD) and will fail. Use the $ORIGINAL_REF computed in Step 0 so the skill reliably returns the user to their previous state.

Then switch back to whatever branch the user was on before this skill ran:

```bash
git checkout "$ORIGINAL_BRANCH"

**skills/dependabot-stack/SKILL.md:5**
* AGENTS.md states each skill should include `metadata.triggers` in its YAML frontmatter for reliable skill activation, but this skill currently has no `metadata` block at all. Add a `metadata.triggers` entry (and keep allowed-tools) so agents can discover the skill from common Dependabot/gh-stack phrasing.

---

name: dependabot-stack
description: Group all open Dependabot PRs on a repository into a single ordered stack using gh-stack. Run weekly, after Dependabot's batch of grouped-update PRs lands. Use when asked to stack, organize, or clean up Dependabot PRs.
allowed-tools: Bash(gh pr list:) Bash(gh pr diff:) Bash(gh repo view:) Bash(gh extension list:) Bash(gh extension install github/gh-stack:) Bash(gh stack:) Bash(git worktree:) Bash(git fetch:) Bash(git checkout:) Bash(git rebase:) Bash(git add:) Bash(git push:) Bash(bundle lock:) Bash(yarn install:) Bash(git rev-parse:) Bash(git branch:) Bash(mktemp:*)

**skills/dependabot-stack/SKILL.md:105**
* `git worktree add "$WT" "$DEFAULT_BRANCH"` fails if the default branch doesn’t exist locally (common when someone hasn’t checked out `main`/`master` yet). Fetch the default branch ref and create the worktree from `origin/$DEFAULT_BRANCH` so this works from any branch.

WT=$(mktemp -d)/stack-wt
git worktree add "$WT" "$DEFAULT_BRANCH"
cd "$WT"

**skills/dependabot-stack/SKILL.md:134**
* `yarn install --mode=update-lockfile` is a Yarn Berry (v2+) flag; on Yarn Classic (v1) it will error, and the note about not installing `node_modules` would be incorrect. Clarify the Yarn version expectation and provide a fallback for Yarn Classic repos.

--mode=update-lockfile rewrites yarn.lock without installing node_modules,
which the scratch worktree does not need.

**skills/dependabot-stack/SKILL.md:26**
* `git branch --show-current` returns an empty string when starting from a detached HEAD, which would later produce `git checkout ""` and fail. Capture a usable ref up front (branch name when present, otherwise the current commit) and use it for the final checkout.

This issue also appears on line 173 of the same file.

REPO="${ARGUMENTS:-$(gh repo view --json nameWithOwner --jq .nameWithOwner)}"
DEFAULT_BRANCH=$(gh repo view "$REPO" --json defaultBranchRef --jq .defaultBranchRef.name)
ROOT=$(git rev-parse --show-toplevel)
ORIGINAL_BRANCH=$(git branch --show-current)

</details>