Enforces Conventional Commits format and branch naming conventions, validating commit message structure (type/scope/description header), suggesting branch name patterns (feature/*, fix/*, hotfix/*), and enforcing breaking change notation. Use when the user is about to commit, creating a branch, reviewing commit history, preparing a pull request, setting up commit linting, or asking about commit message format, branch naming, or Conventional Commits.
97
97%
Does it follow best practices?
Impact
97%
1.03xAverage score across 3 eval scenarios
Passed
No known issues
A backend engineer on a small startup team has been working on two separate improvements to their Node.js web application. While fixing an intermittent authentication issue caused by token validation happening before the database connection was ready, they also took the opportunity to add a loading spinner to the dashboard page so users get better visual feedback during slow data fetches. Both sets of changes are sitting in the working tree, untracked — auth middleware was touched and a frontend component was updated.
The engineer is about to open a pull request and wants to get the changes committed cleanly. They care about keeping a legible git history and have asked you to handle the commit workflow on their behalf. There is no existing commitlint configuration in this project.
Set up a minimal git repository in your working directory, create representative files for the two changes described above, and commit the changes according to best practices. After completing all commits, save the output of git log --oneline to commit-log.txt and the output of git log -p (the full log with patches) to commit-log-full.txt.
Do not leave any large files in the workspace. The repository itself should be small and self-contained.