> For the complete documentation index, see [llms.txt](https://docs.bonsol.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bonsol.org/contributing/contributor-guidelines.md).

# Contributor guidelines

Thank you for your interest in contributing to Bonsol! This guide will help you understand our contribution workflow and requirements.

## Local Setup

Refer to [Setup a local environment](/developers/setup-a-local-environment.md)to get started with a local environment for contributing. This will allow you to build, run and make changes to Bonsol from source.

## Pull Requests

When submitting pull requests to Bonsol, please follow these guidelines:

1. **Check Existing Issues**: Before creating a new issue or PR, verify if an existing issue already addresses your concern.
2. **Issue References**: All PRs should reference a corresponding GitHub issue using closing keywords (example: `Closes #123`).
3. **Clear Descriptions**: Include a clear, concise description of your changes in the PR.
4. **Testing**: Add relevant tests that demonstrate your changes work as intended.
5. **Code Quality**:
   * Run `nix flake check` locally to verify your changes pass our quality checks
   * Format Rust code with `cargo +nightly fmt`
   * Format TOML files with `taplo fmt`
   * Check for lints with `cargo clippy`
6. **Dependencies**: Exercise caution when adding new dependencies to ensure they're well-maintained and secure.

## Commit Messages <a href="#commit-message-guidelines" id="commit-message-guidelines"></a>

We use **commitlint** to ensure that all commit messages follow a consistent style based on the [Conventional Commits](https://www.conventionalcommits.org) specification. This makes it easier to understand the history of the project and generate changelogs automatically.

#### Commit Message Format <a href="#commit-message-format" id="commit-message-format"></a>

Each commit message must be structured as follows:

**Type**

The type must be one of the following:

* **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 or correcting existing tests
* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, npm)
* **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
* **chore**: Other changes that don't modify src or test files
* **revert**: Reverts a previous commit

**Scope**

The scope is optional and provides additional context about what the commit affects (e.g., `api`, `cli`, `frontend`, etc.).

**Description**

The description is a short, imperative summary of the change. It should start with a verb and be written in the present tense (e.g., "add feature," "fix bug").

**Body (optional)**

The body of the commit message provides additional details about the change. Use this when the change is not trivial and requires more explanation.

**Footer (optional)**

The footer should contain any relevant information about breaking changes or issues being closed:

* Breaking changes should start with the word `BREAKING CHANGE:`, followed by an explanation of what changed and why.
* Issues should be referenced using the `Closes` keyword, like so: `Closes #123`.

#### Example Commit Messages <a href="#example-commit-messages" id="example-commit-messages"></a>

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

```
fix(auth): correct token expiration logic
```

```
docs: update README with new installation steps
```

```
chore: update dependencies
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bonsol.org/contributing/contributor-guidelines.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.