LLM-Coding · rdmueller · Apr 12, 2026 · Apr 12, 2026
diff --git a/docs/all-anchors.adoc b/docs/all-anchors.adoc
@@ -9,6 +9,8 @@ include::about.adoc[leveloffset=+1]
 
 == Communication & Presentation
 
+include::anchors/4mat.adoc[leveloffset=+2]
+
 include::anchors/bluf.adoc[leveloffset=+2]
 
 include::anchors/gutes-deutsch-wolf-schneider.adoc[leveloffset=+2]
@@ -45,6 +47,8 @@ include::anchors/three-act-structure.adoc[leveloffset=+2]
 
 == Design Principles & Patterns
 
+include::anchors/cohesion-criteria.adoc[leveloffset=+2]
+
 include::anchors/crc-cards.adoc[leveloffset=+2]
 
 include::anchors/fowler-patterns.adoc[leveloffset=+2]
@@ -141,6 +145,10 @@ include::anchors/semantic-versioning.adoc[leveloffset=+2]
 
 include::anchors/sota.adoc[leveloffset=+2]
 
+include::anchors/spike-solution.adoc[leveloffset=+2]
+
+include::anchors/thin-vertical-slice.adoc[leveloffset=+2]
+
 include::anchors/timtowtdi.adoc[leveloffset=+2]
 
 <<<
@@ -235,8 +243,12 @@ include::anchors/lasr.adoc[leveloffset=+2]
 
 include::anchors/madr.adoc[leveloffset=+2]
 
+include::anchors/tracer-bullet.adoc[leveloffset=+2]
+
 include::anchors/vertical-slice-architecture.adoc[leveloffset=+2]
 
+include::anchors/walking-skeleton.adoc[leveloffset=+2]
+
 <<<
 
 == Statistical Methods & Process Monitoring
@@ -257,6 +269,8 @@ include::anchors/impact-mapping.adoc[leveloffset=+2]
 
 include::anchors/jobs-to-be-done.adoc[leveloffset=+2]
 
+include::anchors/mvp.adoc[leveloffset=+2]
+
 include::anchors/pert.adoc[leveloffset=+2]
 
 include::anchors/pugh-matrix.adoc[leveloffset=+2]
@@ -287,6 +301,8 @@ include::anchors/owasp-top-10.adoc[leveloffset=+2]
 
 include::anchors/property-based-testing.adoc[leveloffset=+2]
 
+include::anchors/red-green-tdd.adoc[leveloffset=+2]
+
 include::anchors/stride.adoc[leveloffset=+2]
 
 include::anchors/tdd-chicago-school.adoc[leveloffset=+2]

diff --git a/docs/anchors/4mat.adoc b/docs/anchors/4mat.adoc
@@ -0,0 +1,50 @@
+= 4MAT
+:categories: communication-presentation
+:roles: educator, consultant, technical-writer, team-lead
+:related: pyramid-principle, feynman-technique, diataxis-framework
+:proponents: Bernice McCarthy
+:tags: learning-cycle, didactics, presentation, teaching, communication
+:tier: 3
+
+[%collapsible]
+====
+Full Name:: 4MAT System of Instruction
+
+Also known as:: 4MAT Learning Cycle, McCarthy's 4MAT
+
+[discrete]
+== *Core Concepts*:
+
+Why:: Establish *relevance and motivation* first. Why should the audience care? Connect the topic to their experience, problems, or goals before introducing new information.
+
+What:: Present the *facts, concepts, and structure*. The core content — definitions, models, theory, how the pieces fit together.
+
+How:: Show *practical application*. Demonstrate usage, walk through examples, let the audience try it hands-on. Translate theory into skill.
+
+What If:: Explore *extension, variation, and transfer*. What happens at the edges? How does this apply to new situations? Encourage creative application and critical questioning.
+
+Four-quadrant cycle:: The order matters — why before what prevents "so what?" disengagement; how before what-if prevents premature abstraction.
+
+Left-right brain modes:: Each quadrant alternates between reflective observation and active experimentation, engaging different cognitive styles in one flow.
+
+Four learner types:: Innovative (Why), Analytic (What), Common Sense (How), Dynamic (What If) — every presentation serves all four instead of only the "analytic learner" that default lecture formats assume.
+
+
+Key Proponents:: Bernice McCarthy ("The 4MAT System: Teaching to Learning Styles with Right/Left Mode Techniques", 1980; "About Learning", 1996)
+
+[discrete]
+== *When to Use*:
+
+* Structuring training sessions, workshops, or technical presentations
+* Writing tutorials, explainers, or onboarding documentation
+* Designing conference talks that engage both practitioners and theorists
+* Planning educational content across the motivation-to-mastery arc
+* LLM prompting for instructional material: "Explain X using the 4MAT cycle"
+
+[discrete]
+== *Related Anchors*:
+
+* <<pyramid-principle,Pyramid Principle>> - Top-down structure for written communication; complements 4MAT which is experience-first
+* <<feynman-technique,Feynman Technique>> - Self-directed learning; 4MAT is teacher-directed instructional design
+* <<diataxis-framework,Diátaxis Framework>> - Documentation types (tutorial/how-to/reference/explanation) map loosely to 4MAT quadrants
+====
diff --git a/docs/anchors/4mat.de.adoc b/docs/anchors/4mat.de.adoc
@@ -0,0 +1,50 @@
+= 4MAT
+:categories: communication-presentation
+:roles: educator, consultant, technical-writer, team-lead
+:related: pyramid-principle, feynman-technique, diataxis-framework
+:proponents: Bernice McCarthy
+:tags: learning-cycle, didactics, presentation, teaching, communication
+:tier: 3
+
+[%collapsible]
+====
+Vollständiger Name:: 4MAT System of Instruction
+
+Auch bekannt als:: 4MAT Lernzyklus, McCarthys 4MAT
+
+[discrete]
+== *Kernkonzepte*:
+
+Warum:: Etabliere zuerst *Relevanz und Motivation*. Warum sollte sich das Publikum dafür interessieren? Verbinde das Thema mit seinen Erfahrungen, Problemen oder Zielen, bevor neue Informationen eingeführt werden.
+
+Was:: Präsentiere *Fakten, Konzepte und Struktur*. Der inhaltliche Kern — Definitionen, Modelle, Theorie, wie die Teile zusammenpassen.
+
+Wie:: Zeige *praktische Anwendung*. Demonstriere die Nutzung, gehe Beispiele durch, lass das Publikum selbst ausprobieren. Übersetze Theorie in Fertigkeit.
+
+Was wäre wenn:: Erkunde *Erweiterung, Variation und Transfer*. Was passiert an den Rändern? Wie lässt sich das auf neue Situationen übertragen? Ermutige kreative Anwendung und kritisches Hinterfragen.
+
+Vier-Quadranten-Zyklus:: Die Reihenfolge ist wichtig — Warum vor Was verhindert "Na und?"-Desinteresse; Wie vor Was-wäre-wenn verhindert verfrühte Abstraktion.
+
+Links-rechts-Hirn-Modi:: Jeder Quadrant wechselt zwischen reflektierender Beobachtung und aktivem Experimentieren und engagiert so verschiedene kognitive Stile in einem Fluss.
+
+Vier Lernertypen:: Innovativ (Warum), Analytisch (Was), Pragmatisch (Wie), Dynamisch (Was wäre wenn) — jede Präsentation bedient alle vier, statt nur den "analytischen Lerner" anzusprechen, den klassische Vortragsformate voraussetzen.
+
+
+Schlüsselvertreter:: Bernice McCarthy ("The 4MAT System: Teaching to Learning Styles with Right/Left Mode Techniques", 1980; "About Learning", 1996)
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Strukturierung von Trainings, Workshops oder technischen Präsentationen
+* Verfassen von Tutorials, Erklärungen oder Onboarding-Dokumentation
+* Design von Konferenzvorträgen, die sowohl Praktiker als auch Theoretiker ansprechen
+* Planung von Bildungsinhalten entlang des Motivations-zu-Meisterschaft-Bogens
+* LLM-Prompting für Lehrmaterialien: "Erkläre X nach dem 4MAT-Zyklus"
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<pyramid-principle,Pyramid Principle>> - Top-down-Struktur für schriftliche Kommunikation; ergänzt 4MAT, das erfahrungsorientiert beginnt
+* <<feynman-technique,Feynman Technique>> - Selbstgesteuertes Lernen; 4MAT ist lehrergesteuertes Instruktionsdesign
+* <<diataxis-framework,Diátaxis Framework>> - Dokumentationstypen (Tutorial/How-to/Reference/Explanation) entsprechen grob den 4MAT-Quadranten
+====
diff --git a/docs/anchors/mvp.adoc b/docs/anchors/mvp.adoc
@@ -0,0 +1,53 @@
+= Minimum Viable Product (MVP)
+:categories: strategic-planning
+:roles: product-owner, team-lead, consultant
+:related: jobs-to-be-done, impact-mapping, user-story-mapping, walking-skeleton
+:proponents: Eric Ries, Frank Robinson
+:tags: lean-startup, validated-learning, hypothesis-testing, product, mvp
+:tier: 3
+
+[%collapsible]
+====
+Full Name:: Minimum Viable Product
+
+Also known as:: MVP, Lean Startup MVP
+
+[discrete]
+== *Core Concepts*:
+
+Smallest thing that tests a hypothesis:: An MVP is the minimum product that allows a team to learn whether a specific hypothesis about user needs is valid — with the least amount of effort.
+
+Validated learning is the output:: The defining output is not a feature set, not revenue, not users — it is *learning*. "Did we learn whether our hypothesis is true?" is the only success criterion.
+
+One hypothesis at a time:: An MVP targets a single, falsifiable hypothesis ("users will pay for X", "users need feature Y more than feature Z"). Bundling hypotheses into one MVP makes the learning ambiguous.
+
+Minimum means minimum:: If a hand-drawn mockup, a landing page, or a concierge service can test the hypothesis, that *is* the MVP. Code is often not required. The "P" stands for product, but the product can be an illusion.
+
+Build-measure-learn loop:: The MVP is the first turn of a tight feedback cycle: build a minimal thing, measure how real users respond, learn from the data, then decide whether to pivot or persevere.
+
+Not a small v1:: A common misuse is calling the first release of a polished product "the MVP". A real MVP would be embarrassing to ship in production — its job is learning, not market entry.
+
+Pivot or persevere:: The MVP gives you the evidence to choose: continue in the same direction (persevere) or change course based on what you learned (pivot).
+
+Distinct from Walking Skeleton:: A Walking Skeleton validates *architecture*; an MVP validates *market demand*. You can have one without the other.
+
+
+Key Proponents:: Eric Ries ("The Lean Startup", 2011); Frank Robinson coined the term in 2001
+
+[discrete]
+== *When to Use*:
+
+* Validating whether a new product or feature solves a real user problem before investing in full development
+* Testing pricing, positioning, or target-segment hypotheses with minimal risk
+* Early-stage startups with limited runway who cannot afford to build the wrong thing
+* Internal product experimentation where feature ideas need evidence before prioritization
+* LLM prompting: "design an MVP for X" signals *test the hypothesis, don't ship a complete product*
+
+[discrete]
+== *Related Anchors*:
+
+* <<jobs-to-be-done,Jobs to be Done>> - Framework for articulating the user need an MVP is trying to validate
+* <<impact-mapping,Impact Mapping>> - Technique for aligning MVP scope with business outcomes
+* <<user-story-mapping,User Story Mapping>> - Visual tool for identifying the minimum set of stories for an MVP
+* <<walking-skeleton,Walking Skeleton>> - Architectural counterpart; validates structure rather than market demand
+====
diff --git a/docs/anchors/mvp.de.adoc b/docs/anchors/mvp.de.adoc
@@ -0,0 +1,53 @@
+= Minimum Viable Product (MVP)
+:categories: strategic-planning
+:roles: product-owner, team-lead, consultant
+:related: jobs-to-be-done, impact-mapping, user-story-mapping, walking-skeleton
+:proponents: Eric Ries, Frank Robinson
+:tags: lean-startup, validated-learning, hypothesis-testing, product, mvp
+:tier: 3
+
+[%collapsible]
+====
+Vollständiger Name:: Minimum Viable Product
+
+Auch bekannt als:: MVP, Lean-Startup MVP
+
+[discrete]
+== *Kernkonzepte*:
+
+Das Kleinste, das eine Hypothese testet:: Ein MVP ist das minimale Produkt, das einem Team erlaubt zu lernen, ob eine spezifische Hypothese über Benutzerbedürfnisse valide ist — mit dem geringstmöglichen Aufwand.
+
+Validiertes Lernen ist das Ergebnis:: Das definierende Ergebnis ist kein Feature-Set, kein Umsatz, keine Benutzer — es ist *Lernen*. "Haben wir gelernt, ob unsere Hypothese stimmt?" ist das einzige Erfolgskriterium.
+
+Eine Hypothese nach der anderen:: Ein MVP zielt auf eine einzige, falsifizierbare Hypothese ("Benutzer zahlen für X", "Benutzer brauchen Feature Y mehr als Feature Z"). Mehrere Hypothesen zu bündeln macht das Lernen uneindeutig.
+
+Minimum heißt Minimum:: Wenn ein handgezeichnetes Mockup, eine Landing Page oder ein Concierge-Service die Hypothese testen kann, *ist* das das MVP. Code ist oft nicht erforderlich. Das "P" steht für Produkt, aber das Produkt kann eine Illusion sein.
+
+Build-Measure-Learn-Zyklus:: Das MVP ist die erste Runde eines engen Feedback-Zyklus: baue etwas Minimales, miss die Reaktion echter Benutzer, lerne aus den Daten, entscheide dann über Pivot oder Persevere.
+
+Keine kleine v1:: Ein häufiger Missbrauch ist, das erste Release eines polierten Produkts "MVP" zu nennen. Ein echtes MVP wäre in Produktion peinlich — sein Job ist Lernen, nicht Markteintritt.
+
+Pivot oder Persevere:: Das MVP liefert die Evidenz zur Wahl: in gleicher Richtung weitermachen (Persevere) oder aufgrund des Gelernten den Kurs ändern (Pivot).
+
+Abgrenzung zum Walking Skeleton:: Ein Walking Skeleton validiert *Architektur*; ein MVP validiert *Marktnachfrage*. Man kann eines ohne das andere haben.
+
+
+Schlüsselvertreter:: Eric Ries ("The Lean Startup", 2011); Frank Robinson prägte den Begriff 2001
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Validierung, ob ein neues Produkt oder Feature ein echtes Benutzerproblem löst, bevor in vollständige Entwicklung investiert wird
+* Test von Preisgestaltung, Positionierung oder Zielsegment-Hypothesen mit minimalem Risiko
+* Frühphasige Startups mit begrenztem Runway, die sich nicht leisten können, das Falsche zu bauen
+* Interne Produktexperimente, bei denen Feature-Ideen Evidenz vor der Priorisierung brauchen
+* LLM-Prompting: "Entwirf ein MVP für X" signalisiert *teste die Hypothese, liefere kein komplettes Produkt*
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<jobs-to-be-done,Jobs to be Done>> - Framework zur Artikulation des Benutzerbedürfnisses, das ein MVP validieren soll
+* <<impact-mapping,Impact Mapping>> - Technik zur Ausrichtung des MVP-Umfangs auf Geschäftsziele
+* <<user-story-mapping,User Story Mapping>> - Visuelles Werkzeug zur Identifikation des minimalen Story-Sets für ein MVP
+* <<walking-skeleton,Walking Skeleton>> - Architektonisches Gegenstück; validiert Struktur statt Marktnachfrage
+====
diff --git a/docs/anchors/red-green-tdd.adoc b/docs/anchors/red-green-tdd.adoc
@@ -0,0 +1,50 @@
+= Red/Green TDD
+:categories: testing-quality
+:roles: software-developer, qa-engineer, educator
+:related: tdd-chicago-school, tdd-london-school, bdd-given-when-then
+:proponents: Kent Beck
+:tags: tdd, testing, red-green-refactor, test-first, classical
+:tier: 3
+
+[%collapsible]
+====
+Also known as:: Red-Green-Refactor, Classical TDD Cycle, Test-First Development
+
+[discrete]
+== *Core Concepts*:
+
+Red phase:: Write a failing test *first*, before any production code. The test must actually run and fail for the right reason — compilation errors don't count as red.
+
+Green phase:: Write the *minimum* production code required to make the failing test pass. Resist the urge to add functionality the test does not demand.
+
+Refactor phase:: With tests passing, improve the design — rename, extract, deduplicate — confident the test suite will catch regressions.
+
+Small steps:: Each cycle is deliberately small (seconds to minutes), not hours. Large leaps break the feedback loop.
+
+Watch it fail:: Verifying that the test actually fails *before* implementation catches tautological tests and typos in the test itself.
+
+Test names describe behavior:: Not method names. "Returns empty list when no users exist" tells you what the code does; "test getUsers" does not.
+
+Minimum to pass:: Fake it ('return 42'), hardcode, or copy-paste — whatever makes the test pass fastest. Generalization happens in the refactor phase via triangulation.
+
+One test at a time:: Only one failing test in the suite at any moment. Never add a second failing test before the first is green.
+
+
+Key Proponents:: Kent Beck ("Test-Driven Development: By Example", 2002); popularized for LLM coding agents by Simon Willison
+
+[discrete]
+== *When to Use*:
+
+* Instructing LLM coding agents that default to implementing features first and writing tests afterwards
+* New production code where requirements can be expressed as concrete examples
+* Bug fixes — write a failing test that reproduces the bug, then fix
+* Refactoring legacy code that lacks test coverage (start by characterizing behavior)
+* Teaching disciplined incremental development
+
+[discrete]
+== *Related Anchors*:
+
+* <<tdd-chicago-school,TDD Chicago School>> - State-based classical TDD focused on real objects over mocks
+* <<tdd-london-school,TDD London School>> - Mock-heavy, interaction-based, outside-in variant
+* <<bdd-given-when-then,BDD Given-When-Then>> - Behavior-driven complement for higher-level acceptance tests
+====
diff --git a/docs/anchors/red-green-tdd.de.adoc b/docs/anchors/red-green-tdd.de.adoc
@@ -0,0 +1,50 @@
+= Red/Green TDD
+:categories: testing-quality
+:roles: software-developer, qa-engineer, educator
+:related: tdd-chicago-school, tdd-london-school, bdd-given-when-then
+:proponents: Kent Beck
+:tags: tdd, testing, red-green-refactor, test-first, classical
+:tier: 3
+
+[%collapsible]
+====
+Auch bekannt als:: Red-Green-Refactor, Klassischer TDD-Zyklus, Test-First-Entwicklung
+
+[discrete]
+== *Kernkonzepte*:
+
+Red-Phase:: Schreibe *zuerst* einen fehlschlagenden Test, bevor irgendwelcher Produktionscode existiert. Der Test muss tatsächlich laufen und aus dem richtigen Grund scheitern — Kompilierfehler zählen nicht als rot.
+
+Green-Phase:: Schreibe das *Minimum* an Produktionscode, das den fehlgeschlagenen Test grün macht. Widerstehe dem Drang, Funktionalität hinzuzufügen, die der Test nicht verlangt.
+
+Refactor-Phase:: Mit grünen Tests verbessere das Design — umbenennen, extrahieren, Duplikate entfernen — im Vertrauen darauf, dass die Testsuite Regressionen fängt.
+
+Kleine Schritte:: Jeder Zyklus ist bewusst klein (Sekunden bis Minuten), nicht Stunden. Große Sprünge zerstören die Feedback-Schleife.
+
+Scheitern beobachten:: Zu verifizieren, dass der Test tatsächlich *vor* der Implementierung fehlschlägt, fängt tautologische Tests und Tippfehler im Test selbst.
+
+Testnamen beschreiben Verhalten:: Nicht Methodennamen. "Gibt leere Liste zurück, wenn keine Benutzer existieren" sagt, was der Code tut; "test getUsers" nicht.
+
+Minimum zum Bestehen:: "Fake it" (return 42), hardcoden, kopieren — was auch immer den Test am schnellsten grün macht. Verallgemeinerung passiert in der Refactor-Phase durch Triangulation.
+
+Ein Test nach dem anderen:: Zu jedem Zeitpunkt nur ein fehlschlagender Test in der Suite. Niemals einen zweiten fehlschlagenden Test hinzufügen, bevor der erste grün ist.
+
+
+Schlüsselvertreter:: Kent Beck ("Test-Driven Development: By Example", 2002); für LLM-Coding-Agents popularisiert durch Simon Willison
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Instruktion von LLM-Coding-Agents, die standardmäßig Features zuerst implementieren und Tests hinterher schreiben
+* Neuer Produktionscode, bei dem Anforderungen als konkrete Beispiele ausgedrückt werden können
+* Bugfixes — schreibe einen fehlschlagenden Test, der den Bug reproduziert, dann behebe ihn
+* Refactoring von Legacy-Code ohne Testabdeckung (beginne mit Charakterisierungstests)
+* Vermittlung disziplinierter inkrementeller Entwicklung
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<tdd-chicago-school,TDD Chicago School>> - Zustandsbasiertes klassisches TDD, das echte Objekte statt Mocks bevorzugt
+* <<tdd-london-school,TDD London School>> - Mock-lastige, interaktionsbasierte, outside-in Variante
+* <<bdd-given-when-then,BDD Given-When-Then>> - Verhaltensgetriebene Ergänzung für höhergelegene Akzeptanztests
+====