What is the Conventional Commits format?

It uses ( ): with optional body and footer; types include feat, fix, docs, style, refactor, perf, test, build, ci, chore.

How do I indicate breaking changes?

Include a BREAKING CHANGE: description in the footer to explain the impact.

Should the body wrap at a specific width?

Yes, wrap body lines at 72 characters and explain what and why, not how.

git-commit

npx machina-cli add skill ThinkInAIXYZ/deepchat/git-commit --openclaw

Files (1)

SKILL.md

1.6 KB

Git Commit Message Skill

You are a git commit message expert. When this skill is activated, help users create well-structured commit messages.

Commit Message Format

Follow the Conventional Commits specification:

<type>(<scope>): <subject>

[optional body]

[optional footer(s)]

Types

feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that do not affect the meaning of the code
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing tests or correcting existing tests
build: Changes that affect the build system or external dependencies
ci: Changes to CI configuration files and scripts
chore: Other changes that don't modify src or test files

Guidelines

Subject Line
- Use imperative mood ("add" not "added")
- Don't capitalize first letter
- No period at the end
- Limit to 50 characters
Body
- Explain what and why, not how
- Wrap at 72 characters
- Separate from subject with a blank line
Footer
- Reference issues: Fixes #123
- Breaking changes: BREAKING CHANGE: description

Workflow

Run git diff --staged or git status to see changes
Analyze the changes to understand what was modified
Generate an appropriate commit message
Optionally run git commit -m "message" if user confirms

Source

git clone https://github.com/ThinkInAIXYZ/deepchat/blob/dev/resources/skills/git-commit/SKILL.mdView on GitHub

Overview

This skill helps you craft well-structured commit messages that follow the Conventional Commits format. It enforces type, scope, subject, and optional body and footer sections to maintain a clean, navigable project history.

How This Skill Works

When activated, the skill guides you to produce messages in the form <type>(<scope>): <subject>, with optional body and footer. It references the standard types (feat, fix, docs, style, refactor, perf, test, build, ci, chore) and enforces subject rules (imperative mood, lowercase, no trailing period, max 50 chars) and body wrap at 72 characters. It analyzes changes, suggests a suitable structure, and helps you add a BREAKING CHANGE footer when needed.

When to Use It

when adding a new feature (feat) to a module
when fixing a bug (fix) with a clear scope
when updating documentation (docs) or comments
when performing a non-breaking refactor (refactor)
when changes introduce breaking changes or CI/build updates (BREAKING CHANGE)

Quick Start

Step 1: Review changes staged for commit with git diff --staged or git status
Step 2: Create a conventional commit message: <type>(<scope>): <subject>, with an optional body and footer
Step 3: Confirm and run git commit -m "<your message>" when ready

Best Practices

Use imperative mood and lowercase subject; avoid ending with a period and limit subject to 50 characters
Format as type(scope): subject, then add an optional body and/or footer; wrap body at 72 characters
Choose a precise scope and avoid vague topics; keep commits focused on a single change
Place breaking changes in the footer with BREAKING CHANGE: description
Commit one logical change per commit to preserve a clean history

Example Use Cases

feat(auth): add oauth login flow
fix(payment): handle null cart gracefully
docs(readme): update installation steps
style(ui): format spacing for buttons
refactor(core): simplify state management

Frequently Asked Questions

Add this skill to your agents