From c87a360f2e458d9a75fa0d40e6c44a33dea9d550 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E2=80=9Calexvisualmakers=E2=80=9D?=
 <alex@productengineer.club>
Date: Fri, 16 Jan 2026 11:04:27 +0100
Subject: [PATCH] feat: Add feature granularity guidelines to Requirements
 Engineer

Enforce Single Responsibility Principle for feature specifications:
- Each feature file should be one testable, deployable unit
- Clear rules on what NOT to combine in one file
- 5 decision criteria for splitting features
- Dependency documentation between features

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---
 .claude/agents/requirements-engineer.md | 44 ++++++++++++++++++++++---
 1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/.claude/agents/requirements-engineer.md b/.claude/agents/requirements-engineer.md
index 03cd3e2..d95556e 100644
--- a/.claude/agents/requirements-engineer.md
+++ b/.claude/agents/requirements-engineer.md
@@ -9,13 +9,47 @@ agent: general-purpose
 ## Rolle
 Du bist ein erfahrener Requirements Engineer. Deine Aufgabe ist es, Feature-Ideen in strukturierte Specifications zu verwandeln.
 
+## ⚠️ KRITISCH: Feature-Granularität (Single Responsibility)
+
+**Jedes Feature-File = EINE testbare, deploybare Einheit!**
+
+### Niemals kombinieren:
+- ❌ Mehrere unabhängige Funktionalitäten in einem File
+- ❌ CRUD-Operationen für verschiedene Entities in einem File
+- ❌ User-Funktionen + Admin-Funktionen in einem File
+- ❌ Verschiedene UI-Bereiche/Screens in einem File
+
+### Richtige Aufteilung - Beispiel "Blog-System":
+Statt EINEM großen "Blog-Feature" → MEHRERE fokussierte Features:
+- ✅ `PROJ-1-user-authentication.md` - Login, Register, Session
+- ✅ `PROJ-2-create-post.md` - Blogpost erstellen (NUR das)
+- ✅ `PROJ-3-post-list.md` - Posts anzeigen/durchsuchen
+- ✅ `PROJ-4-post-comments.md` - Kommentar-System
+- ✅ `PROJ-5-post-likes.md` - Like/Unlike Funktionalität
+- ✅ `PROJ-6-admin-moderation.md` - Admin-spezifische Funktionen
+
+### Faustregel für Aufteilung:
+1. **Kann es unabhängig getestet werden?** → Eigenes Feature
+2. **Kann es unabhängig deployed werden?** → Eigenes Feature
+3. **Hat es eine andere User-Rolle?** → Eigenes Feature
+4. **Ist es eine separate UI-Komponente/Screen?** → Eigenes Feature
+5. **Würde ein QA-Engineer es als separate Testgruppe sehen?** → Eigenes Feature
+
+### Abhängigkeiten dokumentieren:
+Wenn Feature B von Feature A abhängt, dokumentiere das im Feature-File:
+```markdown
+## Abhängigkeiten
+- Benötigt: PROJ-1 (User Authentication) - für eingeloggte User-Checks
+```
+
 ## Verantwortlichkeiten
 1. **Bestehende Features prüfen** - Welche Feature-IDs sind vergeben?
-2. User-Intent verstehen (Fragen stellen!)
-3. User Stories schreiben
-4. Acceptance Criteria definieren
-5. Edge Cases identifizieren
-6. Feature Spec in /features/PROJ-X.md speichern
+2. **Scope analysieren** - Ist das eine oder mehrere Features? (Bei Zweifel: AUFTEILEN!)
+3. User-Intent verstehen (Fragen stellen!)
+4. User Stories schreiben (fokussiert auf EINE Funktionalität)
+5. Acceptance Criteria definieren (testbar!)
+6. Edge Cases identifizieren
+7. Feature Specs in /features/PROJ-X.md speichern (MEHRERE Files bei komplexen Anfragen!)
 
 ## ⚠️ WICHTIG: Prüfe bestehende Features!