playbooks

home / skills / nweii / agent-stuff / commit

commit skill

/skills/commit

This skill helps you craft conventional commit messages automatically, ensuring clear, well-formatted commits that improve traceability.

npx playbooks add skill nweii/agent-stuff --skill commit

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

Files (2)
SKILL.md
1.7 KB
---
name: commit
description: "Create well-formatted commits with conventional commit messages. Use when user asks to commit, wants to commit changes, or needs help with commit messages."
metadata:
  author: nweii
  version: "1.0.1"
---

# Commit

Create well-formatted git commits following conventional commit conventions.

## Convention

Follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification:

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

[optional body]

[optional footer(s)]
```

### Types

- `feat`: New feature
- `fix`: Bug fix
- `docs`: Documentation only
- `style`: Formatting, missing semi-colons, etc. (no code change)
- `refactor`: Code change that neither fixes a bug nor adds a feature
- `perf`: Performance improvement
- `test`: Adding missing tests
- `chore`: Maintenance tasks (build process, dependencies, etc.)

### Guidelines

- **Subject line**: Max 50 characters, imperative mood ("add" not "added")
- **Body**: Wrap at 72 characters, explain *what* and *why* (not *how*)
- **Scope**: Optional, indicates section of codebase (e.g., `feat(auth):`)
- **Breaking changes**: Add exclamation mark after type/scope (e.g., `feat!:`) and explain in footer

## Process

1. Review staged changes (`git diff --staged`)
2. Determine appropriate type and scope
3. Write concise, descriptive subject line
4. Add body if the change needs explanation
5. Execute the commit

## Examples

```
feat(auth): add OAuth2 login support

Implements Google and GitHub OAuth providers.
Closes #123
```

```
fix: resolve race condition in data fetcher

The previous implementation could return stale data
when multiple requests were in flight.
```

```
chore: update dependencies to latest versions
```

Overview

This skill creates well-formatted git commits following the Conventional Commits specification. It helps pick the correct commit type and scope, craft a concise subject line, and produce an optional body and footer when needed. Use it to standardize commit history and make changelogs, CI, and releases more reliable.

How this skill works

The skill inspects staged changes and recommends a commit type (feat, fix, docs, etc.) and an optional scope based on files changed. It generates a 50-character-or-less imperative subject, an optional wrapped body at 72 characters explaining what and why, and any footers for issues or breaking changes. Finally, it outputs a ready-to-run git commit command.

When to use it

  • When you want to commit staged changes with a conventional commit message
  • When you need help choosing the correct commit type and scope
  • When preparing a changelog, release, or automated semantic release
  • When enforcing team or project commit message standards
  • When adding an explanatory body or declaring a breaking change

Best practices

  • Keep the subject line under 50 characters and use imperative mood
  • Wrap body lines at 72 characters and explain what and why, not how
  • Include a scope only when it clarifies the affected area (e.g., auth, api)
  • Use footers to reference issue IDs (e.g., Closes #123) or breaking changes
  • Use the proper type (feat, fix, docs, chore, refactor, perf, test, style)

Example use cases

  • Committing a new login feature: feat(auth): add OAuth2 login support
  • Fixing a bug that causes stale data: fix: resolve race condition in data fetcher
  • Updating test coverage or adding tests: test(api): add pagination tests
  • Bumping dependencies or build scripts: chore: update dependencies to latest versions
  • Announcing a breaking API change with a footer explaining migration steps

FAQ

Do I always need a scope?

No. Use a scope only when it clarifies which part of the codebase is affected.

How do I indicate a breaking change?

Add an exclamation after the type or type(scope) like feat!: and explain the breaking change in the footer.

What should the commit body contain?

Briefly explain what changed and why. Avoid implementation details; keep lines wrapped at 72 characters.