What happens if there are no staged changes?

The skill prompts you to stage changes with git add before generating a commit message.

Can I override the auto-detected scope or type?

Yes. You can adjust the subject to include an explicit scope or select a different type if your changes warrant it; the format is type(scope): description with optional body.

Is Perf or Revert supported?

Yes. The skill supports the full set of Conventional Commit types: feat, fix, docs, refactor, perf, test, build, ci, chore, and revert.

git-commit

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

Files (1)

SKILL.md

3.3 KB

Git Commit Skill

This skill guides the creation of Git commit messages that follow the Conventional Commits format.

When to Use

Use this skill when:

Code changes are completed and ready to be committed
Need to create a commit message that adheres to project conventions

Commit Message Format

The commit message must follow this format:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Instructions

Check the staged files using git diff --staged --name-only. Ask user to stage changes if there are no staged files.
Determine the appropriate commit type based on the staged files.

type must be selected from the following options:

feat: New feature or change to existing functionality
fix: Bug fix
docs: Documentation-only changes (e.g., changes to *.md files)
refactor: Refactoring (code changes that neither fix a bug nor add a feature)
perf: Performance improvements
test: Adding or modifying tests (e.g., changes to *.spec.* or *.spec.*.snap files)
build: Changes affecting the build system or external dependencies
ci: Changes to CI configuration files (e.g., changes within .github/actions or .github/workflows)
chore: Other changes (e.g., changes to *.json, *.config.mjs, *.config.cjs, *.config.js, *.config.ts, .gitignore, .gitattributes, .prettierignore, .prettier)
revert: Reverting a previous commit

Determine the appropriate scope based on the staged files and the project structure.

scope should be determined based on the directory structure of the staged files. For example:

If staged files are in .claude/ or .mcp.json, use claude
If staged files are in .github/, use github
If staged files are in .vscode/, use vscode
If staged files are in apps/frontend/, use frontend
If staged files are in libs/frontend/feature-xxx, use frontend-feature-xxx
If staged files are in libs/utils/, use utils
If staged files are in the root directory, do not set a scope

Craft a comprehensive and descriptive commit message strictly following the Conventional Commits format.

Important NEVER include \n in the commit message. Always use actual newlines to separate the subject, body, and footer.

Example:

git commit -m "feat(utils): update xxx function

- Add xxx logic in xxx function
- Implement unit tests for xxx function

Co-Authored-By: Copilot <175728472+Copilot@users.noreply.github.com>"

Notes

Important Commit messages must be written in English.
If there are staged changes, determine the commit message based only on the staged changes.
Always include Co-Authored-By information. The commit message must clearly indicate that it was created with Copilot.

References

Commit message

Source

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

Overview

This skill enforces Conventional Commits formatting for Git messages. It automatically selects the type (feat, fix, docs, refactor, perf, test, build, ci, chore, revert) and determines the scope from the staged file paths and project layout, delivering a consistent, machine-friendly history.

How This Skill Works

It inspects staged changes with git diff --staged --name-only to determine the affected files. It maps each change to a Conventional Commits type, derives the scope from directory structure (for example apps/frontend -> frontend, libs/utils -> utils, or leaves no scope at root), and outputs a correctly formatted message that includes a Co-Authored-By footer indicating Copilot authorship.

When to Use It

When code changes are staged and ready to be committed
When you must adhere to project conventions via Conventional Commits
When you want automatic scope derived from file paths like apps/frontend or libs/utils
When updating or adding documentation files (*.md) or contributing changes to docs
When you want every commit to clearly credit Copilot via Co-Authored-By

Quick Start

Step 1: git diff --staged --name-only to confirm staged files
Step 2: Let the skill determine the Conventional Commit type and scope from the file paths
Step 3: Create the commit with the generated message, including the Co-Authored-By footer, e.g. git commit -m "feat(scope): description" -m "Body" -m "Co-Authored-By: Copilot <175728472+Copilot@users.noreply.github.com>"

Best Practices

Stage only the changes that belong in the current commit before running the tool
Select the correct type from feat, fix, docs, refactor, perf, test, build, ci, chore, or revert
Use a concise subject in the form type(scope): description; include scope when meaningful
Provide a body only if necessary to explain the rationale behind the changes
Always include a Co-Authored-By footer to credit Copilot

Example Use Cases

feat(frontend): add user login modal\n\nCo-Authored-By: Copilot <175728472+Copilot@users.noreply.github.com>
fix(core): resolve race condition in session store\n\nCo-Authored-By: Copilot <175728472+Copilot@users.noreply.github.com>
docs: update README contribution guidelines\n\nCo-Authored-By: Copilot <175728472+Copilot@users.noreply.github.com>
refactor(utils): simplify debounce utility\n\nCo-Authored-By: Copilot <175728472+Copilot@users.noreply.github.com>
chore(ci): bump workflow Node version to 20\n\nCo-Authored-By: Copilot <175728472+Copilot@users.noreply.github.com>

Frequently Asked Questions

Add this skill to your agents