# Contribution Guidelines

To ensure a consistent and readable git history, this project adheres to the [Conventional Commits](https://www.conventionalcommits.org/) specification.

## Commit Message Format

Each commit message consists of a **header**, a **body**, and a **footer**.

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

[optional body]

[optional footer]
```

### Type

The type must be one of the following:

*   **feat**: A new feature for the user.
*   **fix**: A bug fix for the user.
*   **docs**: Changes to the documentation.
*   **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.
*   **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation.
*   **build**: Changes that affect the build system or external dependencies.
*   **ci**: Changes to our CI configuration files and scripts.

### Description

The description is a short summary of the code changes. Use the imperative, present tense: "change" not "changed" nor "changes".

### Breaking Changes

A commit that has a footer beginning with `BREAKING CHANGE:` introduces a breaking API change. A BREAKING CHANGE can be part of any type of commit.

---

*This document provides a summary. For more details, please refer to the [official Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/).*