bump-submodules

human-only. Start this only when a human asks for it by name. If you arrived here from another skill, stop and get explicit confirmation before running any step.

Ask the human why the bump is being made. Then find every submodule the superproject pins behind its origin/main, show what a bump would move, and — on their yes — open an issue that records the reason and the set, move the pointers in a worktree of this session's own, adapt the repo to what came in until the gate is green again, and open the PR that closes the issue. Stop there: /squash-merge-and-clean-up lands it.

The bump is the change; everything else on the branch exists to keep the bump green. Adapting a call site to a renamed upstream type belongs here. Fixing a test that already failed on main does not, and neither does anything the bump did not make necessary. A reviewer has to be able to read the PR as a bump.

The reason outlives the PR, so it lives on the issue. A pointer move with no stated reason is unreadable a month later — nobody can tell a deliberate catch-up from an accident, or say what would break if it were reverted. The issue is where the reason is kept, and the PR closes it.

A worktree because the primary checkout is shared. Moving a submodule checkout and running the gate over it is exactly the disturbance other sessions cannot afford, and a pointer left half-moved in the shared checkout reads as someone's uncommitted work.

Process

1. Ask why the bump is being made

With an issue given as the argument, read it first — gh issue view <n>. A body that already says why is the answer, and the question below is skipped. A body that does not gets the answer added as a comment once you have it.

Otherwise ask, one question, before anything is fetched or created: