reordering-release-bump

Relocates a Git version bump commit to the tip of the default branch.

125|42|Updated May 19, 2025
One-click install
npx skills add https://github.com/SocketDev/socket-mcp --skill reordering-release-bump
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reordering-release-bump
Source: https://github.com/SocketDev/socket-mcp/tree/main/.claude/skills/fleet/reordering-release-bump
Command: npx skills add https://github.com/SocketDev/socket-mcp --skill reordering-release-bump

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The skill relocates an existing release bump commit to the tip of the default branch when subsequent work lands on top of it, then retags vX.Y.Z onto the moved commit and force-pushes — with a timestamped backup branch, tree-identical integrity verification, and the package.json+CHANGELOG-only bump check. Use when a release bump is no longer the latest commit and needs to be again.

Core Features & Use Cases

  • Move the bump commit to the tip and retag onto vX.Y.Z, preserving the exact tree content.
  • Create a timestamped backup branch for recovery and traceability.
  • Verify that only package.json and CHANGELOG were touched and ensure tree-identical integrity before pushing.
  • Use when a release bump is no longer the latest commit due to later work and the bump must be relocated.

Quick Start

Invoke the reordering-release-bump skill on your repository to relocate the bump commit to the tip and update the tag accordingly.

Frequently Asked Questions about reordering-release-bump

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I move a Git version bump commit to the tip of the default branch?

You can relocate the version bump commit to the tip using a multi-phase process that verifies package.json changes, creates a backup branch, reorders via a worktree, and updates refs with force-with-lease.

What is the safest way to retag a Git release after reordering commits?

Retagging safely requires creating a timestamped backup branch for recovery, verifying tree-identical integrity, and updating refs with force-with-lease to prevent overwriting unexpected remote changes.

Why is my release bump commit no longer the latest commit on the default branch?

This happens when subsequent work lands on top of the chore: bump version to X.Y.Z commit, meaning later commits have pushed the bump down the history and it must be relocated to the head.

Does this Git workflow verify that only package.json and CHANGELOG were touched?

Yes, the process verifies that only package.json and CHANGELOG were touched in the bump commit, ensuring tree-identical integrity before updating refs and pushing the changes.

Can I recover my branch if relocating a release bump goes wrong?

Yes, the process creates a timestamped backup branch before performing any reordering, providing a recovery point and traceability to restore the original state if needed.