Claude Code macht Obsidian zum zweiten Gehirn

Was ist das Ziel dieses Systems?

Stell dir vor, du hättest eine Bibliothek, in der alle deine Notizen (Rezepte, Autodaten, SQL-Wissen) liegen. Normalerweise müsstest du alles selbst sortieren. Mit diesem System hast du einen intelligenten Bibliothekar (Claude Code), der:

Neue Infos liest und sie an die richtige Stelle einsortiert.
Verbindungen herstellt (z. B. erkennt, dass ein Rezept zu deinem Thermomix passt).
Dir Fragen beantwortet, die auf deinem persönlichen Wissen basieren.

Voraussetzungen (Prerequisites)

Bevor Sie mit der Einrichtung beginnen, müssen folgende Tools auf Ihrem Computer installiert sein:

Obsidian: Die Basis für Ihr Wissensmanagement (obsidian.md).
Node.js: Notwendig, um Claude Code über das Terminal auszuführen (nodejs.org).
VS Code (Visual Studio Code): Empfohlen als Editor, um das Terminal und die Dateien parallel zu verwalten (code.visualstudio.com).
Claude Code: Der KI-Agent von Anthropic (Installation via Terminal: npm install -g @anthropic-ai/claude-code).

Schritt-für-Schritt-Anleitung

1. Obsidian Vault erstellen

Laden Sie Obsidian herunter und installieren Sie es.
Erstellen Sie einen neuen Vault (einen lokalen Ordner auf Ihrem Computer). Im Video wird dieser beispielsweise „Wiki“ genannt.
Merken Sie sich den Speicherort dieses Ordners (z. B. auf Ihrem Desktop).

2. Den Ordner in VS Code öffnen

Öffnen Sie VS Code.
Gehen Sie auf Datei > Ordner öffnen und wählen Sie Ihren soeben erstellten Obsidian-Vault-Ordner aus.
Öffnen Sie das integrierte Terminal in VS Code (Terminal > Neues Terminal).

3. Claude Code im Terminal starten

Tippen Sie im Terminal einfach claude ein, um den KI-Agenten zu starten.
Wichtig: Arnie empfiehlt im Video den Weg über das Terminal/VS Code (anstatt eines Obsidian-Plugins), da dies „Model Agnostic“ ist (man kann leichter zwischen verschiedenen KIs wechseln) und die Limits stabiler gehandhabt werden.

4. Das System-Prompt implementieren (Das Herzstück)

Um die Struktur eines „Zweiten Gehirns“ (nach Andrew Kirby) aufzubauen, benötigt Claude eine klare Arbeitsanweisung.

Kopieren Sie das im Video erwähnte System-Prompt (Arnie stellt dies in seiner Community bereit).

LLM Wiki
A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

The idea here is different. Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then kept current, not re-derived on every query.

This is the key difference: the wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask.

You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

This can apply to a lot of different contexts. A few examples:

Personal: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
Research: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis.
Reading a book: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. By the end you have a rich companion wiki. Think of fan wikis like Tolkien Gateway — thousands of interlinked pages covering characters, places, events, languages, built by a community of volunteers over years. You could build something like that personally as you read, with the LLM doing all the cross-referencing and maintenance.
Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do.
Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives — anything where you're accumulating knowledge over time and want it organized rather than scattered.
Architecture
There are three layers:

Raw sources — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.

The wiki — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.

The schema — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.

Operations
Ingest. You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.

Query. You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: good answers can be filed back into the wiki as new pages. A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.

Lint. Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.

Indexing and logging
Two special files help the LLM (and you) navigate the wiki as it grows. They serve different purposes:

index.md is content-oriented. It's a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.

log.md is chronological. It's an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. ## [2026-04-02] ingest | Article Title), the log becomes parseable with simple unix tools — grep "^## \[" log.md | tail -5 gives you the last 5 entries. The log gives you a timeline of the wiki's evolution and helps the LLM understand what's been done recently.

Optional: CLI tools
At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. qmd is a good option: it's a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code a naive search script as the need arises.

Tips and tricks
Obsidian Web Clipper is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.
Download images locally. In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. raw/assets/). Then in Settings → Hotkeys, search for "Download" to find "Download attachments for current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping an article, hit the hotkey and all images get downloaded to local disk. This is optional but useful — it lets the LLM view and reference images directly instead of relying on URLs that may break. Note that LLMs can't natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately to gain additional context. It's a bit clunky but works well enough.
Obsidian's graph view is the best way to see the shape of your wiki — what's connected to what, which pages are hubs, which are orphans.
Marp is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.
Dataview is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.
The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.
Why this works
The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.

The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else.

The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that.

Note
This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. Everything mentioned above is optional and modular — pick what's useful, ignore what isn't. For example: your sources might be text-only, so you don't need image handling at all. Your wiki might be small enough that the index file is all you need, no search engine required. You might not care about slide decks and just want markdown pages. You might want a completely different set of output formats. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document's only job is to communicate the pattern. Your LLM can figure out the rest.

Du bist jetzt mein LLM-Wiki-Agent. Setze diese exakte Ideendatei als mein zweites Gehirn um. Führe mich Schritt für Schritt durch: Erstelle die Schema-Datei CLAUDE.md mit allen Regeln, richte index.md und log.md ein, definiere Ordnerkonventionen und zeige mir das erste Ingest-Beispiel. Ab jetzt folgt jede Interaktion dem Schema.

Fügen Sie dieses Prompt direkt in das geöffnete Claude-Terminal ein.
Ergebnis: Claude erstellt automatisch eine Ordnerstruktur in Ihrem Obsidian-Vault:
- RAW: Für neue, unverarbeitete Daten.
- Wiki: Der Bereich für das strukturierte Wissen (mit Unterordnern wie Index, Log, Sources, Entities, Concepts).
- Dateien wie cloud.md oder agents.md, die Claude erklären, wie er das Wiki verwalten soll.

5. Den „Obsidian Skill“ installieren (Optional, aber empfohlen)

Um die Zusammenarbeit zwischen Claude und Obsidian zu verbessern, wird im Video ein spezielles Plugin (Skill) installiert:

Nutzen Sie die URL des Repositories (z. B. von Elias Pereira): „Hallo Claude, installiere diesen Skill für mich: https://github.com/elias-pereira/obsidian-skills"
Tippen Sie in Claude: install skill http://zmrepo.zoneminder.com/.
Dieser Skill hilft Claude, Obsidian-spezifische Formate (wie JSON Canvas) besser zu lesen und zu bearbeiten.

6. Datenquelle einrichten: Obsidian Web Clipper

Installieren Sie die Chrome-Erweiterung Obsidian Web Clipper.
Konfigurieren Sie die Erweiterung so, dass Artikel direkt im Ordner RAW Ihres Vaults gespeichert werden.
Wenn Sie nun eine interessante Webseite finden, klicken Sie auf den Clipper, und der Inhalt landet als Markdown-Datei in Ihrem Obsidian.

7. Daten „injizieren“ (Informationen verarbeiten)

Sobald sich neue Dateien im RAW-Ordner befinden, geben Sie Claude den Befehl zur Verarbeitung:

Prompt im Terminal: Injiziere den neuen Artikel.
Was Claude nun tut: 1. Er liest die Datei im RAW-Ordner. 2. Er erstellt Metadaten (Datum, Quelle, Tags). 3. Er verknüpft den Text automatisch mit bestehenden Notizen (Backlinks). 4. Er verschiebt die Informationen in die richtige Kategorie im Wiki-Ordner.

Du kannst alles in die Root von raw/ werfen — ich sortiere beim Ingest automatisch ein. Der Workflow ist:

1. Du droppst eine Datei in raw/ (egal ob Artikel, Notiz oder Buchkapitel)
2. Du sagst mir: „Neue Quelle in raw/ verfügbar“ (oder nennst den Dateinamen)
3. Ich erkenne den Typ, verschiebe die Datei in den richtigen Unterordner und verarbeite sie

Die Unterordner (articles/, notes/, books/, courses/) sind dann nur Archiv für Ordnung — du musst dich nie darum
kümmern.

—
Design — Teil 2: CLAUDE.md Schema (Kern-Regeln)

Das Schema definiert, wie ich als Wiki-Agent arbeite. Die wichtigsten Abschnitte:

Identität & Rolle
Ich bin dein Wiki-Agent. Meine Aufgabe: raw/ lesen, wiki/ schreiben und pflegen. Du liest, ich schreibe.

Ingest-Workflow (wenn du eine neue Quelle einpflegst)
1. Quelle lesen & Typ erkennen (Artikel / Notiz / Buch / Kurs)
2. Kurze Diskussion: Was sind die wichtigsten Erkenntnisse?
3. Summary-Seite in wiki/[domain]/ anlegen
4. Betroffene Hub-Seite(n) aktualisieren
5. Querschnitts-Seiten prüfen / anlegen falls nötig
6. wiki/index.md aktualisieren
7. Eintrag in wiki/log.md appenden

Query-Workflow (wenn du eine Frage stellst)
1. wiki/index.md lesen → relevante Seiten identifizieren
2. Relevante Seiten lesen → Antwort synthetisieren
3. Antwort mit Wiki-Links als Quellen ausgeben
4. Falls wertvoll: Antwort als neue Wiki-Seite speichern

Lint-Workflow (auf Anfrage: „Wiki aufräumen“)
Widersprüche suchen, verwaiste Seiten verlinken, fehlende Hub-Links ergänzen, veraltete Infos markieren

Wichtige technische Einstellungen aus dem Video

Model-Modus: Arnie wechselt gelegentlich mit dem Befehl /model auf das Modell Opus, wenn komplexe strukturelle Änderungen (wie das Erstellen einer Wikipedia-ähnlichen HTML-Ansicht) vorgenommen werden sollen, da dieses über ein größeres Kontextfenster verfügt.
Automatisierung: Durch die Datei agents.md oder cloud.md im Hauptverzeichnis „weiß“ jeder neu gestartete Agent sofort, wie er mit Ihrem spezifischen Wiki umzugehen hat.

Diese Einrichtung ermöglicht es Ihnen, Wissen nicht nur zu sammeln, sondern durch die KI aktiv vernetzen zu lassen – ganz ohne manuelles Sortieren.

Schritt 3: Wissen „injizieren“ (Füttern)

Das ist der magische Moment aus dem Video.

Sammeln: Du nutzt den Obsidian Web Clipper (eine Erweiterung für deinen Chrome-Browser). Wenn du ein tolles Rezept oder einen Artikel über Elektroautos findest, klickst du auf das Symbol und speicherst es direkt in deinen RAW-Ordner in Obsidian.
Verarbeiten: Jetzt gehst du zurück in dein Terminal (in VS Code) und sagst zu Claude:
Prompt: „Injiziere die neuen Dateien aus dem RAW-Ordner in mein Wiki.“
Was passiert dann? Claude liest die Datei, erstellt in deinem Wiki-Ordner eine neue, schöne Notiz, verlinkt sie mit anderen passenden Notizen und löscht (oder verschiebt) die rohe Datei aus dem RAW-Ordner.

Ein anschauliches Beispiel (Extra für dich)

Stell dir vor, du hast zwei Notizen im RAW-Ordner:

Ein PDF-Handbuch für den Cosori Airfryer.
Ein klassisches Rezept von deiner Oma für pikante Fleischpflanzerl.

Du sagst zu Claude: „Injiziere das Wissen.“

Das Ergebnis in Obsidian: Claude erstellt eine Notiz „Omas Fleischpflanzerl“. Automatisch setzt Claude ganz unten einen Link: „Passendes Gerät: [[Cosori Turboblaze Airfryer]]“. Warum? Weil Claude im Handbuch gelesen hat, dass der Airfryer perfekt für Fleischpflanzerl ist. Dein „Gehirn“ hat also eine Verbindung hergestellt, an die du vielleicht gar nicht gedacht hast.

Die wichtigsten Links & Prompts aus dem Video (Zusammenfassung)

Download Obsidian: https://obsidian.md/
Download VS Code: https://code.visualstudio.com/
Obsidian Web Clipper (Chrome): Link im Chrome Web Store
Prompt für neue Inhalte: Injiziere den neuen Artikel von [Name].
Prompt für Aufgaben: Was sind meine aktuellen To-Dos in den Projekten?
Prompt für Stil-Kopie: Schreibe einen Text über [Thema] in meinem persönlichen Schreibstil, den du in meinen Notizen findest.

Teil 2: Dein Workspace-Workflow (`\start`, `\prime`, `\shutdown`)

Da dieses System im Video nicht behandelt wurde, erkläre ich dir hier, wie du diese Befehle als „Meta-Prompts“ nutzt, um deinen Workspace mit Obsidian und Claude professionell zu steuern.

1. `\start` – Die Vorbereitung

Dies ist dein Initialisierungsbefehl. Wenn du diesen Befehl in Claude (innerhalb deines Obsidian-Ordners) eingibst, bereitet sich die KI auf die Arbeit vor.

Was passiert: Claude scannt die Ordnerstruktur, liest deine zentralen Anweisungsdateien (wie agents.md oder cloud.md) und versteht, in welchem Kontext du arbeitest.
Prompt-Beispiel: „\start: Initialisiere den Workspace. Lade die Projektübersicht und meine Todo-Liste. Ich bin bereit für eine neue Session.“

2. `\prime` – Die Wissensaktivierung

Nach dem Start nutzt du \prime, um Claude mit spezifischem Wissen für die aktuelle Aufgabe zu „füttern“.

Was passiert: Du weist die KI an, bestimmte Quellen aus deinem Obsidian-Wiki in den aktiven Arbeitsspeicher (Kontext-Fenster) zu laden.
Anwendung: Wenn du an einem Artikel über Elektroautos arbeitest, sagst du: „\prime: Lade alle Notizen aus dem Ordner Concepts/EV und meinen persönlichen Schreibstil aus Sources/MyStyle.md.“

3. `\shutdown` – Der saubere Abschluss

Bevor du das Terminal schließt, nutzt du diesen Befehl, um den Status zu sichern.

Was passiert: Die KI schreibt eine kurze Zusammenfassung der heutigen Fortschritte in dein Log.md, aktualisiert die Todo-Liste und führt (falls konfiguriert) einen Git-Commit durch, um die Änderungen zu speichern.
Prompt-Beispiel: „\shutdown: Fasse die heutige Session zusammen, aktualisiere die Projekt-Datei und speichere alles via Git.“

Teil 3: Integration des „Superpowers-Skills“

Der Superpowers-Skill (oft als Erweiterung oder tiefgreifender System-Prompt genutzt) verleiht Claude zusätzliche analytische Fähigkeiten, um komplexe Zusammenhänge in deinem Obsidian-Wiki zu finden.

Anleitung für Beginner:

Installation: Stelle sicher, dass du eine Datei namens superpowers.md in deinem Obsidian-Root (Hauptverzeichnis) hast, in der die Regeln des Skills definiert sind (z.B. Tiefenanalyse, kritisches Hinterfragen).
Aktivierung: Rufe den Skill während deiner Session auf.
- Kombination: \prime + Superpowers.
- Prompt: „\prime meine Notizen zu ‚KI-Infrastruktur‘ und nutze den Superpowers-Skill, um logische Lücken in meiner Argumentation zu finden.“
Vorteil: Die KI antwortet nicht mehr nur oberflächlich, sondern agiert als hochkarätiger Berater, der dein gesamtes gespeichertes Wissen im Hinterkopf behält.

Praktisches Beispiel: Dein Szenario

Stell dir vor, du hast Informationen über deinen Cupra Tavascan und die mediterrane Küche in deinem Obsidian gespeichert.

Schritt: Du findest ein neues Rezept für eine pikante Pasta und speicherst es via Web Clipper im Ordner RAW.
Kommando \start: Du öffnest Claude im Terminal.
Kommando \prime: „\prime das neue Rezept und meine ‚Oma-Rezepte‘-Sammlung.“
Aktion mit Superpowers: „Nutze deine Superpowers, um dieses Rezept so umzuwandeln, dass es perfekt für meinen Thermomix TM7 passt und keine schädlichen Zusatzstoffe enthält.“
Ergebnis: Claude erstellt eine neue Markdown-Datei in deinem Wiki, fix und fertig verknüpft mit anderen pikanten Rezepten.
Kommando \shutdown: „\shutdown: Logge die Erstellung des TM7-Rezepts und beende die Session.“

Aufräumen: Unnützes Wissen & falsche Verknüpfungen

Ein digitales Gehirn kann zum „Zettelchaos“ werden, wenn man nicht ab und zu den Besen schwingt. So gehst du vor:

Wissen löschen (Manuell)

Wenn eine Notiz komplett veraltet ist (z.B. ein altes Rezept, das nicht schmeckt):

Rechtsklick auf die Datei im linken Menü.
Löschen wählen.
Hinweis: Obsidian fragt dich, ob du die Datei in den Papierkorb deines Computers verschieben willst.

Falsche Verknüpfungen lösen

Links in Obsidian sind nur Text. Wenn Claude fälschlicherweise eine Verbindung zwischen „Tefal Kontaktgrill“ und „SQL Server 2022“ hergestellt hat:

Gehe in die Notiz.
Suche den Begriff in den eckigen Klammern [[...]].
Lösche einfach die Klammern oder den ganzen Link-Text. Die Verbindung im Graphen verschwindet sofort.

Die KI zum „Hausputz“ nutzen

Das ist der Profi-Weg mit Claude Code. Nutze dein \prime-Kommando:

Prompt: \prime den Ordner Wiki/Concepts. Suche nach Notizen, die keine Verknüpfungen haben oder widersprüchliche Informationen enthalten. Liste mir diese auf, damit ich entscheiden kann, was gelöscht werden soll.

4. Profi-Tipp für Fortgeschrittene: Der „Orphan“-Check

In Obsidian gibt es den Begriff „Orphans“ (Waisen). Das sind Notizen, die mit gar nichts anderem verknüpft sind.

Öffne die Graph-Ansicht (Strg + G).
Klicke auf das Zahnrad (Einstellungen) im Graphen.
Aktiviere unter „Filters“ den Punkt „Orphans“.
Alle Punkte, die einsam in der Gegend herumschweben, sind Kandidaten zum Löschen oder zum besseren Verknüpfen.