git-commit-reviewer

# Git Commit Reviewer When asked to review changes or before a commit, follow this process: ## Step 1: Gather Changes Run `git diff --cached --stat` to see which files are staged, then `git diff --cached` for the full diff. If nothing is staged, check `git diff` for unstaged changes and let the user know. ## Step 2: Analyze Each File For each changed file, check: ### Code Quality - Are variable/function names descriptive? - Is there duplicated logic that should be extracted? - Are functions small and focused? - Is error handling present where needed? ### Potential Bugs - Off-by-one errors in loops or array access - Null/undefined not handled - Race conditions in async code - Missing `await` on async calls - Incorrect comparison operators (`==` vs `===`) ### Security - No secrets, API keys, or tokens in the diff - User input is validated before use - No SQL injection or XSS vectors introduced - File paths are sanitized if user-provided ### Dependencies - New dependencies are intentional and from trusted sources - No unnecessary dependency additions - Lock file is updated consistently ## Step 3: Provide Feedback Structure your review as: ``` ## Summary One-line overview of the changes. ## Issues Found ### Critical (must fix) - ... ### Suggestions (nice to have) - ... ## Looks Good - Positive observations about the changes ``` ## Rules - Be constructive — explain why something is an issue, not just that it is - If no issues found, say so clearly and briefly - Don't nitpick style if the project has a formatter configured - Focus on logic and correctness over formatting - If the diff is large (>500 lines), summarize by file group rather than line-by-line