91 lines
2.5 KiB
Markdown
91 lines
2.5 KiB
Markdown
---
|
|
name: review-pr
|
|
description: >
|
|
Review a Gitea pull request. Fetches PR details, diff, and comments. Includes
|
|
both code review and software architecture review. Use when reviewing pull requests,
|
|
checking code quality, or when user says /review-pr.
|
|
model: sonnet
|
|
argument-hint: <pr-number>
|
|
user-invocable: true
|
|
---
|
|
|
|
# Review PR #$1
|
|
|
|
@~/.claude/skills/gitea/SKILL.md
|
|
@~/.claude/skills/software-architecture/SKILL.md
|
|
|
|
## 1. Gather Information
|
|
|
|
1. **View PR details** with `--comments` flag to see description, metadata, and discussion
|
|
2. **Get the diff** to review the changes:
|
|
```bash
|
|
tea pulls checkout <number>
|
|
git diff main...HEAD
|
|
```
|
|
|
|
## 2. Code Review
|
|
|
|
Review the changes and provide feedback on:
|
|
- Code quality and style
|
|
- Potential bugs or logic errors
|
|
- Test coverage
|
|
- Documentation updates
|
|
|
|
## 3. Software Architecture Review
|
|
|
|
Spawn the software-architect agent for architectural analysis:
|
|
|
|
```
|
|
Task tool with:
|
|
- subagent_type: "software-architect"
|
|
- prompt: |
|
|
ANALYSIS_TYPE: pr-review
|
|
TARGET: <pr-number>
|
|
CONTEXT: [Include the PR diff and description]
|
|
```
|
|
|
|
The architecture review checks:
|
|
- **Pattern consistency**: Changes follow existing codebase patterns
|
|
- **Dependency direction**: Dependencies flow correctly (toward domain layer)
|
|
- **Breaking changes**: API changes are flagged and justified
|
|
- **Module boundaries**: Changes respect existing package boundaries
|
|
- **Error handling**: Errors wrapped with context, proper error types used
|
|
|
|
## 4. Present Findings
|
|
|
|
Structure the review with two sections:
|
|
|
|
### Code Review
|
|
- Quality, bugs, style issues
|
|
- Test coverage gaps
|
|
- Documentation needs
|
|
|
|
### Architecture Review
|
|
- Summary of architectural concerns from agent
|
|
- Pattern violations or anti-patterns detected
|
|
- Dependency or boundary issues
|
|
- Breaking change assessment
|
|
|
|
## 5. User Actions
|
|
|
|
Ask the user what action to take:
|
|
- **Merge**: Post review summary as comment, then merge with rebase style
|
|
- **Request changes**: Leave feedback without merging
|
|
- **Comment only**: Add a comment for discussion
|
|
|
|
## Merging
|
|
|
|
Always use tea CLI for merges to preserve user attribution:
|
|
|
|
```bash
|
|
tea pulls merge <number> --style rebase
|
|
```
|
|
|
|
For review comments, use `tea comment` since `tea pulls review` is interactive-only:
|
|
|
|
```bash
|
|
tea comment <number> "<review summary>"
|
|
```
|
|
|
|
> **Warning**: Never use the Gitea API with admin credentials for user-facing operations like merging. This causes the merge to be attributed to the admin account instead of the user.
|