git-commit-reviewer

Files (2)

• SKILL.md
• metadata.json

SKILL.md (first lines)

# 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

From abhiunix/community-registry, MIT.

More from abhiunix/community-registry