.cursorrules

# shadcn instructions

Use the latest version of Shadcn to install new components, like this command to add a button component:

```bash
pnpx shadcn@latest add button
```

# Conventional Commits Specification (v1.0.0)

When creating commit messages, ALWAYS follow the Conventional Commits specification (https://www.conventionalcommits.org/en/v1.0.0/).

## Commit Message Structure

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

[optional body]

[optional footer(s)]
```

## Required Elements

1. **Type**: MUST be prefixed with a type, followed by a colon and space
   - `feat`: A new feature (correlates with MINOR in Semantic Versioning)
   - `fix`: A bug fix (correlates with PATCH in Semantic Versioning)
   - Other types allowed: `build`, `chore`, `ci`, `docs`, `style`, `refactor`, `perf`, `test`, etc.

2. **Description**: MUST immediately follow the colon and space. Short summary of code changes.

## Optional Elements

1. **Scope**: MAY be provided after type, enclosed in parentheses
   - Example: `feat(parser): add ability to parse arrays`
   - Example: `fix(api): resolve authentication error`

2. **Body**: MAY be provided after description, separated by blank line
   - Free-form, can contain multiple paragraphs
   - Provides additional contextual information

3. **Footer**: MAY be provided after body, separated by blank line
   - Uses format: `Token: value` or `Token #value`
   - Special footer: `BREAKING CHANGE: description` for breaking changes

## Breaking Changes

Breaking changes MUST be indicated in one of two ways:

1. Append `!` after type/scope: `feat!: send email on product shipped`
2. Include footer: `BREAKING CHANGE: description`

## Examples

- `feat: allow provided config object to extend other configs`
- `fix: prevent racing of requests`
- `feat(api)!: send an email when product is shipped`
- `docs: correct spelling of CHANGELOG`
- `feat(lang): add Polish language`
- `chore!: drop support for Node 6`
- `fix(parser): array parsing issue when multiple spaces contained`

## Rules

- Types are case-insensitive (but be consistent)
- Scope is optional but recommended for clarity
- Description should be concise and in imperative mood
- Always use this format - no exceptions
- When suggesting commits, always format them according to this specification