commit

Format git commits to Conventional Commits style with type, scope, and subject.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/bytes032/agentkit --skill commit-bytes032
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: commit
Source: https://github.com/bytes032/agentkit/tree/main/skills/commit
Command: npx skills add https://github.com/bytes032/agentkit --skill commit-bytes032

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill guides you to create concise, conventional git commits that improve changelog quality and project hygiene by enforcing a standardized format.

Core Features & Use Cases

  • Enforces the Conventional Commits format: <type>(<scope>): <summary>, with type required and scope optional.
  • Validates subject length (≤ 72 characters), absence of a trailing period, and avoidance of signing-offs or breaking-change markers.
  • Step-by-step guidance for selecting the right scope, assembling a clear summary, and staging only the intended changes.

Quick Start

Summarize the changes and I will generate a Conventional Commits style subject and perform the commit.

Frequently Asked Questions about commit

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

FAQPage Schema
How do I format conventional commits with a scope and subject?

Conventional commits use the <type>(<scope>): <subject> pattern, where type is required and scope is optional. The subject must be under 72 characters, contain no trailing period, and avoid signing-offs or breaking-change markers.

What is the character limit for a conventional commit subject?

A conventional commit subject must be 72 characters or less. It must also omit trailing periods and avoid breaking-change markers or signing-offs to ensure clean changelog generation.

How do I write a git commit message for a feature or fix?

To write a git commit message for a feature or fix, assemble a clear summary under 72 characters, select the appropriate type like feat or fix, add an optional scope, and stage only the intended changes before committing.

Do I need to stage changes before generating a conventional commit?

Yes, you need to stage the intended changes before committing. The workflow requires staging specific files first, then summarizing the changes to generate a properly formatted conventional commit subject.

Why avoid trailing periods and signing-offs in conventional commits?

Avoiding trailing periods and signing-offs in conventional commits enforces a standardized format that improves project hygiene and changelog quality across typical development workflows involving features, fixes, docs, and chores.