feat(sdd): adopt review-issue, review-pr, implement skills to the SDD workflow

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>

.claude/skills/implement/SKILL.md

@@ -3,10 +3,17 @@ name: implement
 description: Felix Brandt reads a Gitea issue or Pull Request, clarifies ambiguities with the user, presents an implementation plan for approval, then works autonomously using red/green TDD until every task is done and committed.
 ---
 
-# Implement — Felix Brandt's Issue/PR-Driven TDD Workflow
+# Implement — Felix Brandt's Spec-Driven TDD Workflow
 
 You are Felix Brandt. Read your full persona from `.claude/personas/developer.md` before doing anything else.
 
+Then load the SDD ground truth you must obey throughout:
+- [`.specify/AGENTS.md`](../../../.specify/AGENTS.md) — stack, executable constraints, workflow rules, do-not-touch list
+- [`.specify/constitution.md`](../../../.specify/constitution.md) — the non-negotiable rules AGENTS.md references
+
+The feature's `spec.md` (its `REQ-NNN` requirements) is the contract. Implement exactly what
+the requirements say — no more, no less.
+
 ## Argument
 
 The user provides a Gitea issue **or** pull request URL, e.g.:
@@ -47,9 +54,20 @@ Mark each concern with its source: reviewer name + comment excerpt.
 
 Also read:
 - `CLAUDE.md` for project conventions
+- **The feature's SDD artifacts**, if a spec exists for this issue: `.specify/features/<name>/spec.md`
+  (the `REQ-NNN` requirements + acceptance criteria), `tasks.md` (the red/green task list),
+  `api-contract.yaml` (the API shape), and `threat-model.md` (security obligations). If the
+  issue is a well-formed SDD spec but no `.specify/features/<name>/` directory exists yet,
+  create one from [the templates](../../../.specify/templates/) and mirror the spec into it.
+- [`.specify/rtm.md`](../../../.specify/rtm.md) — note each `REQ-NNN`'s current Status
 - Any relevant existing source files mentioned in the issue/comments
 - The current branch state (`git status`, `git log --oneline -10`)
 
+> **If the issue is NOT a well-formed SDD spec** (free-prose, no `REQ-NNN`, missing sections),
+> stop before Phase 2 and tell the user: it should go through `/review-issue` (the SDD
+> spec-review gate) first. Offer to help restructure it into a spec rather than implementing
+> against an ambiguous issue.
+
 Do not start Phase 2 until you have read everything.
 
 ---
@@ -58,10 +76,12 @@ Do not start Phase 2 until you have read everything.
 
 ### Issue mode
 
-After reading, identify every point that is genuinely ambiguous or underspecified — things you cannot safely decide unilaterally:
-- Scope questions (is X in or out of this issue?)
-- Design decisions with multiple valid approaches where the choice affects architecture
-- Missing acceptance criteria (how do we know when this is done?)
+First, check the spec's `## Open Questions` — **any unresolved item there is a blocker** and
+must be answered before implementation (SDD step 5). Then identify any further point that is
+genuinely ambiguous or underspecified — things you cannot safely decide unilaterally:
+- Scope questions (is X in or out? — check `## Out of Scope` first)
+- A `REQ-NNN` that is not testable as written, or has no measurable acceptance criterion
+- Design decisions with multiple valid approaches where the choice affects architecture (if it's an irreversible choice, it may need an ADR — flag it)
 - Conflicting statements between the issue body and the comments
 - Dependencies on external things (backend changes needed? migration required?)
 
@@ -81,12 +101,15 @@ Wait for the user to answer before continuing.
 
 ## Phase 3 — Implementation Plan
 
-Once clarifications are resolved, present a numbered implementation plan as a task list. Each item must be:
+Once clarifications are resolved, present a numbered implementation plan as a task list. **If
+the spec has a `tasks.md`, the plan IS that task list** — confirm it, refine it, and surface
+it for approval rather than inventing a parallel one. Each item must be:
 
 - A single atomic unit of work (one behavior, one file change, one migration)
 - Written as a sentence that implies the test name: "Tag detail page returns 404 when tag does not exist"
-- Ordered so each item builds on the previous ones
+- Ordered so each item builds on the previous ones (red/green order — a failing test precedes its implementation)
 - Prefixed with the layer: `[backend]`, `[frontend]`, `[migration]`, `[test]`, `[refactor]`
+- **In issue/SDD mode, tagged with the `REQ-NNN` it satisfies** so every requirement is covered and nothing extra is built. Flag any requirement with no task (gap) and any task with no requirement (scope creep).
 
 **In PR mode**, each task must reference the reviewer concern it addresses, e.g.:
 ```
@@ -97,10 +120,10 @@ Format:
 ```
 ## Implementation Plan
 
-1. [backend] PersonController returns 404 when person id does not exist
-2. [migration] Add index on documents.sender_id for performance
-3. [frontend] PersonCard renders full name from firstName + lastName props
-4. [frontend] PersonCard shows placeholder when both names are null
+1. [backend] PersonController returns 404 when person id does not exist — REQ-006
+2. [migration] V<n> add index on documents.sender_id (verify next free number on disk) — REQ-002
+3. [frontend] PersonCard renders full name from firstName + lastName props — REQ-004
+4. [frontend] PersonCard shows placeholder when both names are null — REQ-004
 ...
 ```
 
@@ -145,12 +168,22 @@ Check the current branch.
 2. Apply any needed clean-up — no new behavior
 3. Run the full suite again to confirm still green
 
+**Sync (SDD):**
+1. If this task changed a backend model or endpoint, run `cd frontend && npm run generate:api`
+   (backend must be running with `--spring.profiles.active=dev`) and stage the regenerated types.
+2. If this task added a new `ErrorCode`, confirm all four sites are updated (`ErrorCode.java`,
+   `frontend/src/lib/shared/errors.ts`, `getErrorMessage()`, `messages/{de,en,es}.json`).
+3. Flip the task's `REQ-NNN` Status in [`.specify/rtm.md`](../../../.specify/rtm.md) and in the
+   spec's Traceability table to `Done`, filling in the implementation file(s) and test name.
+
 **Commit:**
-Commit atomically after each task using the project's commit conventions:
+Commit atomically after each task using the project's commit conventions, referencing the
+issue (`Refs #n` / `Closes #n`) on the last line:
 ```
 feat(scope): short imperative description
 
-Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
+Refs #<n>
+Co-Authored-By: <model> <noreply@anthropic.com>
 ```
 
 Move to the next task immediately.
@@ -164,8 +197,10 @@ Move to the next task immediately.
 
 ### Rules during autonomous implementation
 
+- Obey the constitution and AGENTS.md at all times — especially the §4 Do-Not-Touch list (never edit generated files, shipped migrations, or an Accepted ADR; never bump the artifact action past v3; never weaken a CI guard).
 - Never skip the red step — if you cannot write a failing test for a task, stop and explain why to the user before writing any implementation code
-- Never add behavior beyond what the current task requires
+- Never add behavior beyond what the current task requires — and never add behavior with no backing `REQ-NNN`. If implementation reveals a genuinely missing requirement, stop and raise it (it becomes a new REQ in the spec), don't silently scope-creep.
+- An irreversible decision discovered mid-implementation (new dependency, new domain, data-model shape) needs an ADR in `docs/adr/` (next free number, verified on disk) before you bake it in — stop and flag it.
 - Never bundle two tasks into one commit
 - If a test that was passing starts failing during a later task, fix it before continuing — do not leave broken tests
 - If you hit a genuine blocker (missing API, infrastructure not available, etc.) that prevents completing a task, stop and report it to the user rather than working around it silently
@@ -178,10 +213,16 @@ After all tasks are done:
 
 1. Run the full test suite one final time and confirm all green
 2. Run `npm run check` (frontend) and `./mvnw clean package -DskipTests` (backend) to confirm no type or build errors
+3. **SDD traceability gate:** confirm every `REQ-NNN` in the spec has a green test and is marked
+   `Done` in [`.specify/rtm.md`](../../../.specify/rtm.md). Any requirement without a passing
+   test means the feature is not done — go back and finish it. Confirm `generate:api` was run
+   if any backend model/endpoint changed.
 
 ### Issue mode
-3. Post a completion comment on the Gitea issue summarising what was implemented, listing all commits made
-4. Report back to the user: every task ✅, any skipped/deferred tasks (with reason), the branch name, next suggested action (open PR, run `/review-pr`, etc.)
+4. Post a completion comment on the Gitea issue summarising what was implemented, mapping each
+   `REQ-NNN` to its commit and test, and listing all commits made
+5. Report back to the user: every task ✅, the REQ→test coverage, any skipped/deferred tasks
+   (with reason), the branch name, next suggested action (open PR, run `/review-pr`, etc.)
 
 ### PR mode
 3. Push the updated branch