conventional-commits

Files (1)

• SKILL.md

SKILL.md (first lines)

# Conventional Commits

## Overview

Conventional Commits is a specification for adding human and machine-readable meaning to commit messages. It provides a standardized format that enables automated tools to generate changelogs, determine semantic version bumps, and communicate the nature of changes clearly.

## When to Use

Use this skill when:

- Creating git commits for any codebase
- Writing commit messages that need to follow a standard format
- The user mentions conventional commits, semantic versioning, or automated changelogs
- Working on projects that use automated release pipelines
- Contributing to open-source projects that require conventional commit format

## Commit Message Format

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

[optional body]

[optional footer(s)]
```

### Required Elements

1. **Type**: A noun indicating the category of change
2. **Description**: A short summary of the change

### Optional Elements

3. **Scope**: Context for the change (in parentheses)
4. **Body**: Detailed explanation (separated by blank line)
5. **Footer(s)**: Metadata like breaking changes or issue references

## Commit Types

### Core Types (Semantic Versioning Impact)

| Type                                            | Meaning         | Version Bump |
| ----------------------------------------------- | --------------- | ------------ |
| `feat`                                          | New feature     | MINOR        |
| `fix`                                           | Bug fix         | PATCH        |
| `feat!` or `feat` with `BREAKING CHANGE` footer | Breaking change | MAJOR        |

### Additional Types (No Version Impact)

| Type       | Meaning                                                 |
| ---------- | ------------------------------------------------------- |
| `build`    | Build system or external dependencies                   |
| `chore`    | Maintenance tasks, no production code changes           |
| `ci`       | CI/CD configuration and scripts                         |
| `docs`     | Documentation only changes                              |
| `style`    | Code style (formatting, semicolons, etc.)               |
| `refactor` | Code refactoring without fixing bugs or adding features |
| `perf`     | Performance improvements                                |
| `test`     | Adding or modifying tests                               |
| `revert`   | Reverting a previous commit                             |

## Examples

### Simple Commit

```
docs: update README with installation instructions
```

### Commit with Scope

```
feat(api): add user authentication endpoint
```

### Commit with Body

```
fix: prevent race condition in request handler

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.
```

### Breaking Change (Footer Style)

```
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```

### Breaking Change (Shorthand Style)

```
feat!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.
```

### Multiple Footers

```
fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Reviewed-by: Z
Refs: #123
```

## Writing Good Descriptions

### Do's

From ntk148v/skills, MIT.

More from ntk148v/skills