Team
72f16d26b8
- Add SKILL.md with workflow and guidelines for generating Conventional Commits messages - Add agent config (.kiro/agents/commit-message.json) with tool permissions and skill resource - Add evals (evals.json) with 3 test cases covering feat/fix/refactor scenarios - Add Conventional Commits 1.0.0 reference documentation - Add compiled skill bundle (commit-message.skill)
47 lines
3.8 KiB
Markdown
47 lines
3.8 KiB
Markdown
# Conventional Commits 1.0.0
|
||
|
||
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with [SemVer](http://semver.org), by describing the features, fixes, and breaking changes made in commit messages.
|
||
|
||
The commit message should be structured as follows:
|
||
|
||
```
|
||
<type>[optional scope]: <description>
|
||
|
||
[optional body]
|
||
|
||
[optional footer(s)]
|
||
```
|
||
|
||
## Types
|
||
|
||
- **feat**: A new feature
|
||
- **fix**: A bug fix
|
||
- **docs**: Documentation only changes
|
||
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
|
||
- **refactor**: A code change that neither fixes a bug nor adds a feature
|
||
- **perf**: A code change that improves performance
|
||
- **test**: Adding missing tests or correcting existing tests
|
||
- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
|
||
- **ci**: Changes to our CI configuration files and scripts (example scopes: GitHub Actions, Travis, Circle, BrowserStack, SauceLabs)
|
||
- **chore**: Other changes that don't modify src or test files
|
||
- **revert**: Reverts a previous commit
|
||
|
||
## Rules
|
||
|
||
1. Commits MUST be prefixed with a type (feat, fix, etc.), followed by an optional scope, and a REQUIRED terminal colon and space.
|
||
2. The type feat MUST be used when a commit adds a new feature to your application or library.
|
||
3. The type fix MUST be used when a commit represents a bug fix for your application.
|
||
4. An optional scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):`
|
||
5. A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., `fix: array parsing issue when multiple spaces were contained in string`.
|
||
6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
|
||
7. A commit body is free-form and MAY consist of any number of new-line separated paragraphs.
|
||
8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a `:<space>` or `<space>#` separator, followed by a string value (this is inspired by the git trailer convention).
|
||
9. A footer’s token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate the footer from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token.
|
||
10. A footer’s value MAY contain whitespace and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
|
||
11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
|
||
12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., `BREAKING CHANGE: environment variables now take precedence over config files`.
|
||
13. If included in the type/scope prefix, breaking changes MUST be indicated by a `!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
|
||
14. Types other than feat and fix MAY be used in your commit messages, e.g., `docs: updated ref docs`.
|
||
15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementers, with the exception of BREAKING CHANGE which MUST be uppercase.
|
||
16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.
|