75 lines
2.8 KiB
Markdown
75 lines
2.8 KiB
Markdown
---
|
|
name: review-pr
|
|
description: Multi-persona PR review. Each persona from .claude/personas/ reviews the PR and posts their findings as a separate Gitea comment.
|
|
---
|
|
|
|
# Multi-Persona PR Review
|
|
|
|
You will perform a thorough multi-persona code review of the given PR URL and post each persona's findings as a **separate comment** on the PR.
|
|
|
|
## Argument
|
|
|
|
The user provides a Gitea PR URL, e.g.:
|
|
`http://heim-nas:3005/marcel/familienarchiv/pulls/160`
|
|
|
|
Parse it to extract:
|
|
- `owner` — e.g. `marcel`
|
|
- `repo` — e.g. `familienarchiv`
|
|
- `pull_number` — e.g. `160`
|
|
|
|
## Step 1 — Gather PR Context
|
|
|
|
Use the Gitea MCP tools to collect:
|
|
1. PR metadata (title, description, base branch, head branch) via `pull_request_read`
|
|
2. The list of changed files via `get_dir_contents` or the PR files endpoint
|
|
3. The full diff / file contents of every changed file — read each file at the head commit using `get_file_contents`
|
|
|
|
Read ALL changed files completely before starting any review. Do not skip files.
|
|
|
|
## Step 2 — Read Every Persona
|
|
|
|
Read all six persona files from `.claude/personas/`:
|
|
- `developer.md` → Felix Brandt
|
|
- `architect.md` → architect persona
|
|
- `tester.md` → tester persona
|
|
- `security_expert.md` → security persona
|
|
- `ui_expert.md` → UI/UX persona
|
|
- `devops.md` → DevOps persona
|
|
|
|
## Step 3 — Write Each Review
|
|
|
|
For each persona, fully adopt their identity, priorities, and review lens as described in their persona file. Write a review that:
|
|
|
|
- Opens with a one-line verdict: **✅ Approved**, **⚠️ Approved with concerns**, or **🚫 Changes requested**
|
|
- Lists concrete findings with file paths and line references where relevant
|
|
- Distinguishes blockers (must fix) from suggestions (nice to have)
|
|
- Uses the persona's voice and priorities (e.g. Felix cares about TDD and clean code; the security expert checks for injection, auth, and data exposure; the architect checks layer boundaries and coupling)
|
|
- Stays focused — only comment on what the persona would actually care about
|
|
|
|
Format each comment in Markdown with a persona header, e.g.:
|
|
|
|
```
|
|
## 👨💻 Felix Brandt — Senior Fullstack Developer
|
|
|
|
**Verdict: ⚠️ Approved with concerns**
|
|
|
|
### Blockers
|
|
...
|
|
|
|
### Suggestions
|
|
...
|
|
```
|
|
|
|
## Step 4 — Post Comments
|
|
|
|
Post each persona's review as a **separate comment** on the PR using the Gitea MCP `issue_write` tool (issues and PRs share the comment API in Gitea).
|
|
|
|
Post all six comments. Do not skip any persona even if their domain has nothing to flag — in that case write a brief "LGTM" with a short explanation of what they checked.
|
|
|
|
## Step 5 — Report Back
|
|
|
|
After all comments are posted, summarize to the user:
|
|
- Which personas posted comments
|
|
- The overall verdict across all personas (worst-case wins: if any said "Changes requested", the overall is "Changes requested")
|
|
- A bullet list of the top blockers found (if any)
|