home / skills / toilahuongg / shopify-agents-kit / git-cm

git-cm skill

safe

/.claude/skills/git-cm

This skill helps you create conventional git commits by staging changes and composing clear messages.

npx playbooks add skill toilahuongg/shopify-agents-kit --skill git-cm

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

863 B

---
name: git-cm
description: Commit changes to git with a descriptive conventional commit message. Use when ready to commit staged or unstaged changes.
argument-hint: "[optional commit message]"
disable-model-invocation: true
allowed-tools: Bash(git:*)
---

# Git Commit

Commit changes with a conventional commit message.

1. Check the current git status to understand what has changed.
   - Command: `git status`

2. View the diff if necessary to understand the changes better.
   - Command: `git diff --staged` or `git diff`

3. Add all changes to the staging area (unless specific files are requested).
   - Command: `git add .`

4. Commit the changes with a descriptive and conventional commit message.
   - Command: `git commit -m "<type>: <subject>"`
   - Ensure the message follows conventional commit standards (e.g., feat, fix, chore, docs, refactor).

Overview

This skill helps you create and apply Git commits using descriptive Conventional Commit messages. It guides you through checking status, reviewing diffs, staging changes, and creating a well-formed commit that follows common commit types like feat, fix, docs, chore, and refactor. Use it when you’re ready to record a logical change in your repository history.

How this skill works

The skill inspects the current repository state by suggesting a git status check and optional diffs to understand what changed. It recommends staging either all changes or specific files, then formats a concise Conventional Commit message and runs the git commit command. The focus is on producing clear, standardized commit messages that improve history readability and automation compatibility.

When to use it

After completing a small feature, bugfix, or documentation update and you’re ready to record the change
When you want consistent commit messages for changelogs or CI hooks
Before pushing to a shared branch to ensure the commit follows team conventions
When you have staged or unstaged changes and need help forming a proper Conventional Commit

Best practices

Run git status first to see modified, added, or deleted files
Use git diff or git diff --staged to confirm exactly what will be committed
Stage only the logical set of changes that belong together (git add <file> or git add .)
Keep the commit subject short and imperative: <type>: <short description>
Choose the correct type (feat, fix, docs, chore, refactor) to reflect intent

Example use cases

Committing a small new feature: git add . && git commit -m "feat: add user profile avatar upload"
Logging a bug fix: git add path/to/file && git commit -m "fix: correct null pointer in auth flow"
Updating documentation: git add docs/ && git commit -m "docs: update API usage examples"
Minor maintenance or config changes: git add . && git commit -m "chore: update CI Node version"

FAQ

What if I only want to commit some files?

Stage the specific files with git add <file1> <file2> and then run the commit command with the Conventional Commit message.

Which types should I use?

Common types are feat, fix, docs, chore, refactor. Pick the one that best describes the change’s purpose.

How long should the subject be?

Keep it short and imperative, ideally under 50 characters, with additional details in the body if needed.