Add code-reviewer agent and code-review skill
Create specialized agent for automated PR code review that: - Fetches PR diffs via fj CLI - Analyzes code for quality, bugs, security, style, and test coverage - Posts structured review comments to PRs Includes code-review skill with guidelines for reviewing code changes. Closes #9 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
98
agents/code-reviewer/AGENT.md
Normal file
98
agents/code-reviewer/AGENT.md
Normal file
@@ -0,0 +1,98 @@
|
|||||||
|
# Code Reviewer Agent
|
||||||
|
|
||||||
|
Specialized agent for automated code review of pull requests. Provides immediate, structured feedback on code changes.
|
||||||
|
|
||||||
|
## Skills
|
||||||
|
|
||||||
|
- forgejo
|
||||||
|
- code-review
|
||||||
|
|
||||||
|
## Capabilities
|
||||||
|
|
||||||
|
This agent can:
|
||||||
|
- Fetch PR diffs via `fj pr view <number> diff`
|
||||||
|
- Analyze code for quality issues
|
||||||
|
- Identify potential bugs and logic errors
|
||||||
|
- Check for security vulnerabilities
|
||||||
|
- Evaluate code style and consistency
|
||||||
|
- Assess test coverage gaps
|
||||||
|
- Post structured review comments via `fj pr comment`
|
||||||
|
|
||||||
|
## When to Use
|
||||||
|
|
||||||
|
Spawn this agent for:
|
||||||
|
- Automated review after PR creation (e.g., from `/work-issue`)
|
||||||
|
- On-demand code review of any PR
|
||||||
|
- Pre-merge quality checks
|
||||||
|
|
||||||
|
This agent should be spawned asynchronously so it doesn't block the main workflow.
|
||||||
|
|
||||||
|
## Behavior
|
||||||
|
|
||||||
|
### Input
|
||||||
|
|
||||||
|
The agent expects a PR number as input:
|
||||||
|
```
|
||||||
|
Review PR #<number>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Review Process
|
||||||
|
|
||||||
|
1. Fetch PR details and diff using `fj pr view <number> diff`
|
||||||
|
2. Analyze the diff for:
|
||||||
|
- **Code Quality**: Readability, maintainability, complexity
|
||||||
|
- **Bugs**: Logic errors, edge cases, null checks
|
||||||
|
- **Security**: Injection vulnerabilities, auth issues, data exposure
|
||||||
|
- **Style**: Naming conventions, formatting, consistency
|
||||||
|
- **Test Coverage**: Missing tests, untested edge cases
|
||||||
|
3. Generate a structured review comment
|
||||||
|
4. Post the review via `fj pr comment <number> "<review>"`
|
||||||
|
|
||||||
|
### Review Comment Format
|
||||||
|
|
||||||
|
The agent posts reviews in this structured format:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## AI Code Review
|
||||||
|
|
||||||
|
> This is an automated review generated by the code-reviewer agent.
|
||||||
|
|
||||||
|
### Summary
|
||||||
|
[Brief overall assessment]
|
||||||
|
|
||||||
|
### Findings
|
||||||
|
|
||||||
|
#### Code Quality
|
||||||
|
- [Finding 1]
|
||||||
|
- [Finding 2]
|
||||||
|
|
||||||
|
#### Potential Bugs
|
||||||
|
- [Finding or "No issues found"]
|
||||||
|
|
||||||
|
#### Security Concerns
|
||||||
|
- [Finding or "No issues found"]
|
||||||
|
|
||||||
|
#### Style Notes
|
||||||
|
- [Finding or "Consistent with codebase"]
|
||||||
|
|
||||||
|
#### Test Coverage
|
||||||
|
- [Finding or "Adequate coverage"]
|
||||||
|
|
||||||
|
### Verdict
|
||||||
|
[LGTM / Needs Changes / Blocking Issues]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Example Usage
|
||||||
|
|
||||||
|
From the main conversation, spawn this agent asynchronously:
|
||||||
|
|
||||||
|
```
|
||||||
|
Task: Review PR #42
|
||||||
|
Agent: code-reviewer
|
||||||
|
Background: true
|
||||||
|
```
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
- Requires `fj` CLI to be configured and authenticated
|
||||||
|
- Uses `code-review` skill for analysis guidelines
|
||||||
152
skills/code-review/SKILL.md
Normal file
152
skills/code-review/SKILL.md
Normal file
@@ -0,0 +1,152 @@
|
|||||||
|
# Code Review
|
||||||
|
|
||||||
|
Guidelines for reviewing code changes in pull requests.
|
||||||
|
|
||||||
|
## Review Categories
|
||||||
|
|
||||||
|
### Code Quality
|
||||||
|
|
||||||
|
Look for:
|
||||||
|
- **Readability**: Clear naming, logical structure, appropriate comments
|
||||||
|
- **Maintainability**: Easy to modify, follows DRY, single responsibility
|
||||||
|
- **Complexity**: Avoid deep nesting, overly long functions, complex conditionals
|
||||||
|
- **Dead code**: Unused variables, unreachable code, commented-out blocks
|
||||||
|
|
||||||
|
Questions to ask:
|
||||||
|
- Can someone unfamiliar with this code understand it quickly?
|
||||||
|
- Would I be comfortable maintaining this code?
|
||||||
|
- Does this follow existing patterns in the codebase?
|
||||||
|
|
||||||
|
### Potential Bugs
|
||||||
|
|
||||||
|
Look for:
|
||||||
|
- **Edge cases**: Empty arrays, null values, boundary conditions
|
||||||
|
- **Logic errors**: Off-by-one, incorrect operators, inverted conditions
|
||||||
|
- **Race conditions**: Async operations, shared state
|
||||||
|
- **Resource leaks**: Unclosed connections, missing cleanup
|
||||||
|
- **Error handling**: Unhandled exceptions, silent failures
|
||||||
|
|
||||||
|
Questions to ask:
|
||||||
|
- What happens with unexpected input?
|
||||||
|
- Are all error paths handled appropriately?
|
||||||
|
- Could concurrent execution cause issues?
|
||||||
|
|
||||||
|
### Security Concerns
|
||||||
|
|
||||||
|
Look for:
|
||||||
|
- **Injection**: SQL, command, XSS vulnerabilities
|
||||||
|
- **Authentication**: Bypasses, weak validation
|
||||||
|
- **Authorization**: Missing permission checks
|
||||||
|
- **Data exposure**: Logging secrets, exposing internals
|
||||||
|
- **Dependencies**: Known vulnerabilities in imports
|
||||||
|
|
||||||
|
Questions to ask:
|
||||||
|
- Could an attacker exploit this?
|
||||||
|
- Is user input properly validated and sanitized?
|
||||||
|
- Are secrets properly protected?
|
||||||
|
|
||||||
|
### Style & Consistency
|
||||||
|
|
||||||
|
Look for:
|
||||||
|
- **Naming conventions**: Match existing codebase style
|
||||||
|
- **Formatting**: Consistent indentation, spacing
|
||||||
|
- **File organization**: Logical grouping, appropriate location
|
||||||
|
- **Import order**: Following project conventions
|
||||||
|
|
||||||
|
Note: Style issues are lower priority than functional concerns.
|
||||||
|
|
||||||
|
### Test Coverage
|
||||||
|
|
||||||
|
Look for:
|
||||||
|
- **Missing tests**: New functionality without tests
|
||||||
|
- **Edge cases**: Boundary conditions not tested
|
||||||
|
- **Error paths**: Exception handling not verified
|
||||||
|
- **Integration**: Component interactions not covered
|
||||||
|
|
||||||
|
Questions to ask:
|
||||||
|
- Would these tests catch a regression?
|
||||||
|
- Are the assertions meaningful?
|
||||||
|
- Do tests cover the acceptance criteria?
|
||||||
|
|
||||||
|
## Review Process
|
||||||
|
|
||||||
|
1. **Understand context**: Read PR description and linked issues
|
||||||
|
2. **High-level scan**: Understand overall structure and approach
|
||||||
|
3. **Detailed review**: Go through changes file by file
|
||||||
|
4. **Consider impact**: Think about side effects and dependencies
|
||||||
|
5. **Provide feedback**: Be constructive and specific
|
||||||
|
|
||||||
|
## Writing Review Comments
|
||||||
|
|
||||||
|
### Be Constructive
|
||||||
|
- Explain *why* something is an issue
|
||||||
|
- Suggest alternatives when possible
|
||||||
|
- Distinguish between blocking issues and suggestions
|
||||||
|
|
||||||
|
### Be Specific
|
||||||
|
- Reference exact lines or code blocks
|
||||||
|
- Provide concrete examples
|
||||||
|
- Link to relevant documentation or patterns
|
||||||
|
|
||||||
|
### Be Kind
|
||||||
|
- Phrase feedback as questions when appropriate
|
||||||
|
- Acknowledge good solutions
|
||||||
|
- Remember there's a person receiving this feedback
|
||||||
|
|
||||||
|
## Verdict Criteria
|
||||||
|
|
||||||
|
### LGTM (Looks Good To Me)
|
||||||
|
- No blocking issues
|
||||||
|
- Code meets quality standards
|
||||||
|
- Tests are adequate
|
||||||
|
- Ready to merge
|
||||||
|
|
||||||
|
### Needs Changes
|
||||||
|
- Minor issues that should be addressed
|
||||||
|
- Style improvements
|
||||||
|
- Missing tests for edge cases
|
||||||
|
- Not blocking, but worth fixing
|
||||||
|
|
||||||
|
### Blocking Issues
|
||||||
|
- Security vulnerabilities
|
||||||
|
- Logic errors that would cause bugs
|
||||||
|
- Missing critical functionality
|
||||||
|
- Breaking changes without migration
|
||||||
|
|
||||||
|
## Review Comment Template
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## AI Code Review
|
||||||
|
|
||||||
|
> This is an automated review generated by the code-reviewer agent.
|
||||||
|
|
||||||
|
### Summary
|
||||||
|
[1-2 sentence overall assessment of the changes]
|
||||||
|
|
||||||
|
### Findings
|
||||||
|
|
||||||
|
#### Code Quality
|
||||||
|
- [Issue with specific file:line reference and explanation]
|
||||||
|
- [Or "Code is well-structured and readable"]
|
||||||
|
|
||||||
|
#### Potential Bugs
|
||||||
|
- [Bug risk with explanation]
|
||||||
|
- [Or "No obvious issues found"]
|
||||||
|
|
||||||
|
#### Security Concerns
|
||||||
|
- [Security issue with severity]
|
||||||
|
- [Or "No security concerns identified"]
|
||||||
|
|
||||||
|
#### Style Notes
|
||||||
|
- [Style improvement suggestion]
|
||||||
|
- [Or "Consistent with codebase conventions"]
|
||||||
|
|
||||||
|
#### Test Coverage
|
||||||
|
- [Missing test scenario]
|
||||||
|
- [Or "Tests adequately cover changes"]
|
||||||
|
|
||||||
|
### Verdict
|
||||||
|
**[LGTM / Needs Changes / Blocking Issues]**
|
||||||
|
|
||||||
|
[Brief explanation of verdict]
|
||||||
|
```
|
||||||
Reference in New Issue
Block a user