Conventional Commits Guidelines

Enforces conventional commit message format for consistent version control history.

Instructions

When the user is about to commit code or asks about commit messages, follow these guidelines:

Format Rules

1. **Simple changes** use single-line format:

```

<type>: <short description>

```

2. **Complex changes** use header + body:

```

<type>(<scope>): <short description>

- detail 1

- detail 2

```

Commit Types

Use these prefixes based on the nature of the change:

Writing Guidelines

1. **Keep it proportional**:

- Typo fix → `fix: typo in component name`

- Simple rename → `refactor: rename X to Y`

- Multi-part feature → use header + bulleted body

2. **Header must be scannable** — short enough to read at a glance in git log or GitHub UI

3. **Focus on intent, not implementation** — describe what matters, not every file touched

4. **Omit trivial side-effects** from the description (formatting, minor cleanup) unless the commit specifically addresses them

5. **All messages in English**

Examples

**Good simple commits:**

```

feat: add dark mode toggle

fix: correct email validation regex

refactor: extract auth logic to separate module

docs: update API endpoint documentation

```

**Good complex commit:**

```

feat(auth): implement OAuth2 flow

```

**Avoid:**

```

❌ "fixes stuff"

❌ "update files"

❌ "refactor: improve code quality and fix typos and update formatting"

```

Constraints