KI-Kontext teilen. Was ich von Teresa Torres über Obsidian, Git und Symlinks gelernt habe.

Die meiste Zeit, die wir in KI-Zusammenarbeit investieren, fliesst nicht in Prompts, sondern in Kontext: Regeln, Arbeitsstil, Projekthistorie, Dateien, die die KI kennen muss. Teresa Torres hat kürzlich beschrieben, wie sie diesen Kontext über Geräte hinweg teilt. Die Erkenntnis dahinter ist einfach, aber folgenreich: Kontext und Skills sind die Investition. Das Teilen über Geräte und Teams hinweg ist die Infrastruktur. Wer diese Infrastruktur nicht baut, investiert bei jedem neuen Gerät und jeder neuen Session von vorne.

Das Infrastruktur-Problem

KI-Tools wie Claude Code speichern Kontext lokal: CLAUDE.md-Dateien, Skills, Memory, Projektregeln. Das funktioniert auf einem Gerät, aber sobald ein zweites dazukommt (Arbeitslaptop, privater Rechner, Tablet), bricht die Kontinuität. Absolute Dateipfade funktionieren nicht geräteübergreifend. Skills liegen standardmässig in ~/.claude, einem Verzeichnis, das die meisten Sync-Tools ignorieren. Und auf iOS (wo Obsidian seine Vaults über iCloud oder Obsidian Sync verwaltet) gibt es kein Git, keine Symlinks, keinen Terminal-Zugriff.

Torres beschreibt drei Lösungsansätze, die unterschiedliche Trade-offs haben. Dropbox mit Symlinks: funktioniert zwischen Macs, scheitert an iOS. Git mit einem versionierten Repository: volle Kontrolle, aber manueller Sync (Pull/Push), Merge-Konflikte bei gleichzeitiger Bearbeitung, und auf iOS ohne Third-Party-Apps nicht nutzbar. Obsidian Sync als dritter Weg: einfach, automatisch, funktioniert auf allen Geräten inklusive iOS, nutzt relative Pfade innerhalb des Vaults. Der Nachteil: kein Versionshistorie im Git-Sinne, weniger Kontrolle über den Sync-Zeitpunkt.

Obsidian Sync als pragmatische Wahl

Torres argumentiert, dass Obsidian Sync für die meisten Anwenderinnen der richtige Weg ist, weil es die Komplexität radikal reduziert. Keine Git-Befehle, keine Symlink-Pflege, keine Merge-Konflikte. Notizen, Kontext-Dateien und über Plugins auch KI-Skills synchronisieren sich automatisch über alle Geräte, und die relativen Obsidian-Links funktionieren überall gleich.

Der Wert liegt nicht in den KI-Tools. Er liegt im Kontext, den du ihnen gibst, und in der Fähigkeit, diesen Kontext zu teilen.

Für Teams geht es über individuelle Sync hinaus: Wenn mehrere Personen mit derselben KI arbeiten (etwa in einem Produkt-Team), braucht der geteilte Kontext eine eigene Infrastruktur. Shared CLAUDE.md-Dateien, Team-Skills, gemeinsame Regeln. Torres sieht hier den nächsten Schritt: nicht nur persönlichen Kontext synchronisieren, sondern Team-Kontext als gemeinsame Ressource pflegen.

Obsidian Sync

Einfach

Automatisch, funktioniert auf iOS, relative Pfade, keine Merge-Konflikte. Ideal für Einzelpersonen und kleine Teams.

Git

Volle Kontrolle

Versionshistorie, Branching, Code-Review. Aber: manueller Sync, Merge-Konflikte, kein iOS-Support ohne Workarounds.

Mein eigener Vault-Ansatz im Vergleich

Mein KnowledgeOS läuft auf Git: ein Obsidian-Vault in einem privaten Repository, versioniert, mit Submodulen für öffentliche Projekte (CV-Site, Blog). Das gibt mir volle Kontrolle über die Historie, ermöglicht Code-Workflows (GitHub Pages für Deploy, Claude Code direkt am Repo) und hält alles in einem System. Der Preis: kein automatischer Sync, kein iOS-Zugriff auf den Vault ohne Git-Client, und absolute Pfade in CLAUDE.md, die nur auf meinem Mac funktionieren.

Beim Lesen ist mir aufgefallen, dass ich an ein paar Stellen unbewusst andere Entscheidungen getroffen habe — nicht aus besserem Wissen, sondern weil sich mein Setup über die Zeit so entwickelt hat. Torres legt ihren Kontext im Wesentlichen in einer grossen CLAUDE.md ab. Bei mir hat er sich auf vier Schichten verteilt, sortiert danach, wann Claude sie überhaupt zu sehen bekommt:

Schicht	Wo	Wann geladen	Beispiel
CLAUDE.md	Repo-Root	Automatisch, jede Session	Vault-Regeln, aktive Projekte
Rules	`00_SYSTEM/01_RULES/`	Bei Bedarf, per Verweis	Writing Style Guide, Job-Search-Rules
Skills	`.claude/skills/`	Auf Aufruf, per Slash-Befehl	`/checkin`, `/checkout`, `/artikel`
Memory	`.claude/projects/…/memory/`	Über Sessions hinweg	Kollaborationsmuster, Feedback

Das Schöne daran: meine CLAUDE.md bleibt kurz, die Lade-Kosten niedrig — als Nebenprodukt einer Trennung nach Lade-Semantik, nicht als Optimierung.

Claude Code App als Sweet Spot für unterwegs

Bei mir ist noch ein vierter Weg dazugekommen, den Torres nicht beleuchtet: Wenn der Kontext zentral im Repo lebt, muss ich ihn nicht auf jedes Gerät syncen. Ich brauche nur einen Weg, von jedem Gerät aus auf das Repo zuzugreifen. Genau das löst die Claude-App am iPhone im Claude-Code-Modus für mich. Ich öffne die App, wähle das angebundene Repo, gebe Claude in Alltagssprache einen Auftrag — und Claude arbeitet direkt auf den Dateien meines KnowledgeOS, mit voller Kenntnis der CLAUDE.md und der gesamten Struktur. Im Hintergrund läuft das in einer Sandbox, das Ergebnis kommt als Commit oder Pull Request zurück. Mein iPad braucht keinen Vault-Zugriff, mein iPhone keinen synchronisierten CLAUDE.md-Hash. Beide brauchen nur die Möglichkeit, Claude einen Auftrag zu geben. Der Kontext bleibt da, wo er hingehört: im versionierten Repo, einmal gepflegt, von überall aus nutzbar.

Das ist eine andere Designentscheidung als Torres' Sync-Modell, kein besserer Weg. Torres optimiert auf derselbe Kontext auf jedem Gerät. Ich optimiere auf eine Wahrheit im Repo, Remote-Agents davor. Beides löst das gleiche Problem, nur an einer anderen Stelle. Spannend zu sehen, wie unterschiedlich man dieselbe Frage beantworten kann, wenn die Ausgangslage eine andere ist.

Was ich verändert habe

Torres' Artikel hat mir nicht meine Architektur in Frage gestellt — die Claude-App-Anbindung löst das Geräte-Problem auf einem anderen Weg, und das passt für mich. Aber zwei konkrete Dinge nehme ich mit. Erstens: Ich gehe meine CLAUDE.md systematisch auf absolute Pfade durch, die nur auf meinem Mac funktionieren, und ersetze sie durch relative. Sonst bricht der Kontext jedes Mal, wenn ich in einem Worktree oder auf einem anderen Rechner arbeite. Zweitens — und das kam beim Schreiben dieses Artikels als zweite Einsicht: Ich habe meine Skills sortiert. Beim näheren Hinsehen waren es zwei Sorten, die ich unbewusst gemischt hatte: Workflow-Commands, die Vault-Dateien brauchen (/checkin, /artikel), und Methoden-Skills, die auf jedem Input laufen (/rice, /jtbd). Workflow-Commands bleiben im Vault-Repo, Methoden-Skills wandern nach ~/.claude/skills/ user-global. Damit sind sie in jedem Projekt verfügbar, ohne Symlinks oder Sync. Torres' Symlink-Pool hätte das gleiche Problem gelöst; der Split ist die einfachere Antwort. Langfristig denke ich über geteilte Kontext-Dateien für Team-Zusammenarbeit nach, etwa wenn mehrere Personen an einem Projekt arbeiten und dieselben KI-Regeln nutzen sollen.

Obsidian Sync ist für mich keine Alternative zu Git, sondern könnte es ergänzen — aber für einen anderen Zweck: Notizen am iPhone lesen und festhalten, nicht KI-Kontext syncen. Das sind zwei verschiedene Probleme, und ich will sie nicht in eine Lösung quetschen.

Kritische Einordnung

Obsidian Sync löst das Problem für Einzelpersonen, aber nicht für Teams mit unterschiedlichen Toolchains. Nicht alle arbeiten in Obsidian, nicht alle nutzen Claude. In gemischten Teams braucht geteilter KI-Kontext ein Format, das tool-agnostisch ist (Markdown-Dateien in einem Shared Drive, etwa). Ausserdem: Der Aufwand für Kontext-Pflege kann zum Selbstzweck werden. Torres warnt implizit davor, mehr Zeit in die Infrastruktur zu investieren als in die eigentliche Arbeit. Die Frage bleibt, ob die KI-Tool-Landschaft sich so stabilisiert, dass sich langfristige Infrastruktur-Investitionen lohnen. Was bleibt, sind gut strukturierte, KI-lesbare Markdown-Dateien und gute Regelwerke, die auch andere KIs lesen können.

Was bleibt für jeden Tag

Investiere in Kontext, nicht in Prompts.

Die CLAUDE.md, die deine Arbeitsweise beschreibt, ist wertvoller als jeder einzelne Prompt.

Mach deinen KI-Kontext portabel.

Relative Pfade, modulare Skills, geräteübergreifender Sync. Jede Minute spart zehn.

Denke Team-Kontext mit.

Wenn andere deine KI-Regeln nutzen sollen, brauchen sie ein Format, das nicht an dein Setup gebunden ist.

Quellen

Glossar

CLAUDE.md — Konfigurationsdatei, die Claude Code bei jedem Session-Start automatisch liest

Skills — Wiederverwendbare KI-Workflows, gespeichert als SKILL.md-Dateien

Symlink — Symbolischer Link: Verknüpfung, die auf eine Datei an anderem Ort verweist

Obsidian Sync — Verschlüsselter Sync-Dienst für Obsidian-Vaults über alle Geräte

KnowledgeOS — Persönliches Wissensmanagementsystem in Obsidian (Linjas Vault)

KI-Kontext — Gesamtheit aus Regeln, Memory, Skills und Projektdateien, die eine KI kennt

Most of the time we invest in AI collaboration does not flow into prompts, but into context: rules, work style, project history, files the AI needs to know. Teresa Torres recently described how she shares this context across devices. The underlying insight is simple but consequential: context and skills are the investment. Sharing them across devices and teams is the infrastructure. Anyone who does not build this infrastructure invests from scratch with every new device and every new session.

The infrastructure problem

AI tools like Claude Code store context locally: CLAUDE.md files, skills, memory, project rules. That works on one device, but as soon as a second one shows up (work laptop, personal machine, tablet), continuity breaks. Absolute file paths do not work across devices. Skills by default live in ~/.claude, a directory most sync tools ignore. And on iOS (where Obsidian manages its vaults via iCloud or Obsidian Sync) there is no Git, no symlinks, no terminal access.

Torres describes three approaches with different trade-offs. Dropbox with symlinks: works between Macs, fails on iOS. Git with a versioned repository: full control, but manual sync (pull/push), merge conflicts on concurrent edits, and not usable on iOS without third-party apps. Obsidian Sync as a third path: simple, automatic, works on all devices including iOS, uses relative paths within the vault. The downside: no Git-style version history, less control over sync timing.

Obsidian Sync as a pragmatic choice

Torres argues that for most users, Obsidian Sync is the right path because it radically reduces complexity. No Git commands, no symlink upkeep, no merge conflicts. Notes, context files, and, via plugins, AI skills sync automatically across all devices, and the relative Obsidian links work the same everywhere.

The value does not sit in the AI tools. It sits in the context you give them, and in the ability to share that context.

For teams, it goes beyond individual sync: when multiple people work with the same AI (say, in a product team), the shared context needs its own infrastructure. Shared CLAUDE.md files, team skills, common rules. Torres sees the next step here: not just syncing personal context, but maintaining team context as a shared resource.

Obsidian Sync

Simple

Automatic, works on iOS, relative paths, no merge conflicts. Ideal for individuals and small teams.

Git

Full control

Version history, branching, code review. But: manual sync, merge conflicts, no iOS support without workarounds.

My own vault approach in comparison

My KnowledgeOS runs on Git: an Obsidian vault in a private repository, versioned, with submodules for public projects (CV site, blog). That gives me full control over history, enables code workflows (GitHub Pages for deploy, Claude Code directly on the repo), and keeps everything in one system. The price: no automatic sync, no iOS access to the vault without a Git client, and absolute paths in CLAUDE.md that only work on my Mac.

While reading the article, I noticed that in a few spots I had unconsciously made different choices, not out of better judgment, but because my setup had evolved that way over time. Torres essentially keeps her context in one large CLAUDE.md. For me it has spread across four layers, sorted by when Claude actually sees them:

Layer	Where	When loaded	Example
CLAUDE.md	Repo root	Automatic, every session	Vault rules, active projects
Rules	`00_SYSTEM/01_RULES/`	On demand, by reference	Writing Style Guide, Job Search Rules
Skills	`.claude/skills/`	On call, by slash command	`/checkin`, `/checkout`, `/artikel`
Memory	`.claude/projects/…/memory/`	Across sessions	Collaboration patterns, feedback

The nice part: my CLAUDE.md stays short, loading costs stay low, as a byproduct of splitting by load semantics, not as an optimization.

Claude Code App as sweet spot on the go

A fourth path has emerged for me that Torres does not cover: if the context lives centrally in the repo, I do not need to sync it to every device. I just need a way to reach the repo from any device. That is exactly what the Claude app on iPhone in Claude Code mode solves for me. I open the app, pick the connected repo, give Claude a task in everyday language, and Claude works directly on the files of my KnowledgeOS, with full knowledge of CLAUDE.md and the whole structure. In the background this runs in a sandbox, the result comes back as a commit or pull request. My iPad does not need vault access, my iPhone does not need a synced CLAUDE.md hash. Both only need the ability to hand Claude a task. Context stays where it belongs: in the versioned repo, maintained once, usable from anywhere.

This is a different design choice than Torres' sync model, not a better one. Torres optimizes for the same context on every device. I optimize for one source of truth in the repo, remote agents in front of it. Both solve the same problem, just at a different spot. It is interesting to see how differently you can answer the same question when the starting point is different.

What I changed

Torres' article did not put my architecture in question, because the Claude-app connection solves the device problem in a different way, and that fits me. But I am taking two concrete things with me. First: I systematically walk through my CLAUDE.md for absolute paths that only work on my Mac, and replace them with relative ones. Otherwise context breaks every time I work in a worktree or on a different machine. Second, and this emerged as a second insight while writing the article: I sorted my skills. On closer inspection there were two kinds I had been unconsciously mixing: workflow commands that need vault files (/checkin, /artikel), and method skills that work on any input (/rice, /jtbd). Workflow commands stay in the vault repo, method skills move to ~/.claude/skills/ user-global. This way they are available in every project, without symlinks or sync. Torres' symlink pool would have solved the same problem; the split is the simpler answer. Longer term, I am thinking about shared context files for team collaboration, for example when several people work on the same project and should use the same AI rules.

Obsidian Sync is not an alternative to Git for me, it could complement Git, but for a different purpose: read and capture notes on iPhone, not sync AI context. Those are two different problems, and I do not want to squeeze them into one solution.

Critical assessment

Obsidian Sync solves the problem for individuals, but not for teams with mixed toolchains. Not everyone works in Obsidian, not everyone uses Claude. In mixed teams, shared AI context needs a format that is tool-agnostic (Markdown files in a shared drive, for example). On top of that: context maintenance can become an end in itself. Torres implicitly warns against investing more time in infrastructure than in the actual work. The question remains whether the AI tool landscape will stabilize enough to justify long-term infrastructure investments. What stays are well-structured, AI-readable Markdown files and good rule sets that other AIs can also read.

What stays with you every day

Invest in context, not in prompts.

The CLAUDE.md that describes how you work is worth more than any single prompt.

Make your AI context portable.

Relative paths, modular skills, cross-device sync. Every minute saves ten.

Think team context in.

If others should use your AI rules, they need a format that is not tied to your setup.

Sources

Glossary

CLAUDE.md — Configuration file that Claude Code reads automatically at every session start

Skills — Reusable AI workflows stored as SKILL.md files

Symlink — Symbolic link: a reference that points to a file at another location

Obsidian Sync — Encrypted sync service for Obsidian vaults across all devices

KnowledgeOS — Personal knowledge management system in Obsidian (Linja's vault)

AI context — The totality of rules, memory, skills, and project files that an AI knows