familienarchiv/.claude/skills/review-issue/SKILL.md

name, description

name	description
review-issue	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)