restructure-commits

Reorganizes feature branch commits into component-based commits for HyperShift pull requests.

538|560|Updated Jan 18, 2021
One-click install
npx skills add https://github.com/openshift/hypershift --skill restructure-commits
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: restructure-commits
Source: https://github.com/openshift/hypershift/tree/main/.claude/skills/restructure-commits
Command: npx skills add https://github.com/openshift/hypershift --skill restructure-commits

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Feature branches in the HyperShift repository often accumulate many small or WIP commits that make PR review difficult. This Skill restructures the branch history into clean, logical commits grouped by architectural component (API, Vendor, CLI, hypershift-operator, control-plane-operator, E2E, Docs) so reviewers can evaluate changes by subsystem.

Core Features & Use Cases

  • Component-Based Commit Grouping: Maps changed files to seven ordered component categories using explicit directory patterns, with documented edge-case rules for ambiguous paths like support/, shared-ingress/, and generated CRD manifests.
  • Safe History Rewriting: Uses git merge-base detection and soft reset to preserve all changes while rebuilding the commit stack, ending with a verified clean working tree.
  • Conventional Commit Messages: Provides per-component type/scope conventions (e.g., feat(api):, chore(api):, test(e2e):) with subject and body writing guidance compliant with gitlint line-length rules.
  • Use Case: Before opening a HyperShift PR, a developer with 15 messy commits runs this Skill to produce 5 well-scoped commits (API, Vendor, HO, CPO, E2E) ready for reviewer approval.

Quick Start

Ask the AI to restructure the commits on my current HyperShift branch into logical component-based commits for PR review.

Frequently Asked Questions about restructure-commits

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

FAQPage Schema
How do I restructure commits on a feature branch before a PR?

Find the merge base with the base branch, run git reset --soft to that point, unstage everything, then stage and commit files grouped by component in order: API, Vendor, CLI, hypershift-operator, control-plane-operator, E2E, Docs. Verify a clean tree and force push with --force-with-lease after user confirmation.

How to organize Git commits by component or directory?

Map each changed file to a component using directory patterns, then stage matching files per component and commit separately. In HyperShift, api/ goes to the API commit, vendor/ and generated CRDs to Vendor, and test/ plus api test files to E2E.

What commit message format does HyperShift use?

HyperShift uses conventional commits with component scopes: feat(api):, chore(api): for vendor regeneration, feat(cli):, feat(hypershift-operator):, feat(control-plane-operator):, test(e2e):, and docs: with no scope. Body lines must stay under 140 characters per gitlint.

Does git reset --soft lose my changes when restructuring commits?

No, git reset --soft to the merge base keeps all changes staged in the working tree. Running git reset HEAD afterwards unstages them so files can be re-staged per component, with no data loss.

Where do ambiguous files like support/ or hack/ go when splitting commits?

support/, shared-ingress/, and karpenter-operator/ belong to the hypershift-operator commit, while control plane sidecars like etcd-backup/ and ignition-server/ belong to control-plane-operator. Build tooling like hack/ and contrib/ goes into the most relevant commit, defaulting to hypershift-operator when ambiguous.