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

name, description

name	description
review-issue	Multi-persona SDD spec review of a Gitea feature issue. Each persona pairs its .claude/personas/ identity with its .specify/personas/ checklist, walks it PASS/FAIL/QUESTION against the EARS requirements, and posts findings as a separate Gitea comment before implementation starts.

Multi-Persona Spec Review (SDD)

You will perform a thorough multi-persona spec review of the given Gitea feature issue and post each persona's findings as a separate comment on the issue. This is the SDD spec-review gate (step 4 of SPEC_DRIVEN_DEVELOPMENT.md): the goal is to catch ambiguity, missing requirements, and blind spots before any code is written, while the cost of change is a sentence edit.

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 0 — Load the SDD ground truth

Before reading the issue, read the rules every persona reviews against:

• .specify/constitution.md — the non-negotiable rules
• .specify/AGENTS.md — stack, constraints, workflow
• .specify/templates/feature-spec.md — the expected spec shape and the five EARS patterns
• The worked example .specify/features/_example/spec.md — what "good" looks like

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 — read them so personas don't repeat what's already been said

Read everything before starting any review.

Step 2 — Read every persona (identity + checklist)

Each persona is its character identity (.claude/personas/) plus its SDD spec-review checklist (.specify/personas/). Adopt the voice from the former; gate the spec with the latter.

Persona	Identity (.claude/personas/)	Checklist (.specify/personas/)
Requirements Engineer	req_engineer.md	requirements-engineer.md
Developer (Felix Brandt)	developer.md	developer.md
Security (Nora "NullX" Steiner)	security_expert.md	security.md
DevOps	devops.md	devops.md
UI/UX	ui_expert.md	ui-ux.md
Architect	architect.md	architect.md

The tester lens (acceptance-criteria quality, edge cases) is carried by the Requirements Engineer checklist (testable, measurable criteria) — no separate tester comment at spec time.

Step 3 — Run each checklist against the spec

For each persona, walk every item in its .specify/personas/ checklist and assign PASS / FAIL / QUESTION, judged against the constitution and the issue text:

• EARS-aware: verify each requirement uses one of the five EARS patterns and carries a REQ-NNN id. The Requirements Engineer leads here; every persona flags missing Unwanted-behavior (If …) clauses in their domain (Security especially — a mutating endpoint with no If clause for unauthenticated/unauthorized access is an automatic FAIL).
• If the issue is not yet an SDD spec (free-prose, no REQ-NNN, missing sections), the Requirements Engineer's primary finding is to restructure it using the feature-spec template, and other personas review what they can while noting the gap.
• Reference the issue text specifically — quote the requirement or the missing section. No generic advice.

Step 4 — Write and post each comment

Each persona posts a separate comment via the Gitea MCP issue_write tool, in the format its checklist's "Output format" section defines — a header, the checklist table, and a verdict:

### 🔐 Security — Spec Review

| # | Item | Status | Note |
|---|------|--------|------|
| 1 | All mutating endpoints have authn + authz `If` clauses | FAIL | REQ-004 POST has no 401 clause (CWE-...) |
| 2 | ... | PASS | |

**Verdict: CHANGES REQUESTED** — blocking FAIL: #1. Resolve before implementation.

Post all six comments. If a persona's checklist is entirely PASS, still post the table and a Verdict: APPROVE so the team knows the perspective was applied. Keep comments scannable.

These verdicts are a pre-implementation gate, not a PR merge gate: a FAIL means the issue/spec must be amended (per SDD step 5) before work starts. Fold the agreed fixes into the issue description (the issue body is the source of truth), then re-run this review with clean context rather than leaving a long comment thread.

Step 5 — Report back

After all comments are posted, tell the user:

• Each persona's verdict (APPROVE / CHANGES REQUESTED)
• The consolidated list of blocking FAILs (these must be resolved before implementation)
• Cross-cutting themes multiple personas flagged
• Whether the issue is a well-formed SDD spec yet, or needs restructuring first
• A reminder to mirror the agreed REQ-NNN rows into .specify/rtm.md