Wiki Styleguide

Dieses Dokument definiert die formalen und inhaltlichen Standards für das Orsia-Wiki. Es dient gleichzeitig als Instruktion für LLMs, die Artikel erstellen oder bearbeiten, und als Leitfaden für menschliche Autoren.

Das Wiki erfüllt zwei Funktionen: Es ist ein schnelles Nachschlagewerk am Spieltisch (Scanbarkeit und Eindeutigkeit haben Priorität) und ein epochenübergreifendes Archiv, das über mehrere Kampagnen in verschiedenen Zeiträumen (z. B. 400 aAG, 580 aAG, 856 aAG) konsistent bleibt.

1. Epochensicherheit — Kein „Jetzt” ohne Anker

Jeder Artikel muss so verfasst sein, dass er unabhängig vom In-Game-Jahr des Lesers logisch und korrekt bleibt.

Verboten (ohne festen Zeitbezug)

Wörter wie: heute, jetzt, aktuell, derzeit, kürzlich, vor kurzem, damals, einst
Relative Zeitangaben ohne Bezugspunkt: „vor 10 Jahren”, „der derzeitige König”

Erlaubt

Konkrete Jahreszahlen nach dem aAG-Kalender: „580 aAG”
Zeiträume: „580–612 aAG”
Epochenbezeichnungen: „Frühe Aurora-Ära”
Relative Angaben mit festem Anker: „zwei Winter nach der Zerstörung Valclaires (580 aAG)”
Jahrhundert-Angaben: „im späten 6. Jahrhundert aAG”

Umgang mit unbekannten Daten

Wenn kein exaktes Datum bekannt ist, wird die Angabe offen als unsicher markiert, nicht weggelassen und nicht geraten.

Erlaubt: „um 580 aAG”, „vermutlich im späten 8. Jahrhundert aAG”, „zu einem unbekannten Zeitpunkt vor 600 aAG”
Verboten: Ein Datum erfinden, um die Regel zu erfüllen.

Beispiel

Falsch: „Golia Venier ist kürzlich gestorben und heute gehört der Laden seinem Sohn.”
Richtig: „Nach der Ermordung von Golia Venier (852 aAG) übernahm sein Sohn Alex Venier den Laden.”

2. Lead — Das Wichtigste im ersten Absatz

Der Artikelaufbau folgt dem Prinzip der umgekehrten Pyramide: Wer nur die Einleitung liest, versteht das Subjekt.

Der Lead beantwortet:

Wer/Was — Subjekt und Wesen des Artikels.
Wo — Geografische Verortung oder Zugehörigkeit.
Wann — Relevanter Zeitraum oder Epoche (aAG).
Relevanz — Was macht dieses Subjekt für die Welt oder die Spieler bedeutsam?

Historie, komplexe Zusammenhänge und Flavor gehören in die nachfolgenden Kapitel, nicht in den Lead. Der Lead bleibt kompakt: maximal 3–5 Sätze.

Statuszeile (verpflichtend bei wandelbaren Subjekten)

Wenn sich das Subjekt über die Kampagnenjahre grundlegend verändert hat (zerstört, gestorben, wiederaufgebaut), steht am Ende des Leads eine Statuszeile:

„Status: aktiv (400 aAG), zerstört (580 aAG), wiederbesiedelt (856 aAG).”

Bei Subjekten, die sich nicht verändern, entfällt die Statuszeile.

3. Scope — Vom Großen ins Kleine

Das Wiki folgt dem Top-Down-Prinzip. Jeder Artikel beschränkt sich auf sein Kernthema.

Artikeltypen

Makro-Artikel (Länder, Städte, Organisationen): Fokus auf Regierung, Wirtschaft, Geschichte, Wendepunkte. Einzelne NPCs oder Läden werden nur erwähnt, wenn sie übergeordnete Relevanz haben. Eine kurze Auflistung relevanter Personen, Orte oder Unter-Artikel am Ende eines Kapitels ist erlaubt und erwünscht, um die Navigation zu erleichtern.

Mikro-Artikel (Personen, Tavernen, Artefakte, einzelne Gebäude): Der richtige Ort für persönliche Historie, Beziehungen und Flavor.

Zwischen-Artikel (Stadtteile, Minenabschnitte, Organisationsabteilungen): Beschreiben einen abgegrenzten Teil eines Makro-Themas. Sie stehen thematisch zwischen Makro und Mikro und folgen denselben Regeln wie Makro-Artikel, aber mit engerem Fokus.

Scope-Faustregel

Wenn ein Detail aus dem Text gelöscht werden kann, ohne dass sich das Verständnis des Hauptthemas ändert, gehört das Detail in einen eigenen Unter-Artikel — nicht in diesen Artikel.

Abgrenzung zu Kampagnen-Notizen

Wiki-Artikel beschreiben die Welt epochenübergreifend und neutral. Kampagnen-Notizen (im Ordner 01_Spiele) dokumentieren dagegen das konkrete Spielgeschehen einer Gruppe: Entscheidungen, Session-Verläufe, Pläne der Spieler. Kampagnen-Notizen folgen nicht dem Styleguide.

4. Stil und Perspektive

Neutraler, enzyklopädischer Ton

Das Wiki ist ein Archiv. Ereignisse werden beschrieben, nicht bewertet.

Falsch: „Die tapferen Helden besiegten den abgrundtief bösen Dämon.”
Richtig: „Im Jahr 856 aAG besiegte der Aufklärungstrupp den Dämon in den Stonevein Katakomben.”

Verbotene Perspektiven

Keine Wir-Form: „wir”, „uns”, „unsere Welt”
Keine Du-Form: „Wenn du die Taverne betrittst…”
Keine Spieler-Meta-Referenzen: „Die Party entschied sich…”, „Die Spieler wählten…”

Erzählperspektive: Allwissend, neutral

Das Wiki schreibt aus der Perspektive eines allwissenden Archivars, der alle Fakten kennt — einschließlich verborgener Wahrheiten, geheimer Identitäten und Hintergründe, die kein NPC in der Spielwelt kennt. Spoiler sind erlaubt und erwünscht, da das Wiki primär als DM-Referenz dient.

Erlaubte Subjektivität (In-World-Flavor)

In-World-Färbungen wie Gerüchte, Propaganda oder Legenden sind willkommen, aber nur in klar abgegrenzten Abschnitten:

## Gerüchte und Überlieferungen
## Legenden

Der Haupttext bleibt davon unberührt.

5. Zeitformen

Präsens (Lexikonstil)

Für die Definition, Identität und unveränderliche Eigenschaften:

„Teramons ist die Hauptstadt von Tourcil.”
„Empatia ist eine legendäre Gitarre.”

Präteritum (Historie)

Für abgeschlossene, datierte Ereignisse:

„852 aAG wurde der Hauptsitz zerstört.”
„Eldorath Thalorian wurde 585 aAG versiegelt.”

Sonderfall: Verstorbene, Zerstörtes, Aufgelöstes

Wenn ein Subjekt endgültig aufgehört hat zu existieren, steht die gesamte Identität im Präteritum:

„Valclaire war eine Handelsstadt in Tourcil, die 580 aAG zerstört wurde.”
„Alaric Eisenfass war ein Braumeister in Greendawn.”

Existiert das Subjekt in mindestens einer aktiven Kampagnenepoche noch, bleibt das Präsens für die Definition:

„Eldorath Thalorian ist ein legendärer Hochelf.” (Korrekt, da seine Essenz in der Klinge weiterlebt.)

Wandelbare Zustände mit Zeitanker

Wenn sich ein Zustand epochenabhängig ändert, wird das Präsens oder Präteritum mit einem Zeitanker gekoppelt:

„Im Jahr 856 aAG kontrolliert die Gilde den Hafenbezirk.”
„Zwischen 580 und 610 aAG dominierte sie den Salzhandel.”

6. Struktur und Scanbarkeit

Das Wiki wird am Spieltisch überflogen. Texte müssen beim Scannen sofort erfassbar sein.

Absätze

Absätze kurz halten. Ein Absatz behandelt einen Gedanken oder Zusammenhang — das können ein bis vier Sätze sein. Absätze nicht künstlich auf einen einzigen Satz zerhacken, wenn der Zusammenhang darunter leidet.

Listen und Aufzählungen

Listen eignen sich für: Stadtbezirke, Mitglieder, Beziehungen, Eigenschaften, Gefahren. Jeder Listenpunkt hat mindestens einen vollständigen Satz oder eine knappe Erklärung — keine nackten Stichworte.

Tabellen

Tabellen sind erlaubt und erwünscht für strukturierte Übersichten (Adelshäuser, Handelswaren, Zeitachsen, Vergleiche). Sie werden sparsam eingesetzt und nur dort, wo eine Liste oder Fließtext die Information schlechter transportieren würde.

Fettdruck (sparsam)

Fettdruck ist ein Scan-Werkzeug, keine Dekoration.

Im Lead: Den Artikelgegenstand bei erster Nennung fett markieren.
Im Fließtext: Maximal 3–6 fette Begriffe pro Artikel als Scan-Anker für zentrale Orte, Schlüsselereignisse oder Kernkonzepte. Zu viel Fettdruck zerstört den optischen Fokus.

Begriffserklärungen

Unbekannte In-Universe-Begriffe bei der ersten Nennung verlinken und in maximal einem Halbsatz kontextualisieren. Bei mehr als fünf erklärungsbedürftigen Begriffen im Artikel stattdessen einen Block ## Kurz erklärt mit 3–6 Stichpunkten nach dem Lead einschieben.

7. Obsidian-Formatierung

A. Metadaten (YAML) & Infobox

Jeder Artikel beginnt mit einem YAML-Block. Alle Properties rendern automatisch als Infobox am rechten Rand.

Syntax-Regeln:

Links in Quotes: Alle Wikilinks zwingend in Anführungszeichen: "[[Link]]".
Datum: Format YYYY-MM-DD (aAG-Jahr vierstellig, z. B. 0822-04-04). Bei Ungenauigkeit weglassen oder unbekannt eintragen.
Region vs. Ort: Region (Makro, z. B. "[[Tourcil]]") strikt von Ort (Mikro, z. B. "[[Teramons]]") trennen.

Ort-Properties bei mobilen Subjekten: Die Properties Region und Ort sind für geografisch gebundene Subjekte (Städte, Gebäude, Ruinen). Bei Lebewesen und mobilen Gegenständen stattdessen verwenden:

Personen: Herkunft, Geburtsort
Gegenstände: Erbaut (Ort und/oder Datum der Herstellung), Schöpfer:in
Wenn der letzte bekannte Aufenthaltsort relevant ist: Letzter bekannter Ort

Bilder in der YAML:

image: Hauptbild oben (ohne Beschriftung).
images: Durchklickbare Tabs oben (Liste mehrerer Bilder).
Individuelle Property-Namen (Karte, Wappen etc.): Rendert das Bild weiter unten mit dem Property-Namen als Bildunterschrift.

---
image: "[[Referenz_Charakter.jpg]]"
Spezies: "[[Mensch]]"
Geboren: 0822-04-04
Fraktion: "[[Marod & Co]]"
Herkunft: "[[Teramons]]"
---

B. Überschriftenhierarchie

## für Hauptüberschriften, ### für Unterkapitel. Keine Ebenen überspringen.
Hauptüberschriften (##) durch eine horizontale Linie (---) vom vorherigen Text trennen.

C. Verlinkungen (Cross-Linking)

Pro Kapitel: Ein Begriff darf einmal pro Kapitel (Abschnitt unter einer ##-Überschrift) verlinkt werden.
Kein Overlinking: Derselbe Begriff wird innerhalb eines Absatzes nie mehrfach verlinkt.
Erneute Verlinkung: Beginnt ein neues Kapitel (##), dürfen wichtige Begriffe erneut verlinkt werden.
Unresolved Links: Leere Links ([[Noch nicht existierender Artikel]]) sind erlaubt, wenn der referenzierte Artikel konkret geplant ist. Spekulative Links zu Themen, die voraussichtlich nie geschrieben werden, sind zu vermeiden.

8. Trennung von Lore und Spielmechanik

D&D-Regelbegriffe (CR, Hit Points, Spell Save DC, Damage Dice) brechen die Immersion und gehören nicht in den Lore-Text.

Lore-Text (Hauptteil des Artikels)

Rein deskriptiv. Magische Effekte werden narrativ beschrieben:

Richtig: „Teleportationsmagie scheitert an der Barriere.”
Richtig: „Die Klinge durchdringt magische Schilde.”
Falsch: „Die Klinge macht 2d6+4 Slashing Damage und ignoriert Resistances.”

Mechanik-Block (am Ende des Artikels)

Unter einer eigenen Überschrift (## Technische Beschreibung oder ## 5e Stats) dürfen alle D&D-Werte, Zauberlisten, DCs und Loot-Tabellen stehen.

Sonderfall: Magische Gegenstände

Bei Artefakten und magischen Gegenständen ist die Mechanik oft ein zentraler Bestandteil. Dennoch gilt: Der Haupttext beschreibt Wirkung und Bedeutung narrativ, der Mechanik-Block am Ende liefert die exakten Spielwerte.

9. Instruktionen für LLMs

Dieser Abschnitt richtet sich an Sprachmodelle (LLMs), die Wiki-Artikel erstellen, bearbeiten oder ergänzen. Er ergänzt alle vorherigen Regeln um maschinenspezifische Anweisungen.

Grundprinzip

Behandle jede Regel in diesem Dokument als verbindliche Einschränkung, nicht als Empfehlung. Im Zweifelsfall gilt: Lieber eine Information weglassen als eine Regel brechen.

Vor dem Schreiben prüfen

Bevor du einen Artikel erstellst oder bearbeitest:

Lies bestehende Artikel im selben Ordner, um Ton, Struktur und Detailtiefe abzugleichen. Ein neuer NPC-Artikel sollte sich an bestehenden NPC-Artikeln orientieren — nicht an Orts- oder Ereignis-Artikeln.
Prüfe Verlinkungsziele. Wenn du auf einen Artikel verlinkst, stelle sicher, dass der Pfad dem tatsächlichen Dateipfad im Vault entspricht. Nutze vollständige Pfade nur, wenn Obsidian dies erfordert oder der Dateiname nicht eindeutig ist — sonst reicht [[Artikelname]].
Erfinde keine Fakten. Wenn dir Informationen fehlen (Jahreszahlen, Orte, Beziehungen), lasse die entsprechenden Felder leer oder markiere sie explizit als unbekannt. Halluzinierte Fakten sind schädlicher als Lücken.

Feature Docs — Interaktive Komponenten

Das Wiki nutzt mehrere interaktive Komponenten, die über fenced Code-Blöcke oder YAML-Properties in Artikel eingebettet werden. Die vollständige technische Dokumentation zu Syntax, Optionen und Beispielen befindet sich im Ordner DnDWiki/98_feature_docs/. Lies die jeweilige Feature Doc, bevor du eine Komponente einsetzt.

Feature Doc	Beschreibung	Einbindung
`familytree.md`	Interaktiver Stammbaum, der Verwandtschaftsbeziehungen aus dem Frontmatter liest.	```familytree Code-Block
`infobox.md`	Wikipedia-artige Sidebar, die automatisch aus dem YAML-Block gerendert wird.	Automatisch bei vorhandenem Frontmatter
`leaflet.md`	Interaktive Karte mit Bild-Overlay und platzierbaren Markern.	```leaflet Code-Block
`variables.md`	Build-Time-Platzhalter (`694` etc.), die mit Vault-Statistiken ersetzt werden.	`{{variableName}}` im Fließtext

YAML-Block

Beginne jeden Artikel mit einem vollständigen YAML-Block.
Setze alle Wikilinks in Anführungszeichen: "[[Link]]".
Verwende das Datumsformat YYYY-MM-DD mit vierstelliger aAG-Jahreszahl.
Lasse Properties weg, die für den Artikeltyp nicht sinnvoll sind, statt sie mit Platzhaltern zu füllen.

Struktur-Template

Orientiere dich beim Aufbau an dieser Reihenfolge (nicht jeder Artikel braucht jeden Abschnitt):

---
[YAML-Block]
---
[Lead: 3–5 Sätze, beantwortet Wer/Was/Wo/Wann/Relevanz]
[Optional: Statuszeile]

---

## Beschreibung
[Aussehen, Charakter, Atmosphäre — was man wahrnimmt]

---

## Geschichte
[Chronologisch, mit aAG-Jahreszahlen verankert]

---

## [Themenspezifische Kapitel]
[z. B. „Beziehungen", „Geografie", „Wirtschaft", „Fähigkeiten"]

---

## Gerüchte und Überlieferungen
[Optional. Nur für In-World-Subjektivität]

---

## Technische Beschreibung
[Optional. Nur für D&D-Mechanik, Stats, Spell-Listen]

Stilregeln für LLMs (Zusammenfassung)

Zeitanker: Jede Zeitangabe braucht einen aAG-Bezug. Nutze nie „heute”, „aktuell”, „kürzlich” ohne Anker.
Perspektive: Allwissend, neutral, dritte Person. Kein „wir”, „du”, „die Spieler”.
Zeitformen: Präsens für Definitionen lebender/existierender Subjekte. Präteritum für Geschichte und für die Identität zerstörter/verstorbener Subjekte.
Fettdruck: Nur den Artikelgegenstand im Lead und maximal 3–6 Scan-Anker im gesamten Artikel.
Verlinkung: Maximal einmal pro Kapitel. Nie mehrfach im selben Absatz.
Mechanik: Nie im Lore-Text. Immer am Ende unter eigener Überschrift.
Keine Erfindungen: Wenn du eine Information nicht hast, schreibe sie nicht. Markiere Lücken oder frage nach.

Bearbeitung bestehender Artikel

Wenn du einen bestehenden Artikel überarbeitest:

Ändere keine Fakten, die du nicht verifizieren kannst.
Behalte die bestehende Struktur bei, es sei denn, sie widerspricht dem Styleguide.
Füge fehlende Zeitanker hinzu, wo möglich.
Korrigiere Verlinkungen nur, wenn du sicher bist, dass der Ziel-Artikel existiert.

Checkliste

Vor dem Speichern eines Artikels:

Orsia Wiki

Explorer