Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
aif-review
artemyurov/moonshine-db-joblog
claude-code
code-review
git
github
security
performance
testing
pull-requests

Perform code review on staged changes or a pull request. Checks for bugs, security issues, performance problems, and best practices. Use when user says "review code", "check my code", "review PR", or "is this code okay".

Install
php artisan boost:add-skill artemyurov/moonshine-db-joblog

Save this content to: .claude/skills/aif-review/SKILL.md

# Code Review Assistant

Perform thorough code reviews focusing on correctness, security, performance, and maintainability.

## Behavior

### Without Arguments (Review Staged Changes)

1. Run `git diff --cached` to get staged changes
2. If nothing staged, run `git diff` for unstaged changes
3. Analyze each file's changes

### With PR Number/URL

1. Use `gh pr view <number> --json` to get PR details
2. Use `gh pr diff <number>` to get the diff
3. Review all changes in the PR

## Review Checklist

### Correctness
- [ ] Logic errors or bugs
- [ ] Edge cases handling
- [ ] Null/undefined checks
- [ ] Error handling completeness
- [ ] Type safety (if applicable)

### Security
- [ ] SQL injection vulnerabilities
- [ ] XSS vulnerabilities
- [ ] Command injection
- [ ] Sensitive data exposure
- [ ] Authentication/authorization issues
- [ ] CSRF protection
- [ ] Input validation

### Performance
- [ ] N+1 query problems
- [ ] Unnecessary re-renders (React)
- [ ] Memory leaks
- [ ] Inefficient algorithms
- [ ] Missing indexes (database)
- [ ] Large payload sizes

### Best Practices
- [ ] Code duplication
- [ ] Dead code
- [ ] Magic numbers/strings
- [ ] Proper naming conventions
- [ ] SOLID principles
- [ ] DRY principle

### Testing
- [ ] Test coverage for new code
- [ ] Edge cases tested
- [ ] Mocking appropriateness

## Output Format

```markdown
## Code Review Summary

**Files Reviewed:** [count]
**Risk Level:** 🟢 Low / 🟡 Medium / 🔴 High

### Critical Issues
[Must be fixed before merge]

### Suggestions
[Nice to have improvements]

### Questions
[Clarifications needed]

### Positive Notes
[Good patterns observed]
```

## Review Style

- Be constructive, not critical
- Explain the "why" behind suggestions
- Provide code examples when helpful
- Acknowledge good code
- Prioritize feedback by importance
- Ask questions instead of making assumptions

## Examples

**User:** `/aif-review`
Review staged changes in current repository.

**User:** `/aif-review 123`
Review PR #123 using GitHub CLI.

**User:** `/aif-review https://github.com/org/repo/pull/123`
Review PR from URL.

## Integration

If GitHub MCP is configured, can:
- Post review comments directly to PR
- Request changes or approve
- Add labels based on review outcome

> **Tip:** Context is heavy after code review. Consider `/clear` or `/compact` before continuing with other tasks.

Code Review Assistant

Perform thorough code reviews focusing on correctness, security, performance, and maintainability.

Behavior

Without Arguments (Review Staged Changes)

  1. Run git diff --cached to get staged changes
  2. If nothing staged, run git diff for unstaged changes
  3. Analyze each file's changes

With PR Number/URL

  1. Use gh pr view <number> --json to get PR details
  2. Use gh pr diff <number> to get the diff
  3. Review all changes in the PR

Review Checklist

Correctness

  • Logic errors or bugs
  • Edge cases handling
  • Null/undefined checks
  • Error handling completeness
  • Type safety (if applicable)

Security

  • SQL injection vulnerabilities
  • XSS vulnerabilities
  • Command injection
  • Sensitive data exposure
  • Authentication/authorization issues
  • CSRF protection
  • Input validation

Performance

  • N+1 query problems
  • Unnecessary re-renders (React)
  • Memory leaks
  • Inefficient algorithms
  • Missing indexes (database)
  • Large payload sizes

Best Practices

  • Code duplication
  • Dead code
  • Magic numbers/strings
  • Proper naming conventions
  • SOLID principles
  • DRY principle

Testing

  • Test coverage for new code
  • Edge cases tested
  • Mocking appropriateness

Output Format

## Code Review Summary

**Files Reviewed:** [count]
**Risk Level:** 🟢 Low / 🟡 Medium / 🔴 High

### Critical Issues
[Must be fixed before merge]

### Suggestions
[Nice to have improvements]

### Questions
[Clarifications needed]

### Positive Notes
[Good patterns observed]

Review Style

  • Be constructive, not critical
  • Explain the "why" behind suggestions
  • Provide code examples when helpful
  • Acknowledge good code
  • Prioritize feedback by importance
  • Ask questions instead of making assumptions

Examples

User: /aif-review Review staged changes in current repository.

User: /aif-review 123 Review PR #123 using GitHub CLI.

User: /aif-review https://github.com/org/repo/pull/123 Review PR from URL.

Integration

If GitHub MCP is configured, can:

  • Post review comments directly to PR
  • Request changes or approve
  • Add labels based on review outcome

Tip: Context is heavy after code review. Consider /clear or /compact before continuing with other tasks.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console