Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 40 additions & 0 deletions .cursorrules
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
# Commit Message Rules

When generating commit messages, ALWAYS follow the Conventional Commits specification:

## Format

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

## Types (use exactly these):

- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (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 tests or correcting existing tests
- build: Changes that affect the build system or external dependencies
- ci: Changes to CI configuration files and scripts
- chore: Other changes that don't modify src or test files
- revert: Reverts a previous commit

## Rules:

1. Use lowercase for type
2. Scope is optional but recommended (e.g., auth, api, ui, db)
3. Description must be in imperative mood ("add" not "added" or "adds")
4. Description must start with lowercase
5. No period at the end of the description
6. Keep the first line under 72 characters

## Examples:

- ✅ feat(auth): add social login with Google OAuth
- ✅ fix(api): resolve race condition in user update endpoint
- ✅ chore: update dependencies to latest versions
- ✅ docs(readme): add installation instructions for Windows
- ❌ Added new feature (missing type)
- ❌ feat: Added login (wrong tense, capitalized)
- ❌ fix(api): fixes bug. (wrong tense, has period)
42 changes: 42 additions & 0 deletions .gitmessage
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# <type>(<scope>): <subject>
#
# <body>
#
# <footer>
#
# 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 tests or correcting existing tests
# * build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, 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 is optional and can be anything specifying the place of the commit change.
# For example: auth, api, ui, db, etc.
#
# Subject must:
# * use the imperative, present tense: "change" not "changed" nor "changes"
# * don't capitalize the first letter
# * no dot (.) at the end
#
# Body should include the motivation for the change and contrast this with previous behavior.
#
# Footer should contain any information about Breaking Changes and is also the place to
# reference GitHub issues that this commit closes.
#
# Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines.
# The rest of the commit message is then used for this.
#
# Example:
# feat(auth): add OAuth2 integration
#
# Add support for OAuth2 authentication with Google and GitHub providers.
# This allows users to sign in using their existing accounts.
#
# Closes #123
4 changes: 4 additions & 0 deletions .husky/commit-msg
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
#!/usr/bin/env sh
. "$(dirname "$0")/_/husky.sh"

npx commitlint --edit $1
Loading