Add Gherkin semantic anchor

docs/anchors/gherkin.adoc

@@ -0,0 +1,47 @@
+= Gherkin
+:categories: testing-quality
+:roles: software-developer, qa-engineer, business-analyst, product-owner
+:related: bdd-given-when-then, ears-requirements, tdd-london-school
+:proponents: Aslak Hellesøy
+:tags: gherkin, bdd, cucumber, given-when-then, specification-by-example, dsl, acceptance-testing, living-documentation
+
+[%collapsible]
+====
+Also known as:: Cucumber DSL, BDD Scenario Language
+
+[discrete]
+== *Core Concepts*:
+
+Feature:: Top-level description of a software capability, grouping related scenarios that describe expected behavior
+
+Scenario:: A concrete example of how the system should behave in a specific situation, written as a sequence of steps
+
+Given-When-Then steps:: Structured step types — Given establishes preconditions, When describes an action, Then asserts the expected outcome; And/But extend any step type
+
+Background:: A set of steps shared across all scenarios in a feature file, executed before each scenario
+
+Scenario Outline / Examples:: Parameterized scenario template with a data table, allowing the same behavior to be tested with multiple input sets
+
+Docstrings and Data Tables:: Inline multi-line strings and tabular data attached to steps for richer input specification
+
+Natural language support:: Gherkin keywords are translated into 70+ human languages, enabling non-English teams to write scenarios in their native language
+
+Human-readable and machine-executable:: Scenarios serve as both documentation for stakeholders and executable tests driven by step definitions in the implementation language
+
+Key Proponent:: Aslak Hellesøy (creator of Cucumber and the Gherkin language, 2008); influenced by Dan North's BDD and JBehave
+
+[discrete]
+== *When to Use*:
+
+* Defining acceptance criteria collaboratively between developers, testers, and business stakeholders
+* Creating living documentation that stays synchronized with the system's behavior
+* Writing automated acceptance tests that non-technical stakeholders can read and verify
+* Projects adopting Behavior-Driven Development (BDD) with tools like Cucumber, SpecFlow, or Behave
+
+[discrete]
+== *Related Anchors*:
+
+* <<bdd-given-when-then,BDD (Behavior-Driven Development)>> - The practice that Gherkin was designed to support
+* <<ears-requirements,EARS Requirements>> - Alternative structured natural-language requirements format
+* <<tdd-london-school,TDD, London School>> - Outside-in development that naturally combines with Gherkin-driven acceptance tests
+====

docs/anchors/gherkin.de.adoc

@@ -0,0 +1,47 @@
+= Gherkin
+:categories: testing-quality
+:roles: software-developer, qa-engineer, business-analyst, product-owner
+:related: bdd-given-when-then, ears-requirements, tdd-london-school
+:proponents: Aslak Hellesøy
+:tags: gherkin, bdd, cucumber, given-when-then, specification-by-example, dsl, acceptance-testing, living-documentation
+
+[%collapsible]
+====
+Auch bekannt als:: Cucumber DSL, BDD-Szenariosprache
+
+[discrete]
+== *Kernkonzepte*:
+
+Feature:: Übergeordnete Beschreibung einer Softwarefähigkeit, die verwandte Szenarien zu erwartetem Verhalten gruppiert
+
+Scenario:: Ein konkretes Beispiel, wie das System in einer bestimmten Situation reagieren soll, beschrieben als eine Abfolge von Schritten
+
+Given-When-Then-Schritte:: Strukturierte Schritttypen — Given legt Vorbedingungen fest, When beschreibt eine Aktion, Then prüft das erwartete Ergebnis; And/But erweitern jeden Schritttyp
+
+Background:: Eine Menge von Schritten, die allen Szenarien einer Feature-Datei gemeinsam sind und vor jedem Szenario ausgeführt werden
+
+Scenario Outline / Examples:: Parametrisierte Szenariovorlage mit einer Datentabelle, die es ermöglicht, dasselbe Verhalten mit verschiedenen Eingabewerten zu testen
+
+Docstrings und Data Tables:: Eingebettete mehrzeilige Zeichenketten und Tabellendaten, die Schritten für reichhaltigere Eingabespezifikationen beigefügt werden
+
+Mehrsprachigkeit:: Gherkin-Schlüsselwörter sind in über 70 Sprachen übersetzt, sodass nicht-englischsprachige Teams Szenarien in ihrer Muttersprache schreiben können
+
+Menschenlesbar und maschinenausführbar:: Szenarien dienen gleichzeitig als Dokumentation für Stakeholder und als ausführbare Tests, die durch Schrittdefinitionen in der Implementierungssprache angetrieben werden
+
+Schlüsselvertreter:: Aslak Hellesøy (Schöpfer von Cucumber und der Gherkin-Sprache, 2008); beeinflusst von Dan Norths BDD und JBehave
+
+[discrete]
+== *Wann zu verwenden*:
+
+* Akzeptanzkriterien kollaborativ zwischen Entwicklern, Testern und fachlichen Stakeholdern definieren
+* Lebendige Dokumentation erstellen, die mit dem Systemverhalten synchron bleibt
+* Automatisierte Akzeptanztests schreiben, die nicht-technische Stakeholder lesen und prüfen können
+* Projekte, die Behavior-Driven Development (BDD) mit Tools wie Cucumber, SpecFlow oder Behave einsetzen
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<bdd-given-when-then,BDD (Behavior-Driven Development)>> - Die Praxis, für die Gherkin entwickelt wurde
+* <<ears-requirements,EARS Requirements>> - Alternatives Format für strukturierte natürlichsprachige Anforderungen
+* <<tdd-london-school,TDD, London School>> - Outside-in-Entwicklung, die sich natürlich mit Gherkin-getriebenen Akzeptanztests verbindet
+====

skill/semantic-anchor-translator/references/catalog.md

@@ -19,6 +19,11 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors
 - **Proponents:** Dan North
 - **Core:** Given-When-Then scenarios, Gherkin syntax, three amigos, living documentation, outside-in specification
 
+### Gherkin
+- **Also known as:** Cucumber DSL, BDD Scenario Language
+- **Proponents:** Aslak Hellesøy
+- **Core:** Domain-specific language for writing human-readable executable specifications; Feature/Scenario/Given/When/Then keywords; Background, Scenario Outline, Examples; 70+ natural languages; used by Cucumber, SpecFlow, Behave
+
 ### Test Double (Meszaros)
 - **Proponents:** Gerard Meszaros
 - **Core:** Taxonomy of test substitutes — Dummy (unused), Stub (canned responses), Spy (records calls), Mock (verifies interactions), Fake (simplified implementation)

website/public/data/anchors.json

@@ -491,6 +491,38 @@
     ],
     "filePath": "docs/anchors/fowler-patterns.adoc"
   },
+  {
+    "id": "gherkin",
+    "title": "Gherkin",
+    "categories": [
+      "testing-quality"
+    ],
+    "roles": [
+      "software-developer",
+      "qa-engineer",
+      "business-analyst",
+      "product-owner"
+    ],
+    "related": [
+      "bdd-given-when-then",
+      "ears-requirements",
+      "tdd-london-school"
+    ],
+    "proponents": [
+      "Aslak Hellesøy"
+    ],
+    "tags": [
+      "gherkin",
+      "bdd",
+      "cucumber",
+      "given-when-then",
+      "specification-by-example",
+      "dsl",
+      "acceptance-testing",
+      "living-documentation"
+    ],
+    "filePath": "docs/anchors/gherkin.adoc"
+  },
   {
     "id": "gof-abstract-factory-pattern",
     "title": "GoF-Abstract Factory Pattern",
@@ -1737,6 +1769,105 @@
     "tags": [],
     "filePath": "docs/anchors/socratic-method.adoc"
   },
+  {
+    "id": "solid-dip",
+    "title": "SOLID-Dependency Inversion Principle",
+    "categories": [
+      "design-principles"
+    ],
+    "roles": [
+      "software-developer",
+      "software-architect"
+    ],
+    "related": [],
+    "proponents": [
+      "Robert C. Martin"
+    ],
+    "tags": [
+      "SOLID",
+      "design principle",
+      "DIP",
+      "dependency inversion"
+    ],
+    "filePath": "docs/anchors/solid-dip.adoc",
+    "umbrella": "solid-principles",
+    "tier": 1
+  },
+  {
+    "id": "solid-isp",
+    "title": "SOLID-Interface Segregation Principle",
+    "categories": [
+      "design-principles"
+    ],
+    "roles": [
+      "software-developer",
+      "software-architect"
+    ],
+    "related": [],
+    "proponents": [
+      "Robert C. Martin"
+    ],
+    "tags": [
+      "SOLID",
+      "design principle",
+      "ISP",
+      "interface segregation"
+    ],
+    "filePath": "docs/anchors/solid-isp.adoc",
+    "umbrella": "solid-principles",
+    "tier": 1
+  },
+  {
+    "id": "solid-lsp",
+    "title": "SOLID-Liskov Substitution Principle",
+    "categories": [
+      "design-principles"
+    ],
+    "roles": [
+      "software-developer",
+      "software-architect"
+    ],
+    "related": [],
+    "proponents": [
+      "Robert C. Martin",
+      "Barbara Liskov"
+    ],
+    "tags": [
+      "SOLID",
+      "design principle",
+      "LSP",
+      "liskov",
+      "substitution"
+    ],
+    "filePath": "docs/anchors/solid-lsp.adoc",
+    "umbrella": "solid-principles",
+    "tier": 1
+  },
+  {
+    "id": "solid-ocp",
+    "title": "SOLID-Open/Closed Principle",
+    "categories": [
+      "design-principles"
+    ],
+    "roles": [
+      "software-developer",
+      "software-architect"
+    ],
+    "related": [],
+    "proponents": [
+      "Robert C. Martin",
+      "Bertrand Meyer"
+    ],
+    "tags": [
+      "SOLID",
+      "design principle",
+      "OCP",
+      "open closed"
+    ],
+    "filePath": "docs/anchors/solid-ocp.adoc",
+    "umbrella": "solid-principles",
+    "tier": 1
+  },
   {
     "id": "solid-principles",
     "title": "SOLID Principles",
@@ -1749,10 +1880,51 @@
       "educator",
       "consultant"
     ],
+    "related": [
+      "gof-design-patterns",
+      "clean-architecture"
+    ],
+    "proponents": [
+      "Robert C. Martin"
+    ],
+    "tags": [
+      "design-principles",
+      "oop",
+      "solid",
+      "uncle-bob"
+    ],
+    "filePath": "docs/anchors/solid-principles.adoc",
+    "subAnchors": [
+      "solid-srp",
+      "solid-ocp",
+      "solid-lsp",
+      "solid-isp",
+      "solid-dip"
+    ]
+  },
+  {
+    "id": "solid-srp",
+    "title": "SOLID-Single Responsibility Principle",
+    "categories": [
+      "design-principles"
+    ],
+    "roles": [
+      "software-developer",
+      "software-architect"
+    ],
     "related": [],
-    "proponents": [],
-    "tags": [],
-    "filePath": "docs/anchors/solid-principles.adoc"
+    "proponents": [
+      "Robert C. Martin"
+    ],
+    "tags": [
+      "SOLID",
+      "design principle",
+      "SRP",
+      "single responsibility"
+    ],
+    "filePath": "docs/anchors/solid-srp.adoc",
+    "umbrella": "solid-principles",
+    "tier": 1
   },
   {
     "id": "sota",

website/public/data/categories.json

@@ -40,7 +40,12 @@
       "gof-strategy-pattern",
       "gof-template-method-pattern",
       "gof-visitor-pattern",
+      "solid-dip",
+      "solid-isp",
+      "solid-lsp",
+      "solid-ocp",
       "solid-principles",
+      "solid-srp",
       "spot-principle",
       "ssot-principle",
       "yagni"
@@ -147,6 +152,7 @@
     "name": "Testing & Quality Practices",
     "anchors": [
       "bdd-given-when-then",
+      "gherkin",
       "iec-61508-sil-levels",
       "mutation-testing",
       "owasp-top-10",

website/public/data/metadata.json

@@ -1,15 +1,15 @@
 {
-  "generatedAt": "2026-03-09T14:10:44.809Z",
+  "generatedAt": "2026-03-11T11:07:32.371Z",
   "version": "1.0.0",
   "counts": {
-    "anchors": 85,
+    "anchors": 92,
     "categories": 12,
     "roles": 12
   },
   "statistics": {
-    "averageRolesPerAnchor": "2.96",
+    "averageRolesPerAnchor": "2.95",
     "averageCategoriesPerAnchor": "1.00",
-    "anchorsWithTags": 40,
-    "anchorsWithRelated": 16
+    "anchorsWithTags": 48,
+    "anchorsWithRelated": 18
   }
 }