76 lines
3.2 KiB
Markdown
76 lines
3.2 KiB
Markdown
---
|
|
name: review-issue
|
|
description: Multi-persona feature issue review. Each persona from .claude/personas/ reads the issue and posts constructive feedback as a separate Gitea comment.
|
|
---
|
|
|
|
# Multi-Persona Feature Issue Review
|
|
|
|
You will perform a thorough multi-persona review of the given Gitea issue URL and post each persona's constructive feedback as a **separate comment** on the issue.
|
|
|
|
Personas give **advisory input only** — no blocking, no verdicts. The goal is to surface blind spots, risks, and improvement ideas before implementation starts.
|
|
|
|
## Argument
|
|
|
|
The user provides a Gitea issue URL, e.g.:
|
|
`http://heim-nas:3005/marcel/familienarchiv/issues/161`
|
|
|
|
Parse it to extract:
|
|
- `owner` — e.g. `marcel`
|
|
- `repo` — e.g. `familienarchiv`
|
|
- `issue_number` — e.g. `161`
|
|
|
|
## Step 1 — Gather Issue Context
|
|
|
|
Use the Gitea MCP tools to collect:
|
|
1. The full issue (title, body, labels, milestone, assignees) via `issue_read`
|
|
2. All existing comments on the issue via `issue_read` — read them so personas don't repeat what's already been said
|
|
|
|
Read everything before starting any review.
|
|
|
|
## 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 thinking style as described in their persona file. Write feedback that:
|
|
|
|
- Is **constructive and forward-looking** — no blockers, no verdicts, no approval stamps
|
|
- Asks clarifying questions the persona would genuinely want answered before or during implementation
|
|
- Points out risks, edge cases, or gaps the persona sees from their domain
|
|
- Offers concrete suggestions or alternative approaches where relevant
|
|
- References the issue text specifically — don't write generic advice
|
|
- Stays focused on what the persona would actually care about (e.g. Felix asks about test strategy and naming; the architect asks about layer boundaries and coupling; the security expert asks about auth, input validation, and data exposure; the tester asks about acceptance criteria and edge cases; the UI expert asks about interaction patterns and accessibility; DevOps asks about deployment, config, and observability)
|
|
|
|
Format each comment in Markdown with a persona header, e.g.:
|
|
|
|
```
|
|
## 👨💻 Felix Brandt — Senior Fullstack Developer
|
|
|
|
### Questions & Observations
|
|
...
|
|
|
|
### Suggestions
|
|
...
|
|
```
|
|
|
|
Keep each comment focused and scannable. Use bullet points. Avoid walls of text.
|
|
|
|
## Step 4 — Post Comments
|
|
|
|
Post each persona's feedback as a **separate comment** on the issue using the Gitea MCP `issue_write` tool.
|
|
|
|
Post all six comments. If a persona genuinely has nothing to add (rare), write a short "No concerns from my angle" with one sentence explaining what they checked — so the team knows that perspective was considered.
|
|
|
|
## Step 5 — Report Back
|
|
|
|
After all comments are posted, tell the user:
|
|
- Which personas posted feedback
|
|
- A brief summary of the most important cross-cutting themes (questions or risks that multiple personas flagged)
|