How long should the subject be?

Keep it to 72 characters or fewer for readability.

Should I include an issue key in every commit?

Optional; include an issue key if available or required by your workflow.

Should the subject end with a period?

No. Use an imperative, concise form without a trailing period.

git-commit

Scanned

npx machina-cli add skill gologo13/agent-skills/git-commit --openclaw

Files (1)

SKILL.md

1.6 KB

Git Create Commit

Overview

Create a short, focused commit message and commit staged changes.

Steps

Review changes
- Check the diff: git diff --cached (if changes are staged) or git diff (if unstaged)
- Understand what changed and why
Ask for issue key (optional)
- Check the branch name for an issue key (Linear, Jira, GitHub issue, etc.)
- If an issue key (e.g., POW-123, PROJ-456, #123) is not already available in the chat or commit context, optionally ask the user if they want to include one
- This is optional - commits can be made without an issue key
Stage changes (if not already staged)
- git add -A
Create short commit message
- Base the message on the actual changes in the diff
- Example: git commit -m "fix(auth): handle expired token refresh"
- Example with issue key: git commit -m "PROJ-123: fix(auth): handle expired token refresh"

Template

git commit -m "<type>(<scope>): <short summary>"
With issue key: git commit -m "<issue-key>: <type>(<scope>): <short summary>"

Rules

Length: <= 72 characters
Imperative mood: Use "fix", "add", "update" (not "fixed", "added", "updated")
Capitalize: First letter of summary should be capitalized
No period: Don't end the subject line with a period
Describe why: Not just what - "fix stuff" is meaningless

Source

git clone https://github.com/gologo13/agent-skills/blob/main/skills/git-commit/SKILL.mdView on GitHub

Overview

Create a short, focused commit message and commit staged changes. It guides you to base messages on the actual changes, use an imperative mood, and follow a consistent template. Optional issue keys help link commits to work items for better traceability.

How This Skill Works

It reviews the diff to understand what changed, then stages the changes with git add -A if needed. It then builds a short, template-based commit message like type(scope): short summary, optionally prefixed with an issue key.

When to Use It

When you have a single logical change with a clear scope.
After reviewing a patch or diff to confirm what changed and why.
When you want to link commits to an issue key (optional) for traceability.
Before opening a pull request to ensure a clean, readable history.
When enforcing a consistent commit message format across a project.

Quick Start

Step 1: Review changes with git diff --cached (or git diff) to see what changed
Step 2: Stage changes if needed: git add -A
Step 3: Create the commit using the template, e.g. git commit -m "fix(auth): Handle expired token refresh"

Best Practices

Keep the subject line length <= 72 characters.
Use imperative mood: fix, add, update (not fixed, added, updated).
Capitalize the first letter of the summary.
Do not end the subject line with a period.
Describe why the change was made, not just what changed.

Example Use Cases

Fix(auth): Handle expired token refresh
PROJ-123: Fix(auth): Handle expired token refresh
Add(ui): Implement dark mode toggle
Docs(readme): Update contributing guidelines
Refactor(api): Simplify token refresh flow

Frequently Asked Questions

Add this skill to your agents