fa6677a7c5
review-issue becomes the SDD spec-review gate (adds the requirements engineer, pairs each .claude persona identity with its .specify checklist, EARS/REQ-NNN aware). review-pr verifies the diff against the constitution and the spec's REQ-NNN traceability. implement reads the spec artifacts, plans from tasks.md, ties tasks to REQ-NNN, and keeps the RTM and generated API types in sync. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
104 lines
5.1 KiB
Markdown
104 lines
5.1 KiB
Markdown
---
|
|
name: review-issue
|
|
description: 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](../../../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`](../../../.specify/constitution.md) — the non-negotiable rules
|
|
- [`.specify/AGENTS.md`](../../../.specify/AGENTS.md) — stack, constraints, workflow
|
|
- [`.specify/templates/feature-spec.md`](../../../.specify/templates/feature-spec.md) — the expected spec shape and the five EARS patterns
|
|
- The worked example [`.specify/features/_example/spec.md`](../../../.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`](../../../.specify/rtm.md)
|