---
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)