From 465983ce584f2f6e4745e30c3167261b0c1846d2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=7BAI=7Df=20D=2E=20M=C3=BCller?= Date: Sun, 12 Apr 2026 13:39:43 +0200 Subject: [PATCH] feat: add 7 new anchors (#412, #413, #420-424) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Red/Green TDD → testing-quality (#412, @petehodgson-tribe) - 4MAT → communication-presentation (#413, @rweisleder) - Walking Skeleton → software-architecture (#420, @cpoepke) - Tracer Bullet → software-architecture (#421, @cpoepke) - Thin Vertical Slice → development-workflow (#422, @cpoepke) - Spike Solution → development-workflow (#423, @cpoepke) - Minimum Viable Product (MVP) → strategic-planning (#424, @cpoepke) All anchors include EN + DE content, catalog entries, changelog, and regenerated metadata. Note: the proposed "System Inception Patterns" category (#414) was declined in favor of sorting each anchor into existing categories based on its primary concern (architecture validation, delivery workflow, or product-hypothesis validation). Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/all-anchors.adoc | 16 + docs/anchors/4mat.adoc | 50 +++ docs/anchors/4mat.de.adoc | 50 +++ docs/anchors/mvp.adoc | 53 +++ docs/anchors/mvp.de.adoc | 53 +++ docs/anchors/red-green-tdd.adoc | 50 +++ docs/anchors/red-green-tdd.de.adoc | 50 +++ docs/anchors/spike-solution.adoc | 48 +++ docs/anchors/spike-solution.de.adoc | 48 +++ docs/anchors/thin-vertical-slice.adoc | 49 +++ docs/anchors/thin-vertical-slice.de.adoc | 49 +++ docs/anchors/tracer-bullet.adoc | 48 +++ docs/anchors/tracer-bullet.de.adoc | 48 +++ docs/anchors/walking-skeleton.adoc | 49 +++ docs/anchors/walking-skeleton.de.adoc | 49 +++ docs/changelog.adoc | 12 + .../references/catalog.md | 35 ++ website/public/data/anchors.json | 242 +++++++++++++ website/public/data/categories.json | 10 +- website/public/data/metadata.json | 8 +- website/public/data/roles.json | 25 ++ website/public/llms.txt | 330 +++++++++++++++++- website/public/sitemap.xml | 314 ++++++++++------- 23 files changed, 1555 insertions(+), 131 deletions(-) create mode 100644 docs/anchors/4mat.adoc create mode 100644 docs/anchors/4mat.de.adoc create mode 100644 docs/anchors/mvp.adoc create mode 100644 docs/anchors/mvp.de.adoc create mode 100644 docs/anchors/red-green-tdd.adoc create mode 100644 docs/anchors/red-green-tdd.de.adoc create mode 100644 docs/anchors/spike-solution.adoc create mode 100644 docs/anchors/spike-solution.de.adoc create mode 100644 docs/anchors/thin-vertical-slice.adoc create mode 100644 docs/anchors/thin-vertical-slice.de.adoc create mode 100644 docs/anchors/tracer-bullet.adoc create mode 100644 docs/anchors/tracer-bullet.de.adoc create mode 100644 docs/anchors/walking-skeleton.adoc create mode 100644 docs/anchors/walking-skeleton.de.adoc diff --git a/docs/all-anchors.adoc b/docs/all-anchors.adoc index af13c36..c51ef37 100644 --- 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 new file mode 100644 index 0000000..de33550 --- /dev/null +++ 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*: + +* <> - Top-down structure for written communication; complements 4MAT which is experience-first +* <> - Self-directed learning; 4MAT is teacher-directed instructional design +* <> - 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 new file mode 100644 index 0000000..5663454 --- /dev/null +++ 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*: + +* <> - Top-down-Struktur für schriftliche Kommunikation; ergänzt 4MAT, das erfahrungsorientiert beginnt +* <> - Selbstgesteuertes Lernen; 4MAT ist lehrergesteuertes Instruktionsdesign +* <> - Dokumentationstypen (Tutorial/How-to/Reference/Explanation) entsprechen grob den 4MAT-Quadranten +==== diff --git a/docs/anchors/mvp.adoc b/docs/anchors/mvp.adoc new file mode 100644 index 0000000..cde9203 --- /dev/null +++ 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*: + +* <> - Framework for articulating the user need an MVP is trying to validate +* <> - Technique for aligning MVP scope with business outcomes +* <> - Visual tool for identifying the minimum set of stories for an MVP +* <> - Architectural counterpart; validates structure rather than market demand +==== diff --git a/docs/anchors/mvp.de.adoc b/docs/anchors/mvp.de.adoc new file mode 100644 index 0000000..49c3c67 --- /dev/null +++ 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*: + +* <> - Framework zur Artikulation des Benutzerbedürfnisses, das ein MVP validieren soll +* <> - Technik zur Ausrichtung des MVP-Umfangs auf Geschäftsziele +* <> - Visuelles Werkzeug zur Identifikation des minimalen Story-Sets für ein MVP +* <> - Architektonisches Gegenstück; validiert Struktur statt Marktnachfrage +==== diff --git a/docs/anchors/red-green-tdd.adoc b/docs/anchors/red-green-tdd.adoc new file mode 100644 index 0000000..cf5c74c --- /dev/null +++ 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*: + +* <> - State-based classical TDD focused on real objects over mocks +* <> - Mock-heavy, interaction-based, outside-in variant +* <> - 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 new file mode 100644 index 0000000..885baf4 --- /dev/null +++ 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*: + +* <> - Zustandsbasiertes klassisches TDD, das echte Objekte statt Mocks bevorzugt +* <> - Mock-lastige, interaktionsbasierte, outside-in Variante +* <> - Verhaltensgetriebene Ergänzung für höhergelegene Akzeptanztests +==== diff --git a/docs/anchors/spike-solution.adoc b/docs/anchors/spike-solution.adoc new file mode 100644 index 0000000..6a0911f --- /dev/null +++ b/docs/anchors/spike-solution.adoc @@ -0,0 +1,48 @@ += Spike Solution +:categories: development-workflow +:roles: software-developer, software-architect, team-lead +:related: tracer-bullet, walking-skeleton, pugh-matrix +:proponents: Kent Beck +:tags: xp, experiment, research, time-boxed, risk-reduction, throwaway +:tier: 3 + +[%collapsible] +==== +Also known as:: Spike, Technical Spike, Research Spike + +[discrete] +== *Core Concepts*: + +Time-boxed:: A spike has an explicit, non-negotiable deadline (hours or days, not weeks). When time runs out, the spike ends — even if the answer is incomplete. An unbounded spike has become speculative development. + +Single question:: A spike answers *one* specific technical question: "Can library X handle our throughput?", "Will the auth provider accept these claims?", "Is Approach A or B faster?". Multiple questions mean multiple spikes. + +Disposable:: The code is throwaway. It lives in a branch (or scratch repo), gets studied, and gets deleted. Reusing spike code in production defeats the purpose — spike quality is deliberately rough. + +Output is a decision, not a deliverable:: The point of a spike is to reduce uncertainty so a decision can be made. Common outputs: a short writeup, a benchmark number, a "yes/no" answer, an ADR. Never a pull request to main. + +Reduces estimation risk:: Spikes are commonly used when a story cannot be estimated because of unknown unknowns. After the spike, the team can estimate with confidence. + +Low ceremony, high focus:: No code review, no test coverage, no polish. The constraint is "learn the answer as fast as possible", which is the opposite of production code. + +Explicit in the backlog:: "Spike: investigate X" is a legitimate work item. Teams should track spikes as first-class, not hide them inside regular stories. + + +Key Proponents:: Kent Beck ("Extreme Programming Explained", 1999, 2nd ed. 2004); Ron Jeffries popularized the term in early XP writings + +[discrete] +== *When to Use*: + +* Estimating a story is impossible because of unknown technical risk +* Choosing between two approaches requires empirical evidence rather than debate +* A new library, framework, or API is being evaluated +* Performance, scalability, or integration assumptions need verification before commitment +* LLM prompting: "spike the approach" cleanly signals *explore, don't build* + +[discrete] +== *Related Anchors*: + +* <> - Also exploratory, but tracer bullets are kept and iterated on, not discarded +* <> - Production-capable end-to-end scaffolding; the opposite of a spike on the throwaway axis +* <> - Decision-support technique a spike often feeds into +==== diff --git a/docs/anchors/spike-solution.de.adoc b/docs/anchors/spike-solution.de.adoc new file mode 100644 index 0000000..6d389e4 --- /dev/null +++ b/docs/anchors/spike-solution.de.adoc @@ -0,0 +1,48 @@ += Spike Solution +:categories: development-workflow +:roles: software-developer, software-architect, team-lead +:related: tracer-bullet, walking-skeleton, pugh-matrix +:proponents: Kent Beck +:tags: xp, experiment, research, time-boxed, risk-reduction, throwaway +:tier: 3 + +[%collapsible] +==== +Auch bekannt als:: Spike, Technischer Spike, Research-Spike + +[discrete] +== *Kernkonzepte*: + +Zeitlich begrenzt:: Ein Spike hat eine explizite, nicht verhandelbare Deadline (Stunden oder Tage, nicht Wochen). Wenn die Zeit abläuft, endet der Spike — auch wenn die Antwort unvollständig ist. Ein unbegrenzter Spike ist zu spekulativer Entwicklung geworden. + +Einzelne Frage:: Ein Spike beantwortet *eine* spezifische technische Frage: "Kann Library X unseren Durchsatz?", "Akzeptiert der Auth-Provider diese Claims?", "Ist Ansatz A oder B schneller?". Mehrere Fragen bedeuten mehrere Spikes. + +Wegwerfbar:: Der Code ist Wegwerfware. Er lebt in einem Branch (oder Scratch-Repo), wird studiert und dann gelöscht. Spike-Code in Produktion zu übernehmen verfehlt den Zweck — Spike-Qualität ist absichtlich roh. + +Ergebnis ist eine Entscheidung, kein Produkt:: Der Sinn eines Spikes ist Unsicherheit zu reduzieren, damit eine Entscheidung getroffen werden kann. Übliche Ergebnisse: kurzer Bericht, Benchmark-Zahl, "Ja/Nein"-Antwort, ein ADR. Niemals ein Pull Request nach main. + +Reduziert Schätzrisiko:: Spikes werden oft eingesetzt, wenn eine Story wegen unbekannter Unbekannter nicht schätzbar ist. Nach dem Spike kann das Team mit Vertrauen schätzen. + +Wenig Zeremonie, hoher Fokus:: Kein Code-Review, keine Testabdeckung, kein Feinschliff. Die Beschränkung ist "finde die Antwort so schnell wie möglich" — das Gegenteil von Produktionscode. + +Explizit im Backlog:: "Spike: untersuche X" ist ein legitimer Arbeitspunkt. Teams sollten Spikes als Erstklass-Items tracken, nicht in regulären Stories verstecken. + + +Schlüsselvertreter:: Kent Beck ("Extreme Programming Explained", 1999, 2. Aufl. 2004); Ron Jeffries popularisierte den Begriff in frühen XP-Schriften + +[discrete] +== *Wann zu verwenden*: + +* Eine Story zu schätzen ist wegen unbekannter technischer Risiken unmöglich +* Die Wahl zwischen zwei Ansätzen erfordert empirische Evidenz statt Diskussion +* Eine neue Library, ein Framework oder eine API wird evaluiert +* Performance-, Skalierungs- oder Integrationsannahmen müssen vor Commitment verifiziert werden +* LLM-Prompting: "Spike den Ansatz" signalisiert sauber *erkunden, nicht bauen* + +[discrete] +== *Verwandte Anker*: + +* <> - Ebenfalls explorativ, aber Tracer Bullets werden behalten und iteriert, nicht verworfen +* <> - Produktionsreifes End-to-End-Gerüst; das Gegenteil eines Spikes auf der Wegwerf-Achse +* <> - Entscheidungstechnik, in die ein Spike oft einfließt +==== diff --git a/docs/anchors/thin-vertical-slice.adoc b/docs/anchors/thin-vertical-slice.adoc new file mode 100644 index 0000000..9987c0d --- /dev/null +++ b/docs/anchors/thin-vertical-slice.adoc @@ -0,0 +1,49 @@ += Thin Vertical Slice +:categories: development-workflow +:roles: software-developer, product-owner, team-lead +:related: walking-skeleton, tracer-bullet, vertical-slice-architecture, user-story-mapping +:proponents: Alistair Cockburn, Mike Cohn +:tags: delivery, incremental, end-to-end, iteration, value-slicing +:tier: 3 + +[%collapsible] +==== +Also known as:: Vertical Slicing, End-to-End Slice + +[discrete] +== *Core Concepts*: + +One feature, all layers:: Each increment implements a single small feature end-to-end through every technical layer (UI → logic → persistence → integration) in one piece of work. + +Releasable after every slice:: The goal of slicing is to keep the system shippable after each increment. "Done" means users can use it, not that one layer is finished. + +Cross-cutting, not horizontal:: Horizontal slicing ("finish the DB layer, then the API, then the UI") delays delivery and hides integration problems. Vertical slicing inverts that. + +Small but complete:: A thin slice is small in scope but complete in depth. Removing any layer breaks the feature; shortening any layer is fine. + +Avoid integration surprises:: Because every slice touches every layer, integration issues surface early and often, not as a terrifying end-of-project merge. + +Value per slice:: Each slice should produce a user-observable change. "Refactor the user service" is not a vertical slice; "user can change their email" is. + +Distinct from Vertical Slice Architecture:: VSA is a *structural pattern* for organizing code; thin vertical slicing is a *delivery technique* for organizing work. They are complementary but independent — you can slice thinly with or without VSA. + + +Key Proponents:: Alistair Cockburn ("Agile Software Development", 2001); Mike Cohn ("User Stories Applied", 2004) + +[discrete] +== *When to Use*: + +* Breaking down user stories or epics into deliverable increments +* Avoiding big-bang integrations at the end of a sprint or project +* When the team needs early, frequent user feedback on actual working software +* Reducing risk on long-running feature work by shipping usable subsets +* Any agile delivery context where "done" should mean "shipped" + +[discrete] +== *Related Anchors*: + +* <> - The first thin slice in a greenfield system; architecture validation +* <> - Exploratory end-to-end slice for direction validation +* <> - Structural pattern that organizes code to match sliced delivery +* <> - Technique for identifying which slices to cut first +==== diff --git a/docs/anchors/thin-vertical-slice.de.adoc b/docs/anchors/thin-vertical-slice.de.adoc new file mode 100644 index 0000000..ea54cae --- /dev/null +++ b/docs/anchors/thin-vertical-slice.de.adoc @@ -0,0 +1,49 @@ += Thin Vertical Slice +:categories: development-workflow +:roles: software-developer, product-owner, team-lead +:related: walking-skeleton, tracer-bullet, vertical-slice-architecture, user-story-mapping +:proponents: Alistair Cockburn, Mike Cohn +:tags: delivery, incremental, end-to-end, iteration, value-slicing +:tier: 3 + +[%collapsible] +==== +Auch bekannt als:: Vertikales Slicing, End-to-End-Scheibe + +[discrete] +== *Kernkonzepte*: + +Ein Feature, alle Schichten:: Jedes Inkrement implementiert ein einzelnes kleines Feature end-to-end durch jede technische Schicht (UI → Logik → Persistenz → Integration) in einem Arbeitspaket. + +Nach jeder Scheibe auslieferbar:: Das Ziel des Slicings ist, das System nach jedem Inkrement lieferbar zu halten. "Fertig" bedeutet, Benutzer können es nutzen, nicht dass eine Schicht abgeschlossen ist. + +Schneidet quer, nicht horizontal:: Horizontales Slicing ("erst die DB-Schicht fertig, dann API, dann UI") verzögert Lieferung und versteckt Integrationsprobleme. Vertikales Slicing kehrt das um. + +Klein, aber komplett:: Eine dünne Scheibe ist klein im Umfang, aber vollständig in der Tiefe. Jede Schicht weglassen bricht das Feature; jede Schicht verkürzen ist okay. + +Integrationsüberraschungen vermeiden:: Weil jede Scheibe jede Schicht berührt, tauchen Integrationsprobleme früh und oft auf, nicht als gefürchteter End-of-Project-Merge. + +Wert pro Scheibe:: Jede Scheibe sollte eine für Benutzer beobachtbare Änderung erzeugen. "User Service refactoren" ist keine vertikale Scheibe; "Benutzer kann E-Mail ändern" schon. + +Abgrenzung zu Vertical Slice Architecture:: VSA ist ein *Strukturmuster* für die Organisation von Code; Thin Vertical Slicing ist eine *Liefertechnik* für die Organisation von Arbeit. Sie ergänzen sich, sind aber unabhängig — du kannst dünn slicen mit oder ohne VSA. + + +Schlüsselvertreter:: Alistair Cockburn ("Agile Software Development", 2001); Mike Cohn ("User Stories Applied", 2004) + +[discrete] +== *Wann zu verwenden*: + +* Zerlegung von User Stories oder Epics in lieferbare Inkremente +* Vermeidung von Big-Bang-Integrationen am Ende eines Sprints oder Projekts +* Wenn das Team frühes, häufiges Benutzer-Feedback auf tatsächlich laufender Software braucht +* Risikoreduktion bei langlaufender Feature-Arbeit durch Auslieferung nutzbarer Teilmengen +* Jeder agile Lieferkontext, in dem "fertig" "ausgeliefert" bedeuten soll + +[discrete] +== *Verwandte Anker*: + +* <> - Die erste dünne Scheibe in einem Greenfield-System; Architekturvalidierung +* <> - Explorative End-to-End-Scheibe zur Richtungsvalidierung +* <> - Strukturmuster, das Code zur geschnittenen Lieferung passend organisiert +* <> - Technik zur Identifikation, welche Scheiben zuerst geschnitten werden +==== diff --git a/docs/anchors/tracer-bullet.adoc b/docs/anchors/tracer-bullet.adoc new file mode 100644 index 0000000..30d4cc2 --- /dev/null +++ b/docs/anchors/tracer-bullet.adoc @@ -0,0 +1,48 @@ += Tracer Bullet +:categories: software-architecture +:roles: software-architect, software-developer +:related: walking-skeleton, spike-solution, thin-vertical-slice +:proponents: Andy Hunt, David Thomas +:tags: architecture, validation, end-to-end, iterative, direction-finding +:tier: 3 + +[%collapsible] +==== +Also known as:: Tracer Bullet Development, Tracer Code + +[discrete] +== *Core Concepts*: + +End-to-end but lightweight:: Build a thin slice that touches all the pieces of the final system — in realtime, on real infrastructure — to see whether your architectural direction lands where you aimed. + +Real ammo, not blanks:: Unlike a spike or prototype, tracer bullet code is *kept and refined*. It becomes part of the final system, not throwaway. The distinction: you iterate on it rather than rewrite it. + +Immediate feedback on integration:: You learn quickly whether your chosen tech stack, service boundaries, and data flow *actually work together*, not just whether each piece works in isolation. + +Aim, fire, adjust:: The metaphor is a tracer round in a machine gun — you see where the shot lands in real time and adjust your aim for the next burst. Tracer bullets enable rapid directional correction. + +Not feature-complete:: The first tracer is deliberately incomplete. One feature, end-to-end, good enough to validate the *shape* of the solution without committing to full functionality. + +Architecture validation over feature delivery:: The primary goal is answering "will this architecture work?", not "is this feature done?". + +Iterative refinement:: Subsequent tracers refine the aim — adjusting interfaces, choosing different libraries, or repositioning service boundaries based on what the first shot revealed. + + +Key Proponents:: Andrew Hunt and David Thomas ("The Pragmatic Programmer", 1999; 20th Anniversary Edition 2019) + +[discrete] +== *When to Use*: + +* Unfamiliar technology stacks where integration risk is unknown +* Complex system boundaries (microservices, event-driven architectures) where interaction patterns are hard to predict +* Exploratory projects where requirements are still being discovered +* When architectural commitments need to be validated before scaling the team +* Projects where early user or stakeholder feedback on the *shape* of the solution is more valuable than a polished prototype + +[discrete] +== *Related Anchors*: + +* <> - Similar end-to-end approach, but production-capable from day one rather than exploratory +* <> - Also exploratory, but spikes are throwaway and answer a single question +* <> - Delivery technique that shares the end-to-end philosophy at the feature level +==== diff --git a/docs/anchors/tracer-bullet.de.adoc b/docs/anchors/tracer-bullet.de.adoc new file mode 100644 index 0000000..39f1e14 --- /dev/null +++ b/docs/anchors/tracer-bullet.de.adoc @@ -0,0 +1,48 @@ += Tracer Bullet +:categories: software-architecture +:roles: software-architect, software-developer +:related: walking-skeleton, spike-solution, thin-vertical-slice +:proponents: Andy Hunt, David Thomas +:tags: architecture, validation, end-to-end, iterative, direction-finding +:tier: 3 + +[%collapsible] +==== +Auch bekannt als:: Tracer-Bullet-Entwicklung, Tracer Code + +[discrete] +== *Kernkonzepte*: + +End-to-End, aber leichtgewichtig:: Baue eine dünne Scheibe, die alle Teile des endgültigen Systems berührt — in Echtzeit, auf echter Infrastruktur — um zu sehen, ob deine architektonische Richtung dort landet, wo du gezielt hast. + +Echte Munition, keine Platzpatronen:: Anders als bei Spike oder Prototyp wird Tracer-Bullet-Code *behalten und verfeinert*. Er wird Teil des endgültigen Systems, nicht Wegwerfware. Der Unterschied: Du iterierst darauf, statt ihn neu zu schreiben. + +Sofortiges Integrations-Feedback:: Du lernst schnell, ob dein gewählter Tech-Stack, Service-Grenzen und Datenfluss *tatsächlich zusammenarbeiten*, nicht nur ob jedes Teil isoliert funktioniert. + +Zielen, schießen, korrigieren:: Die Metapher ist eine Leuchtspurkugel aus einem Maschinengewehr — du siehst in Echtzeit, wo der Schuss landet, und passt dein Ziel für die nächste Salve an. Tracer Bullets ermöglichen schnelle richtungsweisende Korrektur. + +Nicht featurevollständig:: Der erste Tracer ist absichtlich unvollständig. Ein Feature, end-to-end, gut genug, um die *Form* der Lösung zu validieren, ohne sich auf volle Funktionalität festzulegen. + +Architekturvalidierung vor Feature-Lieferung:: Das primäre Ziel ist die Beantwortung von "Wird diese Architektur funktionieren?", nicht "Ist dieses Feature fertig?". + +Iterative Verfeinerung:: Nachfolgende Tracer justieren das Ziel — Interfaces anpassen, andere Bibliotheken wählen oder Servicegrenzen verschieben auf Basis dessen, was der erste Schuss offenbart hat. + + +Schlüsselvertreter:: Andrew Hunt und David Thomas ("The Pragmatic Programmer", 1999; 20. Jubiläumsausgabe 2019) + +[discrete] +== *Wann zu verwenden*: + +* Unbekannte Technologie-Stacks, bei denen Integrationsrisiko unklar ist +* Komplexe Systemgrenzen (Microservices, event-getriebene Architekturen) mit schwer vorhersagbaren Interaktionsmustern +* Explorative Projekte, in denen Anforderungen noch entdeckt werden +* Wenn architektonische Entscheidungen validiert werden müssen, bevor das Team skaliert wird +* Projekte, in denen frühes Benutzer- oder Stakeholder-Feedback zur *Form* der Lösung wertvoller ist als ein polierter Prototyp + +[discrete] +== *Verwandte Anker*: + +* <> - Ähnlicher End-to-End-Ansatz, aber produktionsreif vom ersten Tag an, statt explorativ +* <> - Ebenfalls explorativ, aber Spikes sind Wegwerf und beantworten eine einzelne Frage +* <> - Liefertechnik, die die End-to-End-Philosophie auf Feature-Ebene teilt +==== diff --git a/docs/anchors/walking-skeleton.adoc b/docs/anchors/walking-skeleton.adoc new file mode 100644 index 0000000..ff4a42d --- /dev/null +++ b/docs/anchors/walking-skeleton.adoc @@ -0,0 +1,49 @@ += Walking Skeleton +:categories: software-architecture +:roles: software-architect, software-developer, team-lead +:related: tracer-bullet, thin-vertical-slice, clean-architecture, hexagonal-architecture +:proponents: Alistair Cockburn +:tags: architecture, inception, end-to-end, deployment, risk-reduction +:tier: 3 + +[%collapsible] +==== +Also known as:: Skeleton Architecture, End-to-End Thin Implementation + +[discrete] +== *Core Concepts*: + +End-to-end from day one:: A minimal implementation that touches every architectural layer — UI, application logic, domain, persistence, deployment pipeline — before any significant feature work begins. + +Production-capable:: Unlike a throwaway prototype, the walking skeleton is *real code* that can be shipped to production. It passes through CI/CD, runs on target infrastructure, and forms the foundation for subsequent features. + +Minimal functionality, maximum structure:: A single trivial user journey (one button, one form, one record) is enough. The value is in proving the *structure*, not the feature set. + +Early risk reduction:: Integration risks (does the DB driver work in prod? does auth talk to the identity provider? does the deploy pipeline reach the target?) surface on day one instead of week twelve. + +Walking = working:: "Walking" is the defining verb — the skeleton must move through its full lifecycle (build, deploy, serve a request, return a response, log an event), not just compile. + +Foundation for iteration:: Once the skeleton walks, adding real features becomes additive work on a known-good structure. No "big bang" integration later. + +Not a prototype:: A prototype is discarded; a walking skeleton is grown. The distinction matters — prototype code tempts shortcuts that don't belong in production. + + +Key Proponents:: Alistair Cockburn ("Agile Software Development", 2001); the term originates in his collaboration with Ralph Hodgson + +[discrete] +== *When to Use*: + +* Starting a new system where integration between layers carries architectural risk +* Greenfield projects with unfamiliar tech stacks or deployment targets +* Validating CI/CD, infrastructure, and cross-team contracts before scaling development +* Distributed systems where the "it works on my machine" gap is dangerous +* Any project where the first production deploy should happen *early*, not *late* + +[discrete] +== *Related Anchors*: + +* <> - Also end-to-end, but exploratory and direction-validating rather than production-capable +* <> - Delivery technique for subsequent features on top of the skeleton +* <> - A common structural target the skeleton can instantiate from day one +* <> - Ports/adapters structure the skeleton naturally exposes +==== diff --git a/docs/anchors/walking-skeleton.de.adoc b/docs/anchors/walking-skeleton.de.adoc new file mode 100644 index 0000000..1e7971c --- /dev/null +++ b/docs/anchors/walking-skeleton.de.adoc @@ -0,0 +1,49 @@ += Walking Skeleton +:categories: software-architecture +:roles: software-architect, software-developer, team-lead +:related: tracer-bullet, thin-vertical-slice, clean-architecture, hexagonal-architecture +:proponents: Alistair Cockburn +:tags: architecture, inception, end-to-end, deployment, risk-reduction +:tier: 3 + +[%collapsible] +==== +Auch bekannt als:: Skelett-Architektur, End-to-End Dünne Implementierung + +[discrete] +== *Kernkonzepte*: + +End-to-End vom ersten Tag:: Eine minimale Implementierung, die jede Architekturschicht berührt — UI, Anwendungslogik, Domäne, Persistenz, Deployment-Pipeline — bevor signifikante Feature-Arbeit beginnt. + +Produktionsreif:: Anders als ein Wegwerf-Prototyp ist das Walking Skeleton *echter Code*, der in Produktion geliefert werden kann. Er durchläuft CI/CD, läuft auf Zielinfrastruktur und bildet die Grundlage für nachfolgende Features. + +Minimale Funktionalität, maximale Struktur:: Eine einzige triviale Benutzerreise (ein Button, ein Formular, ein Datensatz) reicht. Der Wert liegt darin, die *Struktur* zu beweisen, nicht die Featureanzahl. + +Frühe Risikoreduktion:: Integrationsrisiken (funktioniert der DB-Treiber in Produktion? Spricht Auth mit dem Identity Provider? Erreicht die Deploy-Pipeline das Ziel?) tauchen am ersten Tag auf statt in Woche zwölf. + +Walking = funktionierend:: "Walking" ist das definierende Verb — das Skelett muss seinen gesamten Lebenszyklus durchlaufen (Build, Deploy, Request bedienen, Response liefern, Event loggen), nicht nur kompilieren. + +Fundament für Iteration:: Sobald das Skelett läuft, wird das Hinzufügen echter Features zu additiver Arbeit auf einer bekannten Struktur. Kein "Big Bang"-Integrationsschritt später. + +Kein Prototyp:: Ein Prototyp wird verworfen; ein Walking Skeleton wird gezüchtet. Die Unterscheidung zählt — Prototyp-Code verleitet zu Shortcuts, die in Produktion nichts verloren haben. + + +Schlüsselvertreter:: Alistair Cockburn ("Agile Software Development", 2001); der Begriff stammt aus seiner Zusammenarbeit mit Ralph Hodgson + +[discrete] +== *Wann zu verwenden*: + +* Start eines neuen Systems, bei dem Integration zwischen Schichten architektonisches Risiko birgt +* Greenfield-Projekte mit unbekannten Tech-Stacks oder Deployment-Zielen +* Validierung von CI/CD, Infrastruktur und teamübergreifenden Verträgen vor dem Skalieren der Entwicklung +* Verteilte Systeme, bei denen die "Funktioniert auf meiner Maschine"-Lücke gefährlich ist +* Jedes Projekt, bei dem der erste Produktions-Deploy *früh* statt *spät* stattfinden sollte + +[discrete] +== *Verwandte Anker*: + +* <> - Ebenfalls end-to-end, aber explorativ und richtungsvalidierend statt produktionsreif +* <> - Liefertechnik für nachfolgende Features auf dem Skelett +* <> - Ein häufiges Strukturziel, das das Skelett vom ersten Tag an instanziieren kann +* <> - Ports/Adapter-Struktur, die das Skelett natürlich freilegt +==== diff --git a/docs/changelog.adoc b/docs/changelog.adoc index e255535..1322c0b 100644 --- a/docs/changelog.adoc +++ b/docs/changelog.adoc @@ -2,6 +2,18 @@ A chronological record of all semantic anchors added to the catalog. Community contributors are credited with thanks. +== 2026-04-12 + +*New anchors:* + +* *Red/Green TDD* — Kent Beck's classical TDD cycle (proposed by https://github.com/petehodgson-tribe[@petehodgson-tribe] in https://github.com/LLM-Coding/Semantic-Anchors/issues/412[#412]) +* *4MAT* — Bernice McCarthy's learning cycle: why → what → how → what if (proposed by https://github.com/rweisleder[@rweisleder] in https://github.com/LLM-Coding/Semantic-Anchors/issues/413[#413]) +* *Walking Skeleton* — Alistair Cockburn's end-to-end production-capable skeleton (proposed by https://github.com/cpoepke[@cpoepke] in https://github.com/LLM-Coding/Semantic-Anchors/issues/420[#420]) +* *Tracer Bullet* — Hunt & Thomas's exploratory end-to-end slice (proposed by https://github.com/cpoepke[@cpoepke] in https://github.com/LLM-Coding/Semantic-Anchors/issues/421[#421]) +* *Thin Vertical Slice* — Cockburn & Cohn's end-to-end delivery technique (proposed by https://github.com/cpoepke[@cpoepke] in https://github.com/LLM-Coding/Semantic-Anchors/issues/422[#422]) +* *Spike Solution* — Kent Beck's time-boxed XP research technique (proposed by https://github.com/cpoepke[@cpoepke] in https://github.com/LLM-Coding/Semantic-Anchors/issues/423[#423]) +* *Minimum Viable Product (MVP)* — Eric Ries's lean-startup hypothesis validation (proposed by https://github.com/cpoepke[@cpoepke] in https://github.com/LLM-Coding/Semantic-Anchors/issues/424[#424]) + == 2026-04-07 *New anchors* (proposed by Gernot Starke): diff --git a/skill/semantic-anchor-translator/references/catalog.md b/skill/semantic-anchor-translator/references/catalog.md index 727e392..2465bb3 100644 --- a/skill/semantic-anchor-translator/references/catalog.md +++ b/skill/semantic-anchor-translator/references/catalog.md @@ -81,6 +81,11 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors - **Proponents:** Percy Liang (Stanford HELM), EleutherAI (Open LLM Leaderboard), LMSYS (Chatbot Arena) - **Core:** Frameworks and metrics for assessing LLM capabilities — benchmark suites (MMLU, HumanEval, BIG-Bench), automatic vs. human evaluation, HELM, Chatbot Arena Elo ratings, red-teaming, contamination detection +### Red/Green TDD +- **Also known as:** Red-Green-Refactor, Classical TDD Cycle, Test-First Development +- **Proponents:** Kent Beck +- **Core:** Classical TDD cycle — write failing test first (red), minimal code to pass (green), then refactor; watch it fail for the right reason; one failing test at a time; test names describe behavior, not method signatures; counters the default LLM habit of writing tests after the implementation + ## Software Architecture ### Clean Architecture @@ -146,6 +151,16 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors - **Proponents:** OWASP Foundation - **Core:** Consensus ranking of the ten most critical web-application security risks (Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Authentication Failures, Data Integrity Failures, Logging Failures, SSRF); used as a baseline checklist for secure code review, threat modeling, and compliance +### Walking Skeleton +- **Also known as:** Skeleton Architecture, End-to-End Thin Implementation +- **Proponents:** Alistair Cockburn +- **Core:** Minimal end-to-end implementation touching every architectural layer (UI → logic → persistence → deployment) that is production-capable from day one; validates integration and structure before any significant feature work; grown iteratively rather than thrown away like a prototype + +### Tracer Bullet +- **Also known as:** Tracer Bullet Development, Tracer Code +- **Proponents:** Andy Hunt, David Thomas +- **Core:** Lightweight end-to-end slice that validates architectural direction on real infrastructure; unlike a spike, tracer code is kept and refined into the final system; enables rapid directional correction via the "aim-fire-adjust" loop; primary goal is architecture validation, not feature delivery + ## Design Principles ### SOLID Principles @@ -396,6 +411,11 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors - **Proponents:** William Strunk Jr., E.B. White - **Core:** Omit needless words, use active voice, prefer concrete language, write with nouns and verbs — clarity-first principles for English writing ("The Elements of Style") +### 4MAT +- **Also known as:** 4MAT System of Instruction, McCarthy's 4MAT, 4MAT Learning Cycle +- **Proponents:** Bernice McCarthy +- **Core:** Four-quadrant learning cycle structuring explanations and presentations — Why (motivation, relevance), What (facts, concepts), How (practical application, examples), What If (extension, transfer); order matters to serve all four learner types (Innovative/Analytic/Common Sense/Dynamic) instead of only analytic learners + ### Chatham House Rule - **Proponents:** Chatham House - **Core:** Info can be used but not attributed to speaker/org @@ -479,6 +499,16 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors - **Proponents:** Tiago Forte (coined the term), inspired by Ernest Hemingway - **Core:** End each work session before a natural stopping point while you still know what comes next; leave an explicit re-entry note (unfinished sentence, comment, TODO) to eliminate "blank page" paralysis, preserve momentum, and manage creative energy across sessions +### Thin Vertical Slice +- **Also known as:** Vertical Slicing, End-to-End Slice +- **Proponents:** Alistair Cockburn, Mike Cohn +- **Core:** Delivery technique where each increment implements one small feature end-to-end through every technical layer (UI → logic → persistence → integration); keeps the system shippable after each slice; distinct from Vertical Slice Architecture (structural pattern vs. delivery technique); surfaces integration issues early and often + +### Spike Solution +- **Also known as:** Spike, Technical Spike, Research Spike +- **Proponents:** Kent Beck +- **Core:** Time-boxed, disposable experiment written to answer one specific technical question before committing to an approach; output is a decision, not a deliverable; deliberately rough quality — no tests, no review, no polish; time-boxing is mandatory or the spike becomes speculative development + ## Statistical Methods ### SPC (Statistical Process Control) @@ -510,6 +540,11 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors - **Proponents:** D.G. Malcolm, J.H. Roseboom, C.E. Clark, W. Fazar - **Core:** Stochastic project scheduling using three-point estimates per activity (Optimistic, Most Likely, Pessimistic); weighted average formula E = (O + 4M + P) / 6; standard deviation σ = (P − O) / 6; critical path analysis; probabilistic milestone confidence intervals +### Minimum Viable Product (MVP) +- **Also known as:** MVP, Lean Startup MVP +- **Proponents:** Eric Ries, Frank Robinson +- **Core:** Smallest product that tests a single falsifiable hypothesis about user needs with the least effort; the defining output is *validated learning*, not a feature set or revenue; first turn of the build-measure-learn loop; distinct from a "small v1" — an MVP would be embarrassing to ship in production because its job is learning, not market entry; gives evidence for pivot-or-persevere decisions + ## Creative Writing & Storytelling ### Three-Act Structure diff --git a/website/public/data/anchors.json b/website/public/data/anchors.json index 386430a..c75403a 100644 --- a/website/public/data/anchors.json +++ b/website/public/data/anchors.json @@ -1,4 +1,34 @@ [ + { + "id": "4mat", + "title": "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" + ], + "filePath": "docs/anchors/4mat.adoc", + "tier": 3 + }, { "id": "adr-according-to-nygard", "title": "ADR according to Nygard", @@ -193,6 +223,38 @@ "filePath": "docs/anchors/clean-architecture.adoc", "tier": 3 }, + { + "id": "cohesion-criteria", + "title": "Cohesion Criteria", + "categories": [ + "design-principles" + ], + "roles": [ + "software-architect", + "software-developer", + "consultant", + "educator" + ], + "related": [ + "grasp", + "solid-srp", + "clean-architecture", + "vertical-slice-architecture" + ], + "proponents": [ + "Larry Constantine", + "Edward Yourdon" + ], + "tags": [ + "cohesion", + "coupling", + "module design", + "structured design", + "code quality" + ], + "filePath": "docs/anchors/cohesion-criteria.adoc", + "tier": 2 + }, { "id": "control-chart-shewhart", "title": "Control Chart (Shewhart)", @@ -2151,6 +2213,37 @@ "filePath": "docs/anchors/mutation-testing.adoc", "tier": 3 }, + { + "id": "mvp", + "title": "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" + ], + "filePath": "docs/anchors/mvp.adoc", + "tier": 3 + }, { "id": "myers-briggs-type-indicator", "title": "Myers-Briggs Type Indicator (MBTI)", @@ -2440,6 +2533,35 @@ "filePath": "docs/anchors/pyramid-principle.adoc", "tier": 3 }, + { + "id": "red-green-tdd", + "title": "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" + ], + "filePath": "docs/anchors/red-green-tdd.adoc", + "tier": 3 + }, { "id": "regulated-environment", "title": "Regulated Environment", @@ -2752,6 +2874,36 @@ ], "tier": 3 }, + { + "id": "spike-solution", + "title": "Spike Solution", + "categories": [ + "development-workflow" + ], + "roles": [ + "software-developer", + "software-architect", + "team-lead" + ], + "related": [ + "tracer-bullet", + "walking-skeleton", + "pugh-matrix" + ], + "proponents": [ + "Kent Beck" + ], + "tags": [ + "xp", + "experiment", + "research", + "time-boxed", + "risk-reduction", + "throwaway" + ], + "filePath": "docs/anchors/spike-solution.adoc", + "tier": 3 + }, { "id": "ssot-principle", "title": "SSOT (Single Source of Truth)", @@ -3107,6 +3259,37 @@ "filePath": "docs/anchors/testing-pyramid.adoc", "tier": 3 }, + { + "id": "thin-vertical-slice", + "title": "Thin Vertical Slice", + "categories": [ + "development-workflow" + ], + "roles": [ + "software-developer", + "product-owner", + "team-lead" + ], + "related": [ + "walking-skeleton", + "tracer-bullet", + "vertical-slice-architecture", + "user-story-mapping" + ], + "proponents": [ + "Alistair Cockburn", + "Mike Cohn" + ], + "tags": [ + "delivery", + "incremental", + "end-to-end", + "iteration", + "value-slicing" + ], + "filePath": "docs/anchors/thin-vertical-slice.adoc", + "tier": 3 + }, { "id": "three-act-structure", "title": "Three-Act Structure", @@ -3182,6 +3365,35 @@ "filePath": "docs/anchors/todotxt-flavoured-markdown.adoc", "tier": 3 }, + { + "id": "tracer-bullet", + "title": "Tracer Bullet", + "categories": [ + "software-architecture" + ], + "roles": [ + "software-architect", + "software-developer" + ], + "related": [ + "walking-skeleton", + "spike-solution", + "thin-vertical-slice" + ], + "proponents": [ + "Andy Hunt", + "David Thomas" + ], + "tags": [ + "architecture", + "validation", + "end-to-end", + "iterative", + "direction-finding" + ], + "filePath": "docs/anchors/tracer-bullet.adoc", + "tier": 3 + }, { "id": "user-story-mapping", "title": "User Story Mapping", @@ -3228,6 +3440,36 @@ "filePath": "docs/anchors/vertical-slice-architecture.adoc", "tier": 3 }, + { + "id": "walking-skeleton", + "title": "Walking Skeleton", + "categories": [ + "software-architecture" + ], + "roles": [ + "software-architect", + "software-developer", + "team-lead" + ], + "related": [ + "tracer-bullet", + "thin-vertical-slice", + "clean-architecture", + "hexagonal-architecture" + ], + "proponents": [ + "Alistair Cockburn" + ], + "tags": [ + "architecture", + "inception", + "end-to-end", + "deployment", + "risk-reduction" + ], + "filePath": "docs/anchors/walking-skeleton.adoc", + "tier": 3 + }, { "id": "wardley-mapping", "title": "Wardley Mapping", diff --git a/website/public/data/categories.json b/website/public/data/categories.json index 3dec5b2..332998f 100644 --- a/website/public/data/categories.json +++ b/website/public/data/categories.json @@ -3,6 +3,7 @@ "id": "communication-presentation", "name": "Communication & Presentation", "anchors": [ + "4mat", "bluf", "gutes-deutsch-wolf-schneider", "mece", @@ -29,6 +30,7 @@ "id": "design-principles", "name": "Design Principles & Patterns", "anchors": [ + "cohesion-criteria", "crc-cards", "fowler-patterns", "gof-abstract-factory-pattern", @@ -81,6 +83,8 @@ "regulated-environment", "semantic-versioning", "sota", + "spike-solution", + "thin-vertical-slice", "timtowtdi" ] }, @@ -156,7 +160,9 @@ "iso-25010", "lasr", "madr", - "vertical-slice-architecture" + "tracer-bullet", + "vertical-slice-architecture", + "walking-skeleton" ] }, { @@ -175,6 +181,7 @@ "cynefin-framework", "impact-mapping", "jobs-to-be-done", + "mvp", "pert", "pugh-matrix", "swot", @@ -194,6 +201,7 @@ "mutation-testing", "owasp-top-10", "property-based-testing", + "red-green-tdd", "stride", "tdd-chicago-school", "tdd-london-school", diff --git a/website/public/data/metadata.json b/website/public/data/metadata.json index af4d178..5016699 100644 --- a/website/public/data/metadata.json +++ b/website/public/data/metadata.json @@ -1,15 +1,15 @@ { - "generatedAt": "2026-04-01T08:18:02.208Z", + "generatedAt": "2026-04-12T15:16:42.235Z", "version": "1.0.0", "counts": { - "anchors": 122, + "anchors": 130, "categories": 14, "roles": 12 }, "statistics": { "averageRolesPerAnchor": "3.14", "averageCategoriesPerAnchor": "1.01", - "anchorsWithTags": 82, - "anchorsWithRelated": 53 + "anchorsWithTags": 90, + "anchorsWithRelated": 61 } } \ No newline at end of file diff --git a/website/public/data/roles.json b/website/public/data/roles.json index 6787ac4..0acaaf1 100644 --- a/website/public/data/roles.json +++ b/website/public/data/roles.json @@ -33,8 +33,10 @@ "id": "consultant", "name": "Consultant / Coach", "anchors": [ + "4mat", "bluf", "c4-diagrams", + "cohesion-criteria", "crc-cards", "cynefin-framework", "devils-advocate", @@ -56,6 +58,7 @@ "mental-model-according-to-naur", "morphological-box", "moscow", + "mvp", "myers-briggs-type-indicator", "owasp-top-10", "pert", @@ -116,6 +119,8 @@ "id": "educator", "name": "Educator / Trainer", "anchors": [ + "4mat", + "cohesion-criteria", "crc-cards", "diataxis-framework", "feynman-technique", @@ -134,6 +139,7 @@ "para-method", "pert", "plain-english-strunk-white", + "red-green-tdd", "save-the-cat", "socratic-method", "solid-principles", @@ -160,6 +166,7 @@ "jobs-to-be-done", "morphological-box", "moscow", + "mvp", "myers-briggs-type-indicator", "pert", "prd", @@ -167,6 +174,7 @@ "pugh-matrix", "semantic-versioning", "swot", + "thin-vertical-slice", "user-story-mapping", "wardley-mapping" ] @@ -189,6 +197,7 @@ "mutation-testing", "owasp-top-10", "property-based-testing", + "red-green-tdd", "regulated-environment", "spc", "stride", @@ -212,6 +221,7 @@ "atam", "c4-diagrams", "clean-architecture", + "cohesion-criteria", "cqrs", "crc-cards", "cynefin-framework", @@ -267,12 +277,15 @@ "solid-ocp", "solid-principles", "solid-srp", + "spike-solution", "ssot-principle", "stride", "swot", "tdd-london-school", "timtowtdi", + "tracer-bullet", "vertical-slice-architecture", + "walking-skeleton", "wardley-mapping", "yagni" ] @@ -286,6 +299,7 @@ "bem-methodology", "chain-of-thought", "clean-architecture", + "cohesion-criteria", "conventional-commits", "cqrs", "crc-cards", @@ -344,6 +358,7 @@ "plain-english-strunk-white", "prd", "property-based-testing", + "red-green-tdd", "regulated-environment", "semantic-versioning", "solid-dip", @@ -353,6 +368,7 @@ "solid-principles", "solid-srp", "sota", + "spike-solution", "stride", "tdd-chicago-school", "tdd-london-school", @@ -363,9 +379,12 @@ "test-double-spy", "test-double-stub", "testing-pyramid", + "thin-vertical-slice", "timtowtdi", "todotxt-flavoured-markdown", + "tracer-bullet", "vertical-slice-architecture", + "walking-skeleton", "yagni" ] }, @@ -373,6 +392,7 @@ "id": "team-lead", "name": "Team Lead / Engineering Manager", "anchors": [ + "4mat", "adr-according-to-nygard", "arc42", "atam", @@ -398,6 +418,7 @@ "mental-model-according-to-naur", "mikado-method", "moscow", + "mvp", "myers-briggs-type-indicator", "owasp-top-10", "para-method", @@ -409,11 +430,14 @@ "regulated-environment", "socratic-method", "spc", + "spike-solution", "stride", "swot", "testing-pyramid", + "thin-vertical-slice", "todotxt-flavoured-markdown", "user-story-mapping", + "walking-skeleton", "wardley-mapping" ] }, @@ -421,6 +445,7 @@ "id": "technical-writer", "name": "Technical Writer / Documentation Specialist", "anchors": [ + "4mat", "arc42", "bluf", "c4-diagrams", diff --git a/website/public/llms.txt b/website/public/llms.txt index 84ce55c..b1042ac 100644 --- a/website/public/llms.txt +++ b/website/public/llms.txt @@ -1,6 +1,6 @@ # Semantic Anchors — Complete Reference -> 123 well-defined terms, methodologies, and frameworks +> 131 well-defined terms, methodologies, and frameworks > that serve as precision reference points when communicating with LLMs. > Source: https://github.com/LLM-Coding/Semantic-Anchors > Website: https://llm-coding.github.io/Semantic-Anchors/ @@ -309,6 +309,47 @@ Ready to explore? [Browse the catalog →](https://llm-coding.github.io/Semantic ## Communication & Presentation +### 4MAT + +***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 - Top-down structure for written communication; complements 4MAT which is experience-first +* Feynman Technique - Self-directed learning; 4MAT is teacher-directed instructional design +* Diátaxis Framework - Documentation types (tutorial/how-to/reference/explanation) map loosely to 4MAT quadrants + ### BLUF (Bottom Line Up Front) ***Full Name***: BLUF (Bottom Line Up Front) @@ -926,6 +967,50 @@ Ready to explore? [Browse the catalog →](https://llm-coding.github.io/Semantic ## Design Principles & Patterns +### Cohesion Criteria + +***Full Name***: Cohesion Criteria (Constantine & Yourdon) + +***Also known as***: Levels of Cohesion, Cohesion Scale, Module Cohesion Types + +[discrete] +## **Core Concepts**: + +Seven levels of cohesion, ranked from worst (1) to best (7): + +***Coincidental Cohesion (1)***: Elements are grouped arbitrarily with no meaningful relationship. Typical sign: utility classes or grab-bag modules. + +***Logical Cohesion (2)***: Elements perform similar activities selected by a control flag. Example: a function handling all I/O (read, write, print) chosen by a parameter. + +***Temporal Cohesion (3)***: Elements are grouped because they execute at the same time. Example: startup initialization routines bundled together. + +***Procedural Cohesion (4)***: Elements are grouped because they follow a specific execution sequence. Example: a function that validates input, then opens a file, then writes a log. + +***Communicational Cohesion (5)***: Elements operate on the same data but perform different operations. Example: a module that both validates and formats a customer record. + +***Sequential Cohesion (6)***: The output of one element serves as input to the next, forming a pipeline. Example: parse -> validate -> transform. + +***Functional Cohesion (7)***: Every element contributes to a single, well-defined task. The ideal. Example: `calculateShippingCost()` does exactly one thing. + +***Key Proponents***: Larry Constantine and Edward Yourdon ("Structured Design", 1979). Further developed by Meilir Page-Jones ("The Practical Guide to Structured Systems Design", 1988). + +[discrete] +## **When to Use**: + +* Evaluating module quality during code reviews or refactoring +* Deciding whether to split a class or module that feels too large +* Arguing for refactoring with concrete criteria instead of gut feeling +* Teaching software design: the scale makes abstract quality tangible +* Assessing architecture decisions around module boundaries + +[discrete] +## **Related Anchors**: + +* GRASP - "High Cohesion" is one of the nine GRASP patterns +* SOLID SRP - Single Responsibility Principle targets functional cohesion +* Clean Architecture - Organizes code by cohesive business rules +* Vertical Slice Architecture - Groups by feature cohesion rather than technical layer + ### CRC-Cards ***Full Name***: Class-Responsibility-Collaboration Cards @@ -2261,6 +2346,85 @@ A class should have only one reason to change. Each module or class should be re * Concise trigger for comprehensive research behavior * Activates research-oriented response patterns in LLMs +### Spike Solution + +***Also known as***: Spike, Technical Spike, Research Spike + +[discrete] +## **Core Concepts**: + +***Time-boxed***: A spike has an explicit, non-negotiable deadline (hours or days, not weeks). When time runs out, the spike ends — even if the answer is incomplete. An unbounded spike has become speculative development. + +***Single question***: A spike answers **one** specific technical question: "Can library X handle our throughput?", "Will the auth provider accept these claims?", "Is Approach A or B faster?". Multiple questions mean multiple spikes. + +***Disposable***: The code is throwaway. It lives in a branch (or scratch repo), gets studied, and gets deleted. Reusing spike code in production defeats the purpose — spike quality is deliberately rough. + +***Output is a decision, not a deliverable***: The point of a spike is to reduce uncertainty so a decision can be made. Common outputs: a short writeup, a benchmark number, a "yes/no" answer, an ADR. Never a pull request to main. + +***Reduces estimation risk***: Spikes are commonly used when a story cannot be estimated because of unknown unknowns. After the spike, the team can estimate with confidence. + +***Low ceremony, high focus***: No code review, no test coverage, no polish. The constraint is "learn the answer as fast as possible", which is the opposite of production code. + +***Explicit in the backlog***: "Spike: investigate X" is a legitimate work item. Teams should track spikes as first-class, not hide them inside regular stories. + +***Key Proponents***: Kent Beck ("Extreme Programming Explained", 1999, 2nd ed. 2004); Ron Jeffries popularized the term in early XP writings + +[discrete] +## **When to Use**: + +* Estimating a story is impossible because of unknown technical risk +* Choosing between two approaches requires empirical evidence rather than debate +* A new library, framework, or API is being evaluated +* Performance, scalability, or integration assumptions need verification before commitment +* LLM prompting: "spike the approach" cleanly signals **explore, don't build** + +[discrete] +## **Related Anchors**: + +* Tracer Bullet - Also exploratory, but tracer bullets are kept and iterated on, not discarded +* Walking Skeleton - Production-capable end-to-end scaffolding; the opposite of a spike on the throwaway axis +* Pugh Matrix - Decision-support technique a spike often feeds into + +### Thin Vertical Slice + +***Also known as***: Vertical Slicing, End-to-End Slice + +[discrete] +## **Core Concepts**: + +***One feature, all layers***: Each increment implements a single small feature end-to-end through every technical layer (UI → logic → persistence → integration) in one piece of work. + +***Releasable after every slice***: The goal of slicing is to keep the system shippable after each increment. "Done" means users can use it, not that one layer is finished. + +***Cross-cutting, not horizontal***: Horizontal slicing ("finish the DB layer, then the API, then the UI") delays delivery and hides integration problems. Vertical slicing inverts that. + +***Small but complete***: A thin slice is small in scope but complete in depth. Removing any layer breaks the feature; shortening any layer is fine. + +***Avoid integration surprises***: Because every slice touches every layer, integration issues surface early and often, not as a terrifying end-of-project merge. + +***Value per slice***: Each slice should produce a user-observable change. "Refactor the user service" is not a vertical slice; "user can change their email" is. + +***Distinct from Vertical Slice Architecture***: VSA is a **structural pattern** for organizing code; thin vertical slicing is a **delivery technique** for organizing work. They are complementary but independent — you can slice thinly with or without VSA. + +***Key Proponents***: Alistair Cockburn ("Agile Software Development", 2001); Mike Cohn ("User Stories Applied", 2004) + +[discrete] +## **When to Use**: + +* Breaking down user stories or epics into deliverable increments +* Avoiding big-bang integrations at the end of a sprint or project +* When the team needs early, frequent user feedback on actual working software +* Reducing risk on long-running feature work by shipping usable subsets +* Any agile delivery context where "done" should mean "shipped" + +[discrete] +## **Related Anchors**: + +* Walking Skeleton - The first thin slice in a greenfield system; architecture validation +* Tracer Bullet - Exploratory end-to-end slice for direction validation +* Vertical Slice Architecture - Structural pattern that organizes code to match sliced delivery +* User Story Mapping - Technique for identifying which slices to cut first + ### TIMTOWTDI ***Full Name***: There Is More Than One Way To Do It @@ -3771,6 +3935,45 @@ MoSCoW = **M**ust have / **S**hould have / **C**ould have / **W**on't have * When LLM assistance is needed to generate consistent decision records * Complementing arc42 Section 9 (Architecture Decisions) +### Tracer Bullet + +***Also known as***: Tracer Bullet Development, Tracer Code + +[discrete] +## **Core Concepts**: + +***End-to-end but lightweight***: Build a thin slice that touches all the pieces of the final system — in realtime, on real infrastructure — to see whether your architectural direction lands where you aimed. + +***Real ammo, not blanks***: Unlike a spike or prototype, tracer bullet code is **kept and refined**. It becomes part of the final system, not throwaway. The distinction: you iterate on it rather than rewrite it. + +***Immediate feedback on integration***: You learn quickly whether your chosen tech stack, service boundaries, and data flow **actually work together**, not just whether each piece works in isolation. + +***Aim, fire, adjust***: The metaphor is a tracer round in a machine gun — you see where the shot lands in real time and adjust your aim for the next burst. Tracer bullets enable rapid directional correction. + +***Not feature-complete***: The first tracer is deliberately incomplete. One feature, end-to-end, good enough to validate the **shape** of the solution without committing to full functionality. + +***Architecture validation over feature delivery***: The primary goal is answering "will this architecture work?", not "is this feature done?". + +***Iterative refinement***: Subsequent tracers refine the aim — adjusting interfaces, choosing different libraries, or repositioning service boundaries based on what the first shot revealed. + +***Key Proponents***: Andrew Hunt and David Thomas ("The Pragmatic Programmer", 1999; 20th Anniversary Edition 2019) + +[discrete] +## **When to Use**: + +* Unfamiliar technology stacks where integration risk is unknown +* Complex system boundaries (microservices, event-driven architectures) where interaction patterns are hard to predict +* Exploratory projects where requirements are still being discovered +* When architectural commitments need to be validated before scaling the team +* Projects where early user or stakeholder feedback on the **shape** of the solution is more valuable than a polished prototype + +[discrete] +## **Related Anchors**: + +* Walking Skeleton - Similar end-to-end approach, but production-capable from day one rather than exploratory +* Spike Solution - Also exploratory, but spikes are throwaway and answer a single question +* Thin Vertical Slice - Delivery technique that shares the end-to-end philosophy at the feature level + ### Vertical Slice Architecture (VSA) ***Also known as***: VSA, Feature Slices @@ -3811,6 +4014,46 @@ MoSCoW = **M**ust have / **S**hould have / **C**ould have / **W**on't have * Hexagonal Architecture (Ports & Adapters) * CQRS +### Walking Skeleton + +***Also known as***: Skeleton Architecture, End-to-End Thin Implementation + +[discrete] +## **Core Concepts**: + +***End-to-end from day one***: A minimal implementation that touches every architectural layer — UI, application logic, domain, persistence, deployment pipeline — before any significant feature work begins. + +***Production-capable***: Unlike a throwaway prototype, the walking skeleton is **real code** that can be shipped to production. It passes through CI/CD, runs on target infrastructure, and forms the foundation for subsequent features. + +***Minimal functionality, maximum structure***: A single trivial user journey (one button, one form, one record) is enough. The value is in proving the **structure**, not the feature set. + +***Early risk reduction***: Integration risks (does the DB driver work in prod? does auth talk to the identity provider? does the deploy pipeline reach the target?) surface on day one instead of week twelve. + +***Walking = working***: "Walking" is the defining verb — the skeleton must move through its full lifecycle (build, deploy, serve a request, return a response, log an event), not just compile. + +***Foundation for iteration***: Once the skeleton walks, adding real features becomes additive work on a known-good structure. No "big bang" integration later. + +***Not a prototype***: A prototype is discarded; a walking skeleton is grown. The distinction matters — prototype code tempts shortcuts that don't belong in production. + +***Key Proponents***: Alistair Cockburn ("Agile Software Development", 2001); the term originates in his collaboration with Ralph Hodgson + +[discrete] +## **When to Use**: + +* Starting a new system where integration between layers carries architectural risk +* Greenfield projects with unfamiliar tech stacks or deployment targets +* Validating CI/CD, infrastructure, and cross-team contracts before scaling development +* Distributed systems where the "it works on my machine" gap is dangerous +* Any project where the first production deploy should happen **early**, not **late** + +[discrete] +## **Related Anchors**: + +* Tracer Bullet - Also end-to-end, but exploratory and direction-validating rather than production-capable +* Thin Vertical Slice - Delivery technique for subsequent features on top of the skeleton +* Clean Architecture - A common structural target the skeleton can instantiate from day one +* Hexagonal Architecture - Ports/adapters structure the skeleton naturally exposes + --- ## Statistical Methods & Process Monitoring @@ -4084,6 +4327,50 @@ MoSCoW = **M**ust have / **S**hould have / **C**ould have / **W**on't have * Writing more meaningful user stories * Market segmentation based on jobs, not demographics +### Minimum Viable Product (MVP) + +***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 - Framework for articulating the user need an MVP is trying to validate +* Impact Mapping - Technique for aligning MVP scope with business outcomes +* User Story Mapping - Visual tool for identifying the minimum set of stories for an MVP +* Walking Skeleton - Architectural counterpart; validates structure rather than market demand + ### PERT ***Full Name***: Program Evaluation and Review Technique @@ -4659,6 +4946,47 @@ SWOT = **S**trengths / **W**eaknesses / **O**pportunities / **T**hreats * Finding edge cases in complex logic * Complementing example-based TDD +### Red/Green TDD + +***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 - State-based classical TDD focused on real objects over mocks +* TDD London School - Mock-heavy, interaction-based, outside-in variant +* BDD Given-When-Then - Behavior-driven complement for higher-level acceptance tests + ### STRIDE Threat Model ***Full Name***: STRIDE Threat Modeling Framework diff --git a/website/public/sitemap.xml b/website/public/sitemap.xml index b81445d..b5c8654 100644 --- a/website/public/sitemap.xml +++ b/website/public/sitemap.xml @@ -3,7 +3,7 @@ https://llm-coding.github.io/Semantic-Anchors/ - 2026-04-01 + 2026-04-12 weekly 1.0 @@ -11,7 +11,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/about - 2026-04-01 + 2026-04-12 monthly 0.8 @@ -19,15 +19,23 @@ https://llm-coding.github.io/Semantic-Anchors/#/contributing - 2026-04-01 + 2026-04-12 monthly 0.7 + + + https://llm-coding.github.io/Semantic-Anchors/#/anchor/4mat + 2026-04-12 + monthly + 0.6 + + https://llm-coding.github.io/Semantic-Anchors/#/anchor/adr-according-to-nygard - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -35,7 +43,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/arc42 - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -43,7 +51,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/atam - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -51,7 +59,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/bdd-given-when-then - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -59,7 +67,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/bem-methodology - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -67,7 +75,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/bluf - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -75,7 +83,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/c4-diagrams - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -83,7 +91,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/chain-of-thought - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -91,7 +99,15 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/clean-architecture - 2026-04-01 + 2026-04-12 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/#/anchor/cohesion-criteria + 2026-04-12 monthly 0.6 @@ -99,7 +115,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/control-chart-shewhart - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -107,7 +123,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/conventional-commits - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -115,7 +131,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/cqrs - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -123,7 +139,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/crc-cards - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -131,7 +147,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/cynefin-framework - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -139,7 +155,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/definition-of-done - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -147,7 +163,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/devils-advocate - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -155,7 +171,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/diataxis-framework - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -163,7 +179,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/docs-as-code - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -171,7 +187,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/domain-driven-design - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -179,7 +195,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/ears-requirements - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -187,7 +203,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/effective-go - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -195,7 +211,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/event-driven-architecture - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -203,7 +219,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/fagan-inspection - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -211,7 +227,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/feynman-technique - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -219,7 +235,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/fichtean-curve - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -227,7 +243,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/five-whys - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -235,7 +251,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/fowler-patterns - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -243,7 +259,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/freytags-pyramid - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -251,7 +267,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gherkin - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -259,7 +275,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/github-flow - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -267,7 +283,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-abstract-factory-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -275,7 +291,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-adapter-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -283,7 +299,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-bridge-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -291,7 +307,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-builder-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -299,7 +315,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-chain-of-responsibility-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -307,7 +323,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-command-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -315,7 +331,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-composite-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -323,7 +339,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-decorator-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -331,7 +347,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-design-patterns - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -339,7 +355,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-facade-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -347,7 +363,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-factory-method-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -355,7 +371,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-flyweight-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -363,7 +379,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-interpreter-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -371,7 +387,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-iterator-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -379,7 +395,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-mediator-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -387,7 +403,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-memento-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -395,7 +411,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-observer-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -403,7 +419,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-prototype-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -411,7 +427,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-proxy-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -419,7 +435,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-singleton-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -427,7 +443,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-state-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -435,7 +451,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-strategy-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -443,7 +459,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-template-method-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -451,7 +467,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gof-visitor-pattern - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -459,7 +475,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gom - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -467,7 +483,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/grasp - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -475,7 +491,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gtd - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -483,7 +499,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/gutes-deutsch-wolf-schneider - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -491,7 +507,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/hemingway-bridge - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -499,7 +515,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/heros-journey - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -507,7 +523,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/hexagonal-architecture - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -515,7 +531,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/iec-61508-sil-levels - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -523,7 +539,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/impact-mapping - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -531,7 +547,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/invest - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -539,7 +555,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/iso-25010 - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -547,7 +563,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/jobs-to-be-done - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -555,7 +571,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/kishotenketsu - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -563,7 +579,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/kiss-principle - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -571,7 +587,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/lasr - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -579,7 +595,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/linddun - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -587,7 +603,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/llm-evaluations - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -595,7 +611,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/madr - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -603,7 +619,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/mece - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -611,7 +627,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/mental-model-according-to-naur - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -619,7 +635,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/mikado-method - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -627,7 +643,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/morphological-box - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -635,7 +651,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/moscow - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -643,7 +659,15 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/mutation-testing - 2026-04-01 + 2026-04-12 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/#/anchor/mvp + 2026-04-12 monthly 0.6 @@ -651,7 +675,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/myers-briggs-type-indicator - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -659,7 +683,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/nelson-rules - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -667,7 +691,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/owasp-top-10 - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -675,7 +699,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/para-method - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -683,7 +707,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/pert - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -691,7 +715,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/plain-english-strunk-white - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -699,7 +723,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/prd - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -707,7 +731,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/problem-space-nvc - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -715,7 +739,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/property-based-testing - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -723,7 +747,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/pugh-matrix - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -731,7 +755,15 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/pyramid-principle - 2026-04-01 + 2026-04-12 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/#/anchor/red-green-tdd + 2026-04-12 monthly 0.6 @@ -739,7 +771,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/regulated-environment - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -747,7 +779,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/save-the-cat - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -755,7 +787,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/semantic-versioning - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -763,7 +795,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/socratic-method - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -771,7 +803,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/solid-dip - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -779,7 +811,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/solid-isp - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -787,7 +819,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/solid-lsp - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -795,7 +827,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/solid-ocp - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -803,7 +835,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/solid-principles - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -811,7 +843,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/solid-srp - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -819,7 +851,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/sota - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -827,7 +859,15 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/spc - 2026-04-01 + 2026-04-12 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/#/anchor/spike-solution + 2026-04-12 monthly 0.6 @@ -835,7 +875,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/ssot-principle - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -843,7 +883,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/story-circle-dan-harmon - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -851,7 +891,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/stride - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -859,7 +899,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/swot - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -867,7 +907,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/tdd-chicago-school - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -875,7 +915,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/tdd-london-school - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -883,7 +923,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/test-double-dummy - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -891,7 +931,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/test-double-fake - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -899,7 +939,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/test-double-meszaros - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -907,7 +947,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/test-double-mock - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -915,7 +955,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/test-double-spy - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -923,7 +963,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/test-double-stub - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -931,7 +971,15 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/testing-pyramid - 2026-04-01 + 2026-04-12 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/#/anchor/thin-vertical-slice + 2026-04-12 monthly 0.6 @@ -939,7 +987,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/three-act-structure - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -947,7 +995,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/timtowtdi - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -955,7 +1003,15 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/todotxt-flavoured-markdown - 2026-04-01 + 2026-04-12 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/#/anchor/tracer-bullet + 2026-04-12 monthly 0.6 @@ -963,7 +1019,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/user-story-mapping - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -971,7 +1027,15 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/vertical-slice-architecture - 2026-04-01 + 2026-04-12 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/#/anchor/walking-skeleton + 2026-04-12 monthly 0.6 @@ -979,7 +1043,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/wardley-mapping - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -987,7 +1051,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/what-qualifies-as-a-semantic-anchor - 2026-04-01 + 2026-04-12 monthly 0.6 @@ -995,7 +1059,7 @@ https://llm-coding.github.io/Semantic-Anchors/#/anchor/yagni - 2026-04-01 + 2026-04-12 monthly 0.6