smart-commit

Topics in the source

• Smart Commit
• Safety rules (always)
• 1. Look at what changed
• 2. Split into atomic commits
• 3. Write the message (Conventional Commits)
• 4. PR description (when asked)
• 5. Release notes (when asked)

Never commit secrets. Before committing, scan the staged diff for things like APIKEY=, sk-, -----BEGIN, password =, .env files. If found, stop and tell the user. Never git push --force, reset --hard, or rewrite history unless the user explicitly asks. Never commit without showing the user the plan first if there are >1 commits or unrelated changes. Read the actual diff — messages are written from the code, not from file names. If the changes mix concerns (a feature + an unrelated fix + formatting), propose a split: Stage per commit with git add (or git add -p for partial files). If everything is one concern, one commit is fine. Types: feat, fix, refactor, perf, test, docs, build, ci, chore, style, revert. Scope = the module/area (api, auth, ui, deps). Check git log --oneline -20 and follow the repo's existing style if it differs (language, scope format, emoji usage). Good: fix(cart): prevent negative quantity when removing last item Bad: update files, fix bug, WIP Base it on git log main..HEAD and git diff main...HEAD: If gh is available and the user wants it, gh pr create --title ... --body-file .... Group commits since the last tag (git describe --tags --abbrev=0) into ✨ Features

This is an excerpt. Refer to the complete source and its current requirements.