asepharyana
8ecc588a3e
- Implemented a code quality scanner that checks for common clean-code violations in Rust source files, including missing documentation, usage of `.unwrap()` in production code, and commented-out code. - Introduced a commit message validator that follows the Conventional Commits specification, ensuring proper formatting and providing suggestions for invalid messages. - Created a unified BestPracticeEngine to encapsulate the functionalities of skills, architecture audits, code quality checks, and commit message validation. - Added tests for both the code quality scanner and commit message validator to ensure reliability and correctness.
2.0 KiB
2.0 KiB
name, description
| name | description |
|---|---|
| commit-convention | Enforce commit message convention for features, fixes, chores, and docs |
Commit Message Convention
All commit messages MUST follow one of the four formats below. The type is lowercase. The subject is imperative, lowercase, and has no trailing period.
Types
feat — New feature or new behaviour
Scope is required: the name of the affected module.
feat(<module>): <what changed or what feature>
Examples:
feat(auth): add google oauth sign-in
feat(billing): support multi-currency invoices
feat(users): allow avatar upload
fix — Bug fix or issue resolution
Scope is required: the name of the affected module.
fix(<module>): <what was fixed>
Examples:
fix(auth): prevent token refresh race condition
fix(cart): correct total when discount is zero
fix(api): return 404 instead of 500 on missing user
chore — Housekeeping, dependency bumps, config changes
No scope.
chore: <what was adjusted>
Examples:
chore: adjust package.json version (bump)
chore: update eslint config
chore: remove unused devDependency
docs — Documentation only
No scope.
docs: <what changed>
Examples:
docs: add setup guide to README
docs: document commit convention
docs: clarify env variable defaults
Rules
- Type is ALWAYS lowercase (
feat,fix,chore,docs). featandfixREQUIRE a module scope in parentheses.choreanddocsdo NOT use a scope.- Subject line is imperative mood ("add", not "added" or "adds").
- Subject line is lowercase, no trailing period.
- Keep the subject under ~72 characters.
- If a commit needs multiple types, split it into multiple commits.
Choosing the right type
| Situation | Type |
|---|---|
| New user-facing capability | feat |
| New internal behaviour | feat |
| Something was broken, now works | fix |
| Version bump in package.json | chore |
| Lockfile regeneration, config tweak | chore |
| README, guide, or comment-only change | docs |