|
10 | 10 | "templateDe": "Wenn wir von einer \"Spezifikation\" oder \"Spec\" sprechen, meinen wir:\n- Use Cases mit Activity Diagrams (alle Pfade, nicht nur der Happy Path)\n- Akzeptanzkriterien im Gherkin-Format (Given/When/Then)", |
11 | 11 | "category": "requirements" |
12 | 12 | }, |
| 13 | + { |
| 14 | + "id": "requirements-discovery", |
| 15 | + "title": "Requirements Discovery", |
| 16 | + "titleDe": "Anforderungsermittlung", |
| 17 | + "description": "How we clarify requirements before writing specs", |
| 18 | + "descriptionDe": "Wie wir Anforderungen klären, bevor wir Specs schreiben", |
| 19 | + "anchors": ["socratic-method", "mece", "prd"], |
| 20 | + "template": "Clarify requirements using the Socratic Method:\n- Ask at most 3 questions at a time, challenge assumptions\n- Use MECE to ensure questions cover all areas without overlap\n- Keep asking until you fully understand the requirements\n- Document as a PRD (problem, goals, personas, success criteria, scope)", |
| 21 | + "templateDe": "Anforderungen mit der Sokratischen Methode klären:\n- Höchstens 3 Fragen gleichzeitig, Annahmen hinterfragen\n- MECE nutzen, um alle Bereiche überlappungsfrei abzudecken\n- Weiterfragen bis die Anforderungen vollständig verstanden sind\n- Als PRD dokumentieren (Problem, Ziele, Personas, Erfolgskriterien, Scope)", |
| 22 | + "category": "requirements" |
| 23 | + }, |
13 | 24 | { |
14 | 25 | "id": "architecture-documentation", |
15 | 26 | "title": "Architecture Documentation", |
16 | 27 | "titleDe": "Architekturdokumentation", |
17 | | - "description": "How we document architecture", |
18 | | - "descriptionDe": "Wie wir Architektur dokumentieren", |
19 | | - "anchors": ["arc42", "c4-diagrams", "adr-according-to-nygard"], |
20 | | - "template": "When we say \"architecture documentation\", we mean:\n- arc42 template with all 12 sections\n- C4 diagrams for visualization\n- ADRs according to Nygard for decisions", |
21 | | - "templateDe": "Wenn wir \"Architekturdokumentation\" sagen, meinen wir:\n- arc42-Template mit allen 12 Abschnitten\n- C4-Diagramme zur Visualisierung\n- ADRs nach Nygard für Entscheidungen", |
| 28 | + "description": "How we document architecture with ADRs and decision evaluation", |
| 29 | + "descriptionDe": "Wie wir Architektur mit ADRs und Entscheidungsbewertung dokumentieren", |
| 30 | + "anchors": ["arc42", "c4-diagrams", "adr-according-to-nygard", "pugh-matrix"], |
| 31 | + "template": "Architecture documentation follows arc42 with all 12 sections.\n- C4 diagrams (PlantUML) for visualization at four abstraction levels\n- Every architecture decision documented as an ADR according to Nygard (Context, Decision, Status, Consequences)\n- Each ADR includes a Pugh Matrix with 3-point scale (-1, 0, +1) evaluating alternatives against quality goals", |
| 32 | + "templateDe": "Architekturdokumentation folgt arc42 mit allen 12 Abschnitten.\n- C4-Diagramme (PlantUML) zur Visualisierung auf vier Abstraktionsebenen\n- Jede Architekturentscheidung als ADR nach Nygard dokumentiert (Kontext, Entscheidung, Status, Konsequenzen)\n- Jedes ADR enthält eine Pugh-Matrix mit 3-Punkt-Skala (-1, 0, +1) zur Bewertung von Alternativen gegen Qualitätsziele", |
22 | 33 | "category": "architecture" |
23 | 34 | }, |
24 | 35 | { |
|
32 | 43 | "templateDe": "An jeder Schichtgrenze:\n- Nur definierte DTOs und Contracts exponieren — niemals Domain-Entitäten\n- Explizites Mapping an jeder Nahtstelle\n- Anti-Corruption-Layer bei Integration externer Systeme\n- Abhängigkeitsrichtung zeigt nach innen (DIP)", |
33 | 44 | "category": "architecture" |
34 | 45 | }, |
| 46 | + { |
| 47 | + "id": "backlog-management", |
| 48 | + "title": "Backlog Management", |
| 49 | + "titleDe": "Backlog-Verwaltung", |
| 50 | + "description": "How we create and prioritize implementation tasks", |
| 51 | + "descriptionDe": "Wie wir Implementierungsaufgaben erstellen und priorisieren", |
| 52 | + "anchors": ["invest", "moscow"], |
| 53 | + "template": "Create EPICs and User Stories as GitHub issues from the specification.\n- User Stories follow INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable)\n- Prioritize with MoSCoW (Must/Should/Could/Won't)\n- Mark dependencies between issues\n- Groom the backlog regularly as the project evolves", |
| 54 | + "templateDe": "EPICs und User Stories als GitHub Issues aus der Spezifikation erstellen.\n- User Stories folgen den INVEST-Kriterien (Independent, Negotiable, Valuable, Estimable, Small, Testable)\n- Priorisierung mit MoSCoW (Must/Should/Could/Won't)\n- Abhängigkeiten zwischen Issues markieren\n- Backlog regelmäßig groomen", |
| 55 | + "category": "development" |
| 56 | + }, |
| 57 | + { |
| 58 | + "id": "implement-next", |
| 59 | + "title": "Implement Next", |
| 60 | + "titleDe": "Nächstes Feature", |
| 61 | + "description": "The implementation loop for each issue", |
| 62 | + "descriptionDe": "Der Implementierungs-Loop für jedes Issue", |
| 63 | + "anchors": ["tdd-london-school", "tdd-chicago-school", "definition-of-done", "conventional-commits"], |
| 64 | + "template": "For each issue:\n- Create a feature branch for the EPIC\n- Select next issue from backlog (respect dependencies)\n- Analyze and document analysis as a comment on the issue\n- Implement using TDD (London or Chicago School as appropriate)\n- Commit with Conventional Commits, reference issue number\n- Check if spec or architecture docs need updating\n- When EPIC is complete, create a Pull Request", |
| 65 | + "templateDe": "Für jedes Issue:\n- Feature-Branch für das EPIC erstellen\n- Nächstes Issue aus dem Backlog wählen (Abhängigkeiten beachten)\n- Analysieren und Analyse als Kommentar am Issue dokumentieren\n- Mit TDD implementieren (London oder Chicago School je nach Kontext)\n- Mit Conventional Commits committen, Issue-Nummer referenzieren\n- Prüfen ob Spec oder Architektur-Docs aktualisiert werden müssen\n- Wenn EPIC fertig, Pull Request erstellen", |
| 66 | + "category": "development" |
| 67 | + }, |
35 | 68 | { |
36 | 69 | "id": "code-quality", |
37 | 70 | "title": "Code Quality", |
38 | 71 | "titleDe": "Code-Qualität", |
39 | | - "description": "Our coding conventions and quality standards", |
40 | | - "descriptionDe": "Unsere Coding-Konventionen und Qualitätsstandards", |
41 | | - "anchors": ["tdd-london-school", "tdd-chicago-school", "solid-principles", "dry-principle", "kiss-principle", "conventional-commits"], |
42 | | - "template": "Our code follows:\n- TDD (London or Chicago School as appropriate)\n- SOLID principles\n- DRY, KISS\n- Conventional Commits", |
43 | | - "templateDe": "Unser Code folgt:\n- TDD (London oder Chicago School je nach Kontext)\n- SOLID-Prinzipien\n- DRY, KISS\n- Conventional Commits", |
| 72 | + "description": "Coding conventions and design principles", |
| 73 | + "descriptionDe": "Coding-Konventionen und Design-Prinzipien", |
| 74 | + "anchors": ["solid-principles", "dry-principle", "kiss-principle", "domain-driven-design"], |
| 75 | + "template": "Our code follows:\n- SOLID principles\n- DRY, KISS\n- Ubiquitous Language from Domain-Driven Design (same terms in code as in the specification)", |
| 76 | + "templateDe": "Unser Code folgt:\n- SOLID-Prinzipien\n- DRY, KISS\n- Ubiquitous Language aus Domain-Driven Design (gleiche Begriffe im Code wie in der Spezifikation)", |
44 | 77 | "category": "development" |
45 | 78 | }, |
| 79 | + { |
| 80 | + "id": "quality-review", |
| 81 | + "title": "Quality Review", |
| 82 | + "titleDe": "Qualitätsprüfung", |
| 83 | + "description": "How we review code and check for security issues", |
| 84 | + "descriptionDe": "Wie wir Code reviewen und Sicherheitsprobleme prüfen", |
| 85 | + "anchors": ["fagan-inspection", "owasp-top-10", "atam"], |
| 86 | + "template": "Quality assurance follows three layers:\n- Code review using Fagan Inspection (structured, systematic, with defined phases)\n- Security review based on OWASP Top 10\n- Architecture review using ATAM (scenario-based tradeoff analysis against quality goals)\n- Use a different AI model or fresh session for reviews to avoid blind spots", |
| 87 | + "templateDe": "Qualitätssicherung folgt drei Schichten:\n- Code-Review mit Fagan Inspection (strukturiert, systematisch, mit definierten Phasen)\n- Security-Review basierend auf OWASP Top 10\n- Architektur-Review mit ATAM (szenariobasierte Tradeoff-Analyse gegen Qualitätsziele)\n- Anderes KI-Modell oder frische Session für Reviews nutzen, um blinde Flecken zu vermeiden", |
| 88 | + "category": "quality" |
| 89 | + }, |
46 | 90 | { |
47 | 91 | "id": "documentation-style", |
48 | | - "title": "Documentation Style", |
49 | | - "titleDe": "Dokumentationsstil", |
50 | | - "description": "How we write and organize documentation", |
51 | | - "descriptionDe": "Wie wir Dokumentation schreiben und organisieren", |
52 | | - "anchors": ["plain-english-strunk-white", "gutes-deutsch-wolf-schneider", "docs-as-code", "diataxis-framework"], |
53 | | - "template": "All documentation uses:\n- Plain English according to Strunk & White (or Gutes Deutsch nach Wolf Schneider for German)\n- Docs-as-Code with AsciiDoc\n- Diataxis for document types", |
54 | | - "templateDe": "Alle Dokumentation verwendet:\n- Gutes Deutsch nach Wolf Schneider (oder Plain English nach Strunk & White für Englisch)\n- Docs-as-Code mit AsciiDoc\n- Diataxis für Dokumenttypen", |
| 92 | + "title": "Docs-as-Code", |
| 93 | + "titleDe": "Docs-as-Code", |
| 94 | + "description": "How we write and build documentation", |
| 95 | + "descriptionDe": "Wie wir Dokumentation schreiben und bauen", |
| 96 | + "anchors": ["docs-as-code", "plain-english-strunk-white", "gutes-deutsch-wolf-schneider"], |
| 97 | + "template": "Documentation follows Docs-as-Code according to Ralf D. Müller:\n- AsciiDoc as format, PlantUML for inline diagrams, built by docToolchain\n- Version-controlled, peer-reviewed, and built automatically\n- Plain English according to Strunk & White (or Gutes Deutsch nach Wolf Schneider)", |
| 98 | + "templateDe": "Dokumentation folgt Docs-as-Code nach Ralf D. Müller:\n- AsciiDoc als Format, PlantUML für Inline-Diagramme, gebaut von docToolchain\n- Versioniert, reviewt und automatisch gebaut\n- Gutes Deutsch nach Wolf Schneider (oder Plain English nach Strunk & White)", |
55 | 99 | "category": "documentation" |
56 | 100 | }, |
57 | 101 | { |
|
0 commit comments