Git

Commit Message Generator

Analyzes staged git changes and generates a conventional-commit-style message with scope, type, and body.

SKILL.md

SKILL.md
---
description: Generate a conventional commit message from staged changes
allowed-tools: Bash(git diff --cached), Bash(git status)
---

# Commit Message Generator

Analyze the currently staged git changes and produce a well-formed commit message following the Conventional Commits specification.

## Steps

1. Run `git diff --cached --stat` to get an overview of changed files.
2. Run `git diff --cached` to read the full diff of staged changes.
3. Determine the commit **type** from this list:
   - `feat` – a new feature
   - `fix` – a bug fix
   - `refactor` – code restructuring without behavior change
   - `docs` – documentation only
   - `test` – adding or updating tests
   - `chore` – tooling, deps, or config changes
   - `style` – formatting, whitespace, semicolons
   - `perf` – performance improvement
4. Infer a **scope** from the primary directory or module affected (e.g. `auth`, `api`, `ui`). Omit scope if changes span many unrelated areas.
5. Write a concise **subject line** (≤72 chars, imperative mood, no period).
6. If the change is non-trivial, add a **body** paragraph explaining *why* the change was made.
7. If there are breaking changes, add a `BREAKING CHANGE:` footer.

## Output format

Return ONLY the commit message — no explanation or surrounding text. Example:

```
feat(auth): add OAuth2 PKCE flow for mobile clients

Implement the Authorization Code with PKCE extension so mobile apps can
authenticate without a client secret. This replaces the implicit grant
flow which is deprecated in OAuth 2.1.
```

## Rules

- Never include file diffs in the commit message itself.
- Keep the subject line in imperative mood ("add", not "added" or "adds").
- Wrap the body at 80 characters.
- If only a single trivial change is staged, a subject line alone is sufficient.

How It Works

This skill demonstrates how to give the agent access to specific shell commands through the `allowed-tools` frontmatter. By restricting it to only `git diff --cached` and `git status`, the skill ensures the agent can read staged changes without being able to modify files or run arbitrary commands.

The step-by-step instructions guide the agent through a decision tree — first understanding what changed, then classifying the type and scope, and finally composing the message. This structured approach produces consistent output even across very different kinds of changes.

The output format section is critical: by showing an example and stating "return ONLY the commit message", the skill prevents the agent from wrapping the result in conversational prose. This makes the output directly usable with `git commit -m`.