playbooks

home / skills / github / awesome-copilot / git-commit

git-commit skill

/skills/git-commit

This skill helps you create conventional git commits by analyzing diffs, staging changes intelligently, and generating accurate messages.

npx playbooks add skill github/awesome-copilot --skill git-commit

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

Files (1)
SKILL.md
3.1 KB
---
name: git-commit
description: 'Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping'
license: MIT
allowed-tools: Bash
---

# Git Commit with Conventional Commits

## Overview

Create standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.

## Conventional Commit Format

```
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
```

## Commit Types

| Type       | Purpose                        |
| ---------- | ------------------------------ |
| `feat`     | New feature                    |
| `fix`      | Bug fix                        |
| `docs`     | Documentation only             |
| `style`    | Formatting/style (no logic)    |
| `refactor` | Code refactor (no feature/fix) |
| `perf`     | Performance improvement        |
| `test`     | Add/update tests               |
| `build`    | Build system/dependencies      |
| `ci`       | CI/config changes              |
| `chore`    | Maintenance/misc               |
| `revert`   | Revert commit                  |

## Breaking Changes

```
# Exclamation mark after type/scope
feat!: remove deprecated endpoint

# BREAKING CHANGE footer
feat: allow config to extend other configs

BREAKING CHANGE: `extends` key behavior changed
```

## Workflow

### 1. Analyze Diff

```bash
# If files are staged, use staged diff
git diff --staged

# If nothing staged, use working tree diff
git diff

# Also check status
git status --porcelain
```

### 2. Stage Files (if needed)

If nothing is staged or you want to group changes differently:

```bash
# Stage specific files
git add path/to/file1 path/to/file2

# Stage by pattern
git add *.test.*
git add src/components/*

# Interactive staging
git add -p
```

**Never commit secrets** (.env, credentials.json, private keys).

### 3. Generate Commit Message

Analyze the diff to determine:

- **Type**: What kind of change is this?
- **Scope**: What area/module is affected?
- **Description**: One-line summary of what changed (present tense, imperative mood, <72 chars)

### 4. Execute Commit

```bash
# Single line
git commit -m "<type>[scope]: <description>"

# Multi-line with body/footer
git commit -m "$(cat <<'EOF'
<type>[scope]: <description>

<optional body>

<optional footer>
EOF
)"
```

## Best Practices

- One logical change per commit
- Present tense: "add" not "added"
- Imperative mood: "fix bug" not "fixes bug"
- Reference issues: `Closes #123`, `Refs #456`
- Keep description under 72 characters

## Git Safety Protocol

- NEVER update git config
- NEVER run destructive commands (--force, hard reset) without explicit request
- NEVER skip hooks (--no-verify) unless user asks
- NEVER force push to main/master
- If commit fails due to hooks, fix and create NEW commit (don't amend)

Overview

This skill executes git commits using Conventional Commits with intelligent analysis and staging. It inspects diffs to auto-detect type and scope, generates a concise conventional commit message, and can interactively stage files or accept overrides. It enforces safe Git practices to avoid secrets and destructive operations.

How this skill works

The skill analyzes the current repository state (staged diff first, then working tree diff) and the git status to determine changed files and logical groupings. It infers commit type, scope, and a present-tense, imperative description from the diff, suggests a message, and can auto-stage files or prompt for interactive staging and overrides. Finally it runs git commit with the generated or user-edited message, respecting hooks and safety rules.

When to use it

  • When you want a conventional commit created from your workspace changes
  • When you type or mention "/commit" or ask to commit changes
  • When you need intelligent staging to group related files into one commit
  • When you want an autogenerated commit message based on the actual diff
  • When you want interactive control over type, scope, or description

Best practices

  • Keep one logical change per commit and stage accordingly
  • Use present-tense, imperative descriptions under 72 characters
  • Verify no secrets (.env, keys, credentials) are included before committing
  • Prefer adding references (Closes #123) or BREAKING CHANGE footers when needed
  • Do not bypass hooks (--no-verify) or run destructive commands unless explicitly requested

Example use cases

  • Auto-generate a feat: message after adding a new API endpoint and stage the related files together
  • Create a fix: commit from a small bug fix found in a single file, with concise scope inferred
  • Interactively stage tests and source changes and customize the commit scope and description
  • Group multiple styling and refactor changes into separate commits by intelligent file selection
  • Add a breaking change footer when a public API was modified and include the BREAKING CHANGE note

FAQ

Can I override the generated type, scope, or description?

Yes. The skill supports interactive overrides so you can change type, scope, and description before committing.

What diff does the skill analyze?

It prefers the staged diff (git diff --staged). If nothing is staged it analyzes the working tree diff (git diff) and checks git status to guide staging suggestions.

Will it commit secrets or run destructive commands?

No. It warns about obvious secrets and follows a safety protocol: it will not run destructive commands, update global git config, or force-push without explicit instruction.