feat: Initial agent-skills repo — 4 adapted skills for Mosaic Stack
Skills included: - pr-reviewer: Adapted for Gitea/GitHub via platform-aware scripts (dropped fetch_pr_data.py and add_inline_comment.py, kept generate_review_files.py) - code-review-excellence: Methodology and checklists (React, TS, Python, etc.) - vercel-react-best-practices: 57 rules for React/Next.js performance - tailwind-design-system: Tailwind CSS v4 patterns, CVA, design tokens New shell scripts added to ~/.claude/scripts/git/: - pr-diff.sh: Get PR diff (GitHub gh / Gitea API) - pr-metadata.sh: Get PR metadata as normalized JSON Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Jason Woltje
368
skills/pr-reviewer/references/gh_cli_guide.md
Normal file
368
skills/pr-reviewer/references/gh_cli_guide.md
Normal file
@@ -0,0 +1,368 @@
|
||||
# GitHub CLI (gh) Guide for PR Reviews
|
||||
|
||||
This reference provides quick commands and patterns for accessing PR data using the GitHub CLI.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Install GitHub CLI: https://cli.github.com/
|
||||
|
||||
Authenticate:
|
||||
```bash
|
||||
gh auth login
|
||||
```
|
||||
|
||||
## Basic PR Information
|
||||
|
||||
### View PR Details
|
||||
```bash
|
||||
gh pr view <number> --repo <owner>/<repo>
|
||||
|
||||
# With JSON output
|
||||
gh pr view <number> --repo <owner>/<repo> --json number,title,body,state,author,headRefName,baseRefName
|
||||
```
|
||||
|
||||
### View PR Diff
|
||||
```bash
|
||||
gh pr diff <number> --repo <owner>/<repo>
|
||||
|
||||
# Save to file
|
||||
gh pr diff <number> --repo <owner>/<repo> > pr_diff.patch
|
||||
```
|
||||
|
||||
### List PR Files
|
||||
```bash
|
||||
gh pr view <number> --repo <owner>/<repo> --json files --jq '.files[].path'
|
||||
```
|
||||
|
||||
## PR Comments and Reviews
|
||||
|
||||
### Get PR Comments (Review Comments on Code)
|
||||
```bash
|
||||
gh api /repos/<owner>/<repo>/pulls/<number>/comments
|
||||
|
||||
# Paginate through all comments
|
||||
gh api /repos/<owner>/<repo>/pulls/<number>/comments --paginate
|
||||
|
||||
# With JQ filtering
|
||||
gh api /repos/<owner>/<repo>/pulls/<number>/comments --jq '.[] | {path, line, body, user: .user.login}'
|
||||
```
|
||||
|
||||
### Get PR Reviews
|
||||
```bash
|
||||
gh api /repos/<owner>/<repo>/pulls/<number>/reviews
|
||||
|
||||
# With formatted output
|
||||
gh api /repos/<owner>/<repo>/pulls/<number>/reviews --jq '.[] | {state, user: .user.login, body}'
|
||||
```
|
||||
|
||||
### Get Issue Comments (General PR Comments)
|
||||
```bash
|
||||
gh api /repos/<owner>/<repo>/issues/<number>/comments
|
||||
```
|
||||
|
||||
## Commit Information
|
||||
|
||||
### List PR Commits
|
||||
```bash
|
||||
gh api /repos/<owner>/<repo>/pulls/<number>/commits
|
||||
|
||||
# Get commit messages
|
||||
gh api /repos/<owner>/<repo>/pulls/<number>/commits --jq '.[] | {sha: .sha[0:7], message: .commit.message}'
|
||||
|
||||
# Get latest commit SHA
|
||||
gh api /repos/<owner>/<repo>/pulls/<number>/commits --jq '.[-1].sha'
|
||||
```
|
||||
|
||||
### Get Commit Details
|
||||
```bash
|
||||
gh api /repos/<owner>/<repo>/commits/<sha>
|
||||
|
||||
# Get commit diff
|
||||
gh api /repos/<owner>/<repo>/commits/<sha> -H "Accept: application/vnd.github.diff"
|
||||
```
|
||||
|
||||
## Branches
|
||||
|
||||
### Get Branch Information
|
||||
```bash
|
||||
# Source branch (head)
|
||||
gh pr view <number> --repo <owner>/<repo> --json headRefName --jq '.headRefName'
|
||||
|
||||
# Target branch (base)
|
||||
gh pr view <number> --repo <owner>/<repo> --json baseRefName --jq '.baseRefName'
|
||||
```
|
||||
|
||||
### Compare Branches
|
||||
```bash
|
||||
gh api /repos/<owner>/<repo>/compare/<base>...<head>
|
||||
|
||||
# Get files changed
|
||||
gh api /repos/<owner>/<repo>/compare/<base>...<head> --jq '.files[] | {filename, status, additions, deletions}'
|
||||
```
|
||||
|
||||
## Related Issues and Tickets
|
||||
|
||||
### Get Linked Issues
|
||||
```bash
|
||||
# Get PR body which may contain issue references
|
||||
gh pr view <number> --repo <owner>/<repo> --json body --jq '.body'
|
||||
|
||||
# Search for issue references (#123 format)
|
||||
gh pr view <number> --repo <owner>/<repo> --json body --jq '.body' | grep -oE '#[0-9]+'
|
||||
```
|
||||
|
||||
### Get Issue Details
|
||||
```bash
|
||||
gh issue view <number> --repo <owner>/<repo>
|
||||
|
||||
# JSON format
|
||||
gh issue view <number> --repo <owner>/<repo> --json number,title,body,state,labels,assignees
|
||||
```
|
||||
|
||||
### Get Issue Comments
|
||||
```bash
|
||||
gh api /repos/<owner>/<repo>/issues/<number>/comments
|
||||
```
|
||||
|
||||
## PR Status Checks
|
||||
|
||||
### Get PR Status
|
||||
```bash
|
||||
gh pr checks <number> --repo <owner>/<repo>
|
||||
|
||||
# JSON format
|
||||
gh api /repos/<owner>/<repo>/commits/<sha>/status
|
||||
```
|
||||
|
||||
### Get Check Runs
|
||||
```bash
|
||||
gh api /repos/<owner>/<repo>/commits/<sha>/check-runs
|
||||
```
|
||||
|
||||
## Adding Comments
|
||||
|
||||
### Add Inline Code Comment
|
||||
```bash
|
||||
gh api -X POST /repos/<owner>/<repo>/pulls/<number>/comments \
|
||||
-f body="Your comment here" \
|
||||
-f commit_id="<sha>" \
|
||||
-f path="src/file.py" \
|
||||
-f side="RIGHT" \
|
||||
-f line=42
|
||||
```
|
||||
|
||||
### Add Multi-line Inline Comment
|
||||
```bash
|
||||
gh api -X POST /repos/<owner>/<repo>/pulls/<number>/comments \
|
||||
-f body="Multi-line comment" \
|
||||
-f commit_id="<sha>" \
|
||||
-f path="src/file.py" \
|
||||
-f side="RIGHT" \
|
||||
-f start_line=40 \
|
||||
-f start_side="RIGHT" \
|
||||
-f line=45
|
||||
```
|
||||
|
||||
### Add General PR Comment
|
||||
```bash
|
||||
gh pr comment <number> --repo <owner>/<repo> --body "Your comment"
|
||||
|
||||
# Or via API
|
||||
gh api -X POST /repos/<owner>/<repo>/issues/<number>/comments \
|
||||
-f body="Your comment"
|
||||
```
|
||||
|
||||
## Creating a Review
|
||||
|
||||
### Create Review with Comments
|
||||
```bash
|
||||
gh api -X POST /repos/<owner>/<repo>/pulls/<number>/reviews \
|
||||
-f body="Overall review comments" \
|
||||
-f event="COMMENT" \
|
||||
-f commit_id="<sha>" \
|
||||
-f comments='[{"path":"src/file.py","line":42,"body":"Comment on line 42"}]'
|
||||
```
|
||||
|
||||
### Submit Review (Approve/Request Changes)
|
||||
```bash
|
||||
# Approve
|
||||
gh api -X POST /repos/<owner>/<repo>/pulls/<number>/reviews \
|
||||
-f body="LGTM!" \
|
||||
-f event="APPROVE" \
|
||||
-f commit_id="<sha>"
|
||||
|
||||
# Request changes
|
||||
gh api -X POST /repos/<owner>/<repo>/pulls/<number>/reviews \
|
||||
-f body="Please address these issues" \
|
||||
-f event="REQUEST_CHANGES" \
|
||||
-f commit_id="<sha>"
|
||||
```
|
||||
|
||||
## Searching and Filtering
|
||||
|
||||
### Search Code in PR
|
||||
```bash
|
||||
# Get PR diff and search
|
||||
gh pr diff <number> --repo <owner>/<repo> | grep "search_term"
|
||||
|
||||
# Search in specific files
|
||||
gh pr view <number> --repo <owner>/<repo> --json files --jq '.files[] | select(.path | contains("search_term"))'
|
||||
```
|
||||
|
||||
### Filter by File Type
|
||||
```bash
|
||||
gh pr view <number> --repo <owner>/<repo> --json files --jq '.files[] | select(.path | endswith(".py"))'
|
||||
```
|
||||
|
||||
## Labels, Assignees, and Metadata
|
||||
|
||||
### Get Labels
|
||||
```bash
|
||||
gh pr view <number> --repo <owner>/<repo> --json labels --jq '.labels[].name'
|
||||
```
|
||||
|
||||
### Get Assignees
|
||||
```bash
|
||||
gh pr view <number> --repo <owner>/<repo> --json assignees --jq '.assignees[].login'
|
||||
```
|
||||
|
||||
### Get Reviewers
|
||||
```bash
|
||||
gh pr view <number> --repo <owner>/<repo> --json reviewRequests --jq '.reviewRequests[].login'
|
||||
```
|
||||
|
||||
## Advanced Queries
|
||||
|
||||
### Get PR Timeline
|
||||
```bash
|
||||
gh api /repos/<owner>/<repo>/issues/<number>/timeline
|
||||
```
|
||||
|
||||
### Get PR Events
|
||||
```bash
|
||||
gh api /repos/<owner>/<repo>/issues/<number>/events
|
||||
```
|
||||
|
||||
### Get All PR Data
|
||||
```bash
|
||||
gh pr view <number> --repo <owner>/<repo> --json \
|
||||
number,title,body,state,author,headRefName,baseRefName,\
|
||||
commits,reviews,comments,files,labels,assignees,milestone,\
|
||||
createdAt,updatedAt,mergedAt,closedAt,url,isDraft
|
||||
```
|
||||
|
||||
## Common JQ Patterns
|
||||
|
||||
### Extract specific fields
|
||||
```bash
|
||||
--jq '.field'
|
||||
--jq '.array[].field'
|
||||
--jq '.[] | {field1, field2}'
|
||||
```
|
||||
|
||||
### Filter arrays
|
||||
```bash
|
||||
--jq '.[] | select(.field == "value")'
|
||||
--jq '.[] | select(.field | contains("substring"))'
|
||||
```
|
||||
|
||||
### Count items
|
||||
```bash
|
||||
--jq '. | length'
|
||||
--jq '.array | length'
|
||||
```
|
||||
|
||||
### Map and transform
|
||||
```bash
|
||||
--jq '.array | map(.field)'
|
||||
--jq '.[] | {newField: .oldField}'
|
||||
```
|
||||
|
||||
## Line Number Considerations for Inline Comments
|
||||
|
||||
**IMPORTANT**: The `line` parameter for inline comments refers to the **line number in the diff**, not the absolute line number in the file.
|
||||
|
||||
### Understanding Diff Line Numbers
|
||||
|
||||
In a diff:
|
||||
- Lines are numbered relative to the diff context, not the file
|
||||
- The `side` parameter determines which version:
|
||||
- `"RIGHT"`: New version (after changes)
|
||||
- `"LEFT"`: Old version (before changes)
|
||||
|
||||
### Finding Diff Line Numbers
|
||||
|
||||
```bash
|
||||
# Get diff with line numbers
|
||||
gh pr diff <number> --repo <owner>/<repo> | cat -n
|
||||
|
||||
# Get specific file diff
|
||||
gh api /repos/<owner>/<repo>/pulls/<number>/files --jq '.[] | select(.filename == "path/to/file")'
|
||||
```
|
||||
|
||||
### Example Diff
|
||||
```diff
|
||||
@@ -10,7 +10,8 @@ def process_data(data):
|
||||
if not data:
|
||||
return None
|
||||
|
||||
- result = old_function(data)
|
||||
+ # New implementation
|
||||
+ result = new_function(data)
|
||||
return result
|
||||
```
|
||||
|
||||
In this diff:
|
||||
- Line 13 (old) would be `side: "LEFT"`
|
||||
- Line 14-15 (new) would be `side: "RIGHT"`
|
||||
- Line numbers are relative to the diff hunk starting at line 10
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Errors
|
||||
|
||||
**Resource not found**:
|
||||
```bash
|
||||
# Check repo access
|
||||
gh repo view <owner>/<repo>
|
||||
|
||||
# Check PR exists
|
||||
gh pr list --repo <owner>/<repo> | grep <number>
|
||||
```
|
||||
|
||||
**API rate limit**:
|
||||
```bash
|
||||
# Check rate limit
|
||||
gh api /rate_limit
|
||||
|
||||
# Use authentication to get higher limits
|
||||
gh auth login
|
||||
```
|
||||
|
||||
**Permission denied**:
|
||||
```bash
|
||||
# Check authentication
|
||||
gh auth status
|
||||
|
||||
# May need additional scopes
|
||||
gh auth refresh -s repo
|
||||
```
|
||||
|
||||
## Tips and Best Practices
|
||||
|
||||
1. **Use `--paginate`** for large result sets (comments, commits)
|
||||
2. **Combine with `jq`** for powerful filtering and formatting
|
||||
3. **Cache results** by saving to files to avoid repeated API calls
|
||||
4. **Check rate limits** when making many API calls
|
||||
5. **Use `--json` output** for programmatic parsing
|
||||
6. **Specify `--repo`** when outside repository directory
|
||||
7. **Get latest commit** before adding inline comments
|
||||
8. **Test comments** on draft PRs or test repositories first
|
||||
|
||||
## Reference Links
|
||||
|
||||
- GitHub CLI Manual: https://cli.github.com/manual/
|
||||
- GitHub REST API: https://docs.github.com/en/rest
|
||||
- JQ Manual: https://jqlang.github.io/jq/manual/
|
||||
- PR Review Comments API: https://docs.github.com/en/rest/pulls/comments
|
||||
- PR Reviews API: https://docs.github.com/en/rest/pulls/reviews
|
||||
345
skills/pr-reviewer/references/review_criteria.md
Normal file
345
skills/pr-reviewer/references/review_criteria.md
Normal file
@@ -0,0 +1,345 @@
|
||||
# Code Review Criteria
|
||||
|
||||
This document outlines the comprehensive criteria for conducting pull request code reviews. Use this as a checklist when reviewing PRs to ensure thorough, consistent, and constructive feedback.
|
||||
|
||||
## Review Process Overview
|
||||
|
||||
When reviewing a PR, the goal is to ensure changes are:
|
||||
- **Correct**: Solves the intended problem without bugs
|
||||
- **Maintainable**: Easy to understand and modify
|
||||
- **Aligned**: Follows project standards and conventions
|
||||
- **Secure**: Free from vulnerabilities
|
||||
- **Tested**: Covered by appropriate tests
|
||||
|
||||
## 1. Functionality and Correctness
|
||||
|
||||
### Problem Resolution
|
||||
- [ ] **Does the code solve the intended problem?**
|
||||
- Verify changes address the issue or feature described in the PR
|
||||
- Cross-reference with linked tickets (JIRA, GitHub issues)
|
||||
- Test manually or run the code if possible
|
||||
|
||||
### Bugs and Logic
|
||||
- [ ] **Are there bugs or logical errors?**
|
||||
- Check for off-by-one errors
|
||||
- Verify null/undefined/None handling
|
||||
- Review assumptions about inputs and outputs
|
||||
- Look for race conditions or concurrency issues
|
||||
- Check loop termination conditions
|
||||
|
||||
### Edge Cases and Error Handling
|
||||
- [ ] **Edge cases handled?**
|
||||
- Empty collections (arrays, lists, maps)
|
||||
- Null/None/undefined values
|
||||
- Boundary values (min/max integers, empty strings)
|
||||
- Invalid or malformed inputs
|
||||
|
||||
- [ ] **Error handling implemented?**
|
||||
- Network failures
|
||||
- File system errors
|
||||
- Database connection issues
|
||||
- API errors and timeouts
|
||||
- Graceful degradation
|
||||
|
||||
### Compatibility
|
||||
- [ ] **Works across supported environments?**
|
||||
- Browser compatibility (if web app)
|
||||
- OS versions (if desktop/mobile)
|
||||
- Database versions
|
||||
- Language/runtime versions
|
||||
- Doesn't break existing features (regression check)
|
||||
|
||||
## 2. Readability and Maintainability
|
||||
|
||||
### Code Clarity
|
||||
- [ ] **Easy to read and understand?**
|
||||
- Meaningful variable names (avoid `x`, `temp`, `data`)
|
||||
- Meaningful function names (verb-first, descriptive)
|
||||
- Short methods/functions (ideally < 50 lines)
|
||||
- Logical structure and flow
|
||||
- Minimal nested complexity
|
||||
|
||||
### Modularity
|
||||
- [ ] **Single Responsibility Principle?**
|
||||
- Functions/methods do one thing well
|
||||
- Classes have a clear, focused purpose
|
||||
- No "god objects" or overly complex logic
|
||||
|
||||
- [ ] **Suggest refactoring if needed:**
|
||||
- Extract complex logic into helper functions
|
||||
- Break large functions into smaller ones
|
||||
- Separate concerns (UI, business logic, data access)
|
||||
|
||||
### Code Duplication
|
||||
- [ ] **DRY (Don't Repeat Yourself)?**
|
||||
- Repeated code abstracted into helpers
|
||||
- Shared logic moved to libraries/utilities
|
||||
- Avoid copy-paste programming
|
||||
|
||||
### Future-Proofing
|
||||
- [ ] **Allows for easy extensions?**
|
||||
- Avoid hard-coded values (use constants/configs)
|
||||
- Use dependency injection where appropriate
|
||||
- Follow SOLID principles
|
||||
- Consider extensibility without modification
|
||||
|
||||
## 3. Style and Conventions
|
||||
|
||||
### Style Guide Adherence
|
||||
- [ ] **Follows project linter rules?**
|
||||
- ESLint (JavaScript/TypeScript)
|
||||
- Pylint/Flake8/Black (Python)
|
||||
- RuboCop (Ruby)
|
||||
- Checkstyle/PMD (Java)
|
||||
- golangci-lint (Go)
|
||||
|
||||
- [ ] **Formatting consistent?**
|
||||
- Proper indentation (spaces vs. tabs)
|
||||
- Consistent spacing
|
||||
- Line length limits
|
||||
- Import/require organization
|
||||
|
||||
### Codebase Consistency
|
||||
- [ ] **Matches existing patterns?**
|
||||
- Follows established architectural patterns
|
||||
- Uses existing utilities and helpers
|
||||
- Consistent naming conventions
|
||||
- Matches idioms of the language/framework
|
||||
|
||||
### Comments and Documentation
|
||||
- [ ] **Sufficient comments?**
|
||||
- Complex algorithms explained
|
||||
- Non-obvious decisions documented
|
||||
- API contracts clarified
|
||||
- TODOs tracked with ticket numbers
|
||||
|
||||
- [ ] **Not excessive?**
|
||||
- Code should be self-documenting where possible
|
||||
- Avoid obvious comments ("increment i")
|
||||
|
||||
- [ ] **Documentation updated?**
|
||||
- README reflects new features
|
||||
- API docs updated
|
||||
- Inline docs (JSDoc, docstrings, etc.)
|
||||
- Architecture diagrams current
|
||||
|
||||
## 4. Performance and Efficiency
|
||||
|
||||
### Resource Usage
|
||||
- [ ] **Algorithm efficiency?**
|
||||
- Avoid O(n²) or worse in loops
|
||||
- Use appropriate data structures
|
||||
- Minimize database queries (N+1 problem)
|
||||
- Avoid unnecessary computations
|
||||
|
||||
### Scalability
|
||||
- [ ] **Performs well under load?**
|
||||
- No blocking operations in critical paths
|
||||
- Async/await for I/O operations
|
||||
- Pagination for large datasets
|
||||
- Caching where appropriate
|
||||
|
||||
### Optimization Balance
|
||||
- [ ] **Optimizations necessary?**
|
||||
- Premature optimization avoided
|
||||
- Readability not sacrificed for micro-optimizations
|
||||
- Benchmark before complex optimizations
|
||||
- Profile to identify actual bottlenecks
|
||||
|
||||
## 5. Security and Best Practices
|
||||
|
||||
### Vulnerabilities
|
||||
- [ ] **Common security issues addressed?**
|
||||
- SQL injection (use parameterized queries)
|
||||
- XSS (Cross-Site Scripting) - proper escaping
|
||||
- CSRF (Cross-Site Request Forgery) - tokens
|
||||
- Command injection
|
||||
- Path traversal
|
||||
- Authentication/authorization checks
|
||||
|
||||
### Data Handling
|
||||
- [ ] **Sensitive data protected?**
|
||||
- Encrypted in transit (HTTPS/TLS)
|
||||
- Encrypted at rest
|
||||
- Input validation and sanitization
|
||||
- Output encoding
|
||||
- PII handling compliance (GDPR, etc.)
|
||||
|
||||
- [ ] **Secrets management?**
|
||||
- No hardcoded passwords/API keys
|
||||
- Use environment variables
|
||||
- Use secret management systems
|
||||
- No secrets in logs
|
||||
|
||||
### Dependencies
|
||||
- [ ] **New packages justified?**
|
||||
- Actually necessary
|
||||
- From trusted sources
|
||||
- Up-to-date and maintained
|
||||
- No known vulnerabilities
|
||||
- License compatible
|
||||
|
||||
- [ ] **Dependency management?**
|
||||
- Lock files committed
|
||||
- Minimal dependency footprint
|
||||
- Consider alternatives if bloated
|
||||
|
||||
## 6. Testing and Quality Assurance
|
||||
|
||||
### Test Coverage
|
||||
- [ ] **Tests exist for new code?**
|
||||
- Unit tests for individual functions/methods
|
||||
- Integration tests for workflows
|
||||
- End-to-end tests for critical paths
|
||||
|
||||
- [ ] **Tests cover scenarios?**
|
||||
- Happy paths
|
||||
- Error conditions
|
||||
- Edge cases
|
||||
- Boundary conditions
|
||||
|
||||
### Test Quality
|
||||
- [ ] **Tests are meaningful?**
|
||||
- Not just for coverage metrics
|
||||
- Assert actual behavior
|
||||
- Test intent, not implementation
|
||||
- Avoid brittle tests
|
||||
|
||||
- [ ] **Test maintainability?**
|
||||
- Clear test names
|
||||
- Arrange-Act-Assert pattern
|
||||
- Minimal test duplication
|
||||
- Fast execution
|
||||
|
||||
### CI/CD Integration
|
||||
- [ ] **Automated checks pass?**
|
||||
- Linting
|
||||
- Tests (unit, integration, e2e)
|
||||
- Build process
|
||||
- Security scans
|
||||
- Code coverage thresholds
|
||||
|
||||
## 7. Overall PR Quality
|
||||
|
||||
### Scope
|
||||
- [ ] **PR is focused?**
|
||||
- Single feature/fix per PR
|
||||
- Not too large (< 400 lines ideal)
|
||||
- Suggest splitting if combines unrelated changes
|
||||
|
||||
### Commit History
|
||||
- [ ] **Clean, atomic commits?**
|
||||
- Each commit is logical unit
|
||||
- Descriptive commit messages
|
||||
- Follow conventional commits if applicable
|
||||
- Avoid "fix", "update", "wip" vagueness
|
||||
|
||||
### PR Description
|
||||
- [ ] **Clear description?**
|
||||
- Explains **why** changes were made
|
||||
- Links to tickets/issues
|
||||
- Steps to reproduce/test
|
||||
- Screenshots for UI changes
|
||||
- Breaking changes called out
|
||||
- Migration steps if needed
|
||||
|
||||
### Impact Assessment
|
||||
- [ ] **Considered downstream effects?**
|
||||
- API changes (breaking vs. backward-compatible)
|
||||
- Database schema changes
|
||||
- Impact on other teams/services
|
||||
- Performance implications
|
||||
- Monitoring and alerting needs
|
||||
|
||||
## Review Feedback Guidelines
|
||||
|
||||
### Communication Style
|
||||
- **Be constructive and kind**
|
||||
- Frame as suggestions: "Consider X because Y"
|
||||
- Not criticism: "This is wrong"
|
||||
- Acknowledge good work
|
||||
- Explain the "why" behind feedback
|
||||
|
||||
### Prioritization
|
||||
- **Focus on critical issues first:**
|
||||
1. Bugs and correctness
|
||||
2. Security vulnerabilities
|
||||
3. Performance problems
|
||||
4. Design/architecture issues
|
||||
5. Style and conventions
|
||||
|
||||
### Feedback Markers
|
||||
Use clear markers to indicate severity:
|
||||
- **🔴 Blocker**: Must be fixed before merge
|
||||
- **🟡 Important**: Should be addressed
|
||||
- **🟢 Nit**: Nice to have, optional
|
||||
- **💡 Suggestion**: Consider for future
|
||||
- **❓ Question**: Clarification needed
|
||||
- **✅ Praise**: Good work!
|
||||
|
||||
### Time Efficiency
|
||||
- Review promptly (within 24 hours)
|
||||
- For large PRs, review in chunks
|
||||
- Request smaller PRs if too large
|
||||
- Use automated tools to catch style issues
|
||||
|
||||
### Decision Making
|
||||
- **Approve**: Solid overall, minor nits acceptable
|
||||
- **Request Changes**: Blockers must be addressed
|
||||
- **Comment**: Provide feedback without blocking
|
||||
|
||||
## Language/Framework-Specific Considerations
|
||||
|
||||
### JavaScript/TypeScript
|
||||
- Type safety (TypeScript)
|
||||
- Promise handling (avoid callback hell)
|
||||
- Memory leaks (event listeners)
|
||||
- Bundle size impact
|
||||
|
||||
### Python
|
||||
- PEP 8 compliance
|
||||
- Type hints (Python 3.5+)
|
||||
- Virtual environment dependencies
|
||||
- Generator usage for memory efficiency
|
||||
|
||||
### Java
|
||||
- Memory management
|
||||
- Exception handling (checked vs. unchecked)
|
||||
- Thread safety
|
||||
- Immutability where appropriate
|
||||
|
||||
### Go
|
||||
- Error handling (no exceptions)
|
||||
- Goroutine management
|
||||
- Channel usage
|
||||
- Interface design
|
||||
|
||||
### SQL/Database
|
||||
- Index usage
|
||||
- Query performance
|
||||
- Transaction boundaries
|
||||
- Migration reversibility
|
||||
|
||||
### Frontend (React, Vue, Angular)
|
||||
- Component reusability
|
||||
- State management
|
||||
- Accessibility (a11y)
|
||||
- Performance (re-renders, bundle size)
|
||||
|
||||
## Tools and Automation
|
||||
|
||||
Leverage tools to automate checks:
|
||||
- **Linters**: ESLint, Pylint, RuboCop
|
||||
- **Formatters**: Prettier, Black, gofmt
|
||||
- **Security**: Snyk, CodeQL, Dependabot
|
||||
- **Coverage**: Codecov, Coveralls
|
||||
- **Performance**: Lighthouse, WebPageTest
|
||||
- **Accessibility**: axe, WAVE
|
||||
|
||||
## Resources
|
||||
|
||||
- Google Engineering Practices: https://google.github.io/eng-practices/review/
|
||||
- GitHub Code Review Guide: https://github.com/features/code-review
|
||||
- OWASP Top 10: https://owasp.org/www-project-top-ten/
|
||||
- Clean Code (Robert C. Martin)
|
||||
- Code Complete (Steve McConnell)
|
||||
71
skills/pr-reviewer/references/scenarios.md
Normal file
71
skills/pr-reviewer/references/scenarios.md
Normal file
@@ -0,0 +1,71 @@
|
||||
# Common Review Scenarios
|
||||
|
||||
Detailed workflows for specific review use cases.
|
||||
|
||||
## Scenario 1: Quick Review Request
|
||||
|
||||
**Trigger**: User provides PR URL and requests review.
|
||||
|
||||
**Workflow**:
|
||||
1. Run `fetch_pr_data.py` to collect data
|
||||
2. Read `SUMMARY.txt` and `metadata.json`
|
||||
3. Scan `diff.patch` for obvious issues
|
||||
4. Apply critical criteria (security, bugs, tests)
|
||||
5. Create findings JSON with analysis
|
||||
6. Run `generate_review_files.py` to create review files
|
||||
7. Direct user to review `pr/review.md` and `pr/human.md`
|
||||
8. Remind user to use `/show` to edit, then `/send` or `/send-decline`
|
||||
|
||||
## Scenario 2: Thorough Review with Inline Comments
|
||||
|
||||
**Trigger**: User requests comprehensive review with inline comments.
|
||||
|
||||
**Workflow**:
|
||||
1. Run `fetch_pr_data.py` with cloning enabled
|
||||
2. Read all collected files (metadata, diff, comments, commits)
|
||||
3. Apply full `review_criteria.md` checklist
|
||||
4. Identify critical issues, important issues, and nits
|
||||
5. Create findings JSON with `inline_comments` array
|
||||
6. Run `generate_review_files.py` to create all files
|
||||
7. Direct user to:
|
||||
- Review `pr/review.md` for detailed analysis
|
||||
- Edit `pr/human.md` if needed
|
||||
- Check `pr/inline.md` for proposed comments
|
||||
- Use `/show` to open in VS Code
|
||||
- Use `/send` or `/send-decline` when ready
|
||||
- Optionally post inline comments from `pr/inline.md`
|
||||
|
||||
## Scenario 3: Security-Focused Review
|
||||
|
||||
**Trigger**: User requests security-specific review.
|
||||
|
||||
**Workflow**:
|
||||
1. Fetch PR data
|
||||
2. Focus on `review_criteria.md` Section 5 (Security)
|
||||
3. Check for: SQL injection, XSS, CSRF, secrets exposure
|
||||
4. Examine dependencies in metadata
|
||||
5. Review authentication/authorization changes
|
||||
6. Report security findings with severity ratings
|
||||
|
||||
## Scenario 4: Review with Related Tickets
|
||||
|
||||
**Trigger**: User requests review against linked JIRA/GitHub ticket.
|
||||
|
||||
**Workflow**:
|
||||
1. Fetch PR data (captures ticket references)
|
||||
2. Read `related_issues.json`
|
||||
3. Compare PR changes against ticket requirements
|
||||
4. Verify all acceptance criteria met
|
||||
5. Note any missing functionality
|
||||
6. Suggest additional tests if needed
|
||||
|
||||
## Scenario 5: Large PR Review (>400 lines)
|
||||
|
||||
**Trigger**: PR contains more than 400 lines of changes.
|
||||
|
||||
**Workflow**:
|
||||
1. Suggest splitting into smaller PRs if feasible
|
||||
2. Review in logical chunks by file or feature
|
||||
3. Focus on architecture and design first
|
||||
4. Document structural concerns before line-level issues
|
||||
5. Prioritize security and correctness over style
|
||||
55
skills/pr-reviewer/references/troubleshooting.md
Normal file
55
skills/pr-reviewer/references/troubleshooting.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# Troubleshooting Guide
|
||||
|
||||
Common issues and solutions for the PR Reviewer skill.
|
||||
|
||||
## gh CLI Not Found
|
||||
|
||||
Install GitHub CLI: https://cli.github.com/
|
||||
|
||||
```bash
|
||||
# macOS
|
||||
brew install gh
|
||||
|
||||
# Linux
|
||||
sudo apt install gh # or yum, dnf, etc.
|
||||
|
||||
# Authenticate
|
||||
gh auth login
|
||||
```
|
||||
|
||||
## Permission Denied Errors
|
||||
|
||||
Check authentication:
|
||||
|
||||
```bash
|
||||
gh auth status
|
||||
gh auth refresh -s repo
|
||||
```
|
||||
|
||||
## Invalid PR URL
|
||||
|
||||
Ensure URL format: `https://github.com/owner/repo/pull/NUMBER`
|
||||
|
||||
## Line Number Mismatch in Diff
|
||||
|
||||
Inline comment line numbers are **relative to the diff**, not absolute file positions.
|
||||
Use `gh pr diff <number>` to see diff line numbers.
|
||||
|
||||
## Rate Limit Errors
|
||||
|
||||
```bash
|
||||
# Check rate limit
|
||||
gh api /rate_limit
|
||||
|
||||
# Authenticated users get higher limits
|
||||
gh auth login
|
||||
```
|
||||
|
||||
## Common Error Patterns
|
||||
|
||||
| Error | Cause | Solution |
|
||||
|-------|-------|----------|
|
||||
| 401 Unauthorized | Token expired | Run `gh auth refresh` |
|
||||
| 403 Forbidden | Missing scope | Run `gh auth refresh -s repo` |
|
||||
| 404 Not Found | Private repo access | Verify repo permissions |
|
||||
| 422 Unprocessable | Invalid request | Check command arguments |
|
||||
Reference in New Issue
Block a user