Git Commit Format

Enforce Conventional Commit formatting for HyperShift Git commits.

1|Updated Nov 18, 2025
One-click install
npx skills add https://github.com/hypershift-community/azure-dev-preview --skill git-commit-format-hypershift-community
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Git Commit Format
Source: https://github.com/hypershift-community/azure-dev-preview/tree/main/.claude/skills/git-commit-format
Command: npx skills add https://github.com/hypershift-community/azure-dev-preview --skill git-commit-format-hypershift-community

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Inconsistent or poorly formatted Git commit messages hinder project history analysis, automated changelog generation, and team collaboration. This Skill standardizes your commit messages according to HyperShift's conventional commit rules, saving you time and ensuring a clean, searchable, and automated Git history.

Core Features & Use Cases

  • Conventional Commit Guidance: Provides a clear structure for commit messages, including types, scopes, descriptions, and optional body/footers.
  • Breaking Change Handling: Guides on how to properly mark breaking changes using ! or BREAKING CHANGE footers for clear communication.
  • Mandatory Footer Enforcement: Ensures critical footers like Signed-off-by and Commit-Message-Assisted-by are always included, streamlining compliance and attribution.
  • Use Case: Before pushing your changes, use this Skill to generate a perfectly formatted commit message for your new feature, ensuring it adheres to all HyperShift standards and includes the necessary sign-off, making your contribution immediately ready for review.

Quick Start

Generate a Git commit message for the new feature that adds workload identity support for Azure, ensuring it follows the HyperShift conventional format and includes the required footers.

Frequently Asked Questions about Git Commit Format

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

FAQPage Schema
How do I format Git commit messages using conventional commits?

Conventional commits use the format <type>(<scope>): <description> with optional body and footers. Types include feature, fix, docs, style, refactor, test, chore, build, ci, perf, and revert. Title lines must stay under 120 characters, body lines under 140, and commits require Signed-off-by and Commit-Message-Assisted-by footers to pass validation.

What's the correct way to mark breaking changes in Git commits?

Mark breaking changes by adding an exclamation mark after the type and scope—for example, `feat(api)!: new endpoint`—or include a `BREAKING CHANGE` footer in the commit body. Both approaches signal that the change is not backward compatible and help teams track significant alterations in project history.

Why enforce consistent commit message formatting in version control?

Standardized commit messages enable automated changelog generation, improve project history searchability, and streamline team collaboration. Consistent formatting with types and scopes makes it easier to parse commits programmatically and understand the nature of changes at a glance.

Do I need to include footers in every Git commit?

Yes, conventional commit validation requires Signed-off-by and Commit-Message-Assisted-by footers in all commits to pass lint checks. These footers ensure proper attribution and compliance tracking, making contributions immediately ready for review in the HyperShift workflow.

How do I handle commit scopes and optional body text in conventional commits?

Scopes are optional and specify the area affected—for example, `fix(workload-identity)`. The optional body provides detailed context after a blank line and can include the BREAKING CHANGE footer or additional explanation. Both body and scope help reviewers understand the full scope and rationale of changes.