## Instructions

- Use conventional commit format (<type>([scope]): <subject>).
  - List of acceptable `type` are:
    - `feat` for a new feature.
    - `fix` for a bug fix.
    - `docs` for documentation changes.
    - `style` for code changes/formatting without changing code logic.
    - `refactor` for code changes without adding features or fixing bugs.
    - `perf` for performance optimizations and improvements.
    - `test` for adding or correcting tests.
    - `build` for changes that affect the build system or external dependencies.
    - `ci` for changes to our CI configuration files or scripts.
    - `chore` for other changes that do not modify source or test files.
    - `revert` for reverting a previous commit.
  - `scope` is an optional contextual information regarding the scope of the commit.
  - `subject` is the summary/description in present tense.
- Avoid overly verbose descriptions or unnecessary details.
- Do not add backticks ('`') at the beginning and at the end of the commit message.

## Examples

- feat: new feature for the user, not a new feature for build script
- fix: bug fix for the user, not a fix to a build script
- fix(auth): fix social media login bug
- docs: changes to the documentation
- docs(readme): update installation instructions
- style: formatting, missing semi colons, etc; no production code change
- refactor: refactoring production code, eg. renaming a variable
- perf(startup): improve startup performance from 5s to 2s
- test: adding missing tests, refactoring tests; no production code change
- chore: updating grunt tasks etc; no production code change