> ## Content Index > Fetch the complete content index at: https://t01.li/llms.txt > Use this file to discover other available public pages before exploring further. # Die neuen Claude-Projekte: Koordinator, Threads und Anweisungen konfigurieren - URL: https://t01.li/ki-alltag/claude-projekte-koordinator-threads-anleitung/ - Published: 2026-10-05T06:09:41.000Z - Updated: 2026-10-05T21:01:40.000Z - Description: Claudes neue Projekte verteilen Arbeit über einen Koordinator an Threads in der Cloud. Wie sich Ziel, Projektanweisungen und CLAUDE.md sauber trennen lassen – und warum der lokale MCP erst mal weg ist. - Author: Tobias Glawe - Tags: KI Alltag Anthropic rollt die neuen Claude-Projekte gerade nach und nach aus, offiziell noch als Beta und jetzt hat es mich auch erwischt. Ich habe in der *Claude Desktop App* etwas vorschnell auf den Knopf zum Umstellen geklickt, ein paar Minuten später waren meine bestehenden Projekte konvertiert. Was danach kam, war eine komplett neue Projektstruktur mit geänderten Routinen – und am Anfang eine ordentliche Portion Frust. Der Frust hatte einen Namen: mein Obsidian-Projekt. Das lebt davon, dass Claude über einen lokalen MCP-Server direkt in meinen Vault „reinarbeiten“ kann und genau das funktionierte nach der Umstellung nicht mehr. Ein Blick in die Doku hätte gereicht, um zu verstehen, warum. Claude selbst hat mich auch nicht darauf hingewiesen, das wollte lieber Computer Use ausprobieren (ich aber nicht). [RTFM](https://en.wikipedia.org/wiki/RTFM?ref=t01.li), predige ich regelmäßig, aber selbst – reden wir nicht darüber. Deshalb hier das How-to, das ich gern vorher gelesen hätte, entlang der drei Fragen, die ich mir nach dem ersten Ärger gestellt habe: Was gehört ins Ziel für den Koordinator, worauf kommt es bei den Projektanweisungen an, und was unterscheidet die eigentlich von einer CLAUDE.md? Am Ende steht, wie ich ein Projekt heute aufsetze. ## TL;DR Die neuen Claude-Projekte bestehen aus einem Koordinator, der Aufgaben als Threads verteilt. Diese Threads laufen standardmäßig in der Cloud und sehen keine MCP-Server, die nur lokal installiert sind. - Ins Ziel gehört ein Satz, an dem sich messen lässt, ob das Projekt seinen Job macht. Regeln gehören woandershin. - Die Projektanweisungen (bis 16.000 Zeichen) sind das Briefing für jeden neuen Thread und für den Koordinator. Änderungen erreichen nur neue Threads. - Die CLAUDE.md gilt für ein Repository, die Projektanweisungen fürs ganze Projekt. Beide landen zusammen im Kontext, eine feste Rangfolge gibt es nicht, also sollte sie ausgeschrieben sein. Ins Memory schreibt Claude, was es unterwegs lernt. - Lokale Tools gibt es nur in Threads, die per Remote Control auf dem eigenen Rechner laufen. Die laden die Projektanweisungen, aber nicht das Memory. - Standard ist *Opus* überall. Für Fleißarbeit reicht pro Thread oft ein kleineres Modell. ## Vom Ordner zum Gespräch ![Benutzeroberfläche eines Claude-Projekts mit konfigurierbarem Kontext, Anweisungen und Datei-Bibliothek.](https://t01.li/content/images/2026/10/claude-projekte-uebersicht.webp) Die neuen Projekte in der Claude Desktop App Früher war ein Projekt im Kern ein Ordner: Dateien rein, Anweisungen drüber, Chats darunter. Anthropic nennt den Umbau im [Blogpost zum Start](https://claude.com/blog/projects-redesigned?ref=t01.li) passenderweise „from folder to conversation“. Ein Projekt ist jetzt eine lange laufende Unterhaltung mit einem Koordinator, der Aufträge entgegennimmt, entscheidet, was ein eigener Thread wird, und den Überblick behält, wer woran arbeitet. Die Threads machen die eigentliche Arbeit – jeder mit eigenem Kontextfenster – und melden sich zurück, wenn sie fertig sind oder etwas brauchen. Beim Anlegen gibt es Name, Icon (auf Wunsch sogar mit eigener Farbe) und ein Ziel. Für den Koordinator lassen sich Modell und Effort festlegen und, das ist wirklich neu, für die Threads getrennt davon noch einmal. Dazu weiter unten mehr. Laut [Projekt-Doku](https://code.claude.com/docs/en/claude-projects?ref=t01.li) läuft das Ganze als öffentliche Beta für Pro und Max, ausgerollt wird schrittweise (Team und Enterprise müssen noch warten). Projekte gibt es in der Desktop App, im Browser unter claude.ai/code und in der mobilen App, im Terminal und in den IDE-Plugins dagegen nicht. ## Die Falle: Threads laufen in der Cloud Jeder Thread ist standardmäßig eine [Cloud-Session](https://code.claude.com/docs/en/claude-code-on-the-web?ref=t01.li), also *Claude Code* auf Anthropics Infrastruktur statt auf dem eigenen Rechner. Das hat seinen Charme: Threads arbeiten weiter, wenn der Laptop zu ist, und lassen sich vom Smartphone aus in die Rippen stoßen. Der Preis dafür steht unmissverständlich in der Doku – Cloud-Threads haben keine Skills, [MCP-Server](https://t01.li/glossar/#mcp), Plugins und Tools, die nur lokal installiert sind. Genau in diese Falle bin ich reingelaufen. In meinem frisch umgewandelten Obsidian-Projekt hatte ich schlicht keinen lokalen Ordner ausgewählt, also lief jeder Thread in der Cloud, und der [MCP-Zugriff auf den Vault](https://t01.li/kein-ki/obsidian-mcp-claude-code-codex-antigravity/), den ich mir lokal eingerichtet habe, war weg. Dabei regeln die Projektanweisungen, welche Art von Information in welchen Ordner gehört, wo bestimmte Dateien liegen und wie mein Frontmatter aussieht – ohne Vault-Zugriff ist das nichts mehr wert. Damit war erst einmal das ganze Projekt hinfällig (die schönsten Regeln zur Ordnerstruktur helfen wenig, wenn der Thread das Haus gar nicht betreten darf). Claudes Vorschlag zur Güte war unter anderem *Computer Use*, also Screenshots, Mausklicks und Tippen auf meinem Desktop. Funktioniert irgendwie, aber wenn die Alternative ein MCP-Server oder ein CLI-Zugriff ist, fühlt sich das an wie Dampflok gegen ICE. Über Token-Effizienz reden wir erst einmal gar nicht. Was in der Cloud weiter funktioniert, sind die offiziellen Connectors des claude.ai-Kontos – technisch ebenfalls MCP-Server, nur eben remote. Jeder Cloud-Thread kann sie ohne Einrichtung pro Projekt nutzen und im laufenden Thread über das Plus-Menü einzeln an- oder abschalten. Zwei Details stehen im Kleingedruckten. Wer dort einen Connector abschaltet, ändert gleich den Konto-Standard, der dann auch für neue Threads und normale Chats gilt. Und der Koordinator selbst hat gar keine Connectors, Arbeit mit Connector läuft deshalb immer als Thread. ### So kommt ein Thread auf den eigenen Rechner Lokale Tools gibt es nur, wenn der Thread auf dem eigenen Rechner läuft, und dafür nutzt das Projekt Remote Control. Laut Doku kombiniert ein Projekt beides: Die Threads laufen in der Cloud, und wenn einer lokal arbeiten soll, übernimmt Remote Control. In der Desktop App sind es [zwei Schritte](https://code.claude.com/docs/en/claude-projects?ref=t01.li#run-a-thread-on-your-own-computer): 1. Unter **Einstellungen** \> **Claude Code** den Schalter „**Nutze diesen Computer von deinem Telefon und claude.ai aus**“ einschalten und den Ordner, den die Aufgabe braucht, in die Liste darunter aufnehmen. Voraussetzung ist *Claude Code* ab Version 2.1.280. 2. In den **Projekteinstellungen** unter **Umgebung** \> „**Vorab freigegebene Ordner**“ einen oder mehrere Projektordner auswählen. ![Einstellungsmenü eines Claude-Projekts mit Feldern für Projektziel und Konfiguration des Koordinatormodells.](https://t01.li/content/images/2026/10/claude-projekte-settings-1.webp) Projekteinstellungen in der Claude App Danach ist der Thread eine Claude-Code-Session in genau diesem Ordner, mit den Dateien, Tools und MCP-Servern des Rechners und dessen Claude-Code-Settings samt Hooks und Permission-Regeln. Laut [Desktop-Doku](https://code.claude.com/docs/en/desktop?ref=t01.li) reicht die Desktop App lokalen Sessions auch die MCP-Server aus ihrer `claude_desktop_config.json` durch. In meinem Obsidian-Projekt habe ich den Projektordner vorab in den Projekteinstellungen freigegeben, seitdem taucht dort der Obsidian-MCP im Thread wieder auf. Ob ein Thread lokal läuft, entscheidet trotzdem der Koordinator. Im Zweifel hilft ein Satz in der Aufgabe, dass sie auf dem eigenen Rechner laufen soll. ![Konfiguration in der Claude App für die Projektanweisungen. ](https://t01.li/content/images/2026/10/claude-projekte-speicher-1.webp) Projektanweisungen in der Claude App Ein paar Nebenwirkungen gehören dazu: Der lokale Thread läuft im [Auto Mode](https://t01.li/ai-dev/claude-code-auto-mode-default/) und führt Befehle in dem Ordner ohne Rückfrage aus (ist Auto Mode auf dem Rechner aus, landen die Rückfragen im Thread). Er läuft nur, solange der Rechner wach und die App offen ist – in den Einstellungen gibt es dafür einen eigenen Schalter, der den Rechner für Remote Control wach hält. Ist im Konto die Beschränkung auf vertrauenswürdige Geräte aktiv, gibt es gar keine lokalen Threads. Und, für mich der wichtigste Punkt: Er startet mit den Projektanweisungen, aber ohne die Memory-Dateien des Projekts. ## Frage 1: Was gehört ins Ziel des Koordinators? Im Zielfeld hätte ich laut Oberfläche 8.000 Zeichen Platz. Die Doku beschreibt das Ziel dagegen als eine Zeile, und ihr Beispiel ist entsprechend knapp: „Hold p95 API latency under 200 ms“. Darauf arbeitet der Koordinator hin, ohne Ziel arbeitet er einfach ab, was reinkommt. Ich halte mich an die eine Zeile (vielleicht auch eine zweite oder dritte) und nicht an die 8.000 Zeichen. Wie viel vom Zielfeld intern in jeden Kontext wandert, dokumentiert Anthropic nicht, aber „In der Kürze liegt die Würze“ ist hier mehr als eine Stilfrage. Das Ziel ist kein zweites Anweisungsfeld, sondern die Antwort auf die Frage, woran sich messen lässt, ob das Projekt seinen Job macht – ein bisschen wie beim Prompting. Die Koordination selbst (wie viele Threads gleichzeitig, wann Rückfragen, welches Modell für was) läuft übers Gespräch. Anthropic nennt Sätze wie „Propose threads and wait for my go-ahead before starting them“, „Run at most two threads at a time“ oder „Do this task with a smaller model“, und Claude legt solche Vorlieben selbst im Projekt-Memory ab. Vorlieben sind allerdings keine harten Grenzen. Was wörtlich und ab dem ersten Thread gelten soll, gehört deshalb in die Projektanweisungen. ## Frage 2: Worauf achte ich bei den Projektanweisungen? Die Projektanweisungen sind das Briefing, mit dem jeder neue Thread startet, und auch der Koordinator bekommt sie. Platz gibt es für bis zu 16.000 Zeichen unter **Projekteinstellungen** \> **Speicher** \> **Projektanweisungen**. Anthropic empfiehlt fünf Inhalte: wofür das Projekt da ist, wo die Arbeit passiert, wie ein Thread seine Arbeit prüft, bevor er sie für erledigt erklärt, was er tut, wenn ihm etwas fehlt, und was eine Freigabe braucht. Der vierte Punkt hätte mir einiges an Frust erspart. Das Beispiel aus der Doku sagt es so: > If you can't reach something you need, such as a repository, a secret, an API, or a connector, say exactly what's missing in your first message and stop. Don't substitute, mock, or guess. Mit so einem Satz in den Anweisungen hätte mein Obsidian-Thread sofort gemeldet, dass er den Vault nicht erreicht, statt mir kreative Umwege anzubieten. Drei Dinge gehören noch dazu. Änderungen an den Anweisungen erreichen nur neue Threads, laufende arbeiten mit dem alten Stand weiter. Lokale Threads bekommen die Anweisungen, aber nicht das Memory – was auch auf dem eigenen Rechner gelten muss, gehört in die Anweisungen. Und 16.000 Zeichen sind ein Limit, kein Soll. Jede Zeile landet in jedem Thread und beim Koordinator, kostet Tokens und konkurriert um Aufmerksamkeit – bei der [CLAUDE.md](https://t01.li/ai-dev/claude-md-best-practice-2026/) habe ich das schon durchgekaut, je mehr Instruktionen, desto weniger davon werden befolgt. Für Projektanweisungen gibt es dazu keine eigene Messung, ich sehe aber keinen Grund, warum es hier anders laufen sollte. Wer wie ich ein Projekt konvertiert hat, sollte die übernommenen Anweisungen einmal gegenlesen. Bei mir hat die Umstellung Dateien, Memory und die alten Chats mitgenommen. Die Anweisungen waren für Chats geschrieben, in denen ich danebensitze, nicht für Threads, die allein loslaufen und erst am Ende berichten. ## Frage 3: Projektanweisungen, CLAUDE.md und Memory – wer lädt was? In einem Projekt kommen drei Ebenen zusammen, die sich auf den ersten Blick ähneln. Die Doku zieht die Grenze in einem Satz: Anweisungen zu einem Repository gehören in dessen CLAUDE.md, Notizen zum Projekt ins Projekt-Memory. Die Projektanweisungen liegen darüber und gelten für alles. | | Projektanweisungen | CLAUDE.md | Projekt-Memory | | -------------- | ----------------------------------------------- | ------------------------------------------- | ------------------------------------------ | | Wer schreibt | Nutzer | Nutzer | Claude, auf Zuruf oder selbst | | Gilt für | das ganze Projekt, Koordinator und neue Threads | ein Repository, auch außerhalb des Projekts | das Projekt | | Liegt | in den Projekteinstellungen | im Repository | in den Projekteinstellungen unter Speicher | | Lokaler Thread | lädt sie | lädt sie aus dem Ordner | lädt es nicht | | Gehört rein | Zweck, Arbeitsweise, Prüfschritte, Freigaben | Build-Befehle, Code-Konventionen | Entscheidungen, Fallstricke, Korrekturen | Der praktische Unterschied liegt in der Reichweite. Eine [CLAUDE.md](https://t01.li/glossar/#agentic-instruction-file) reist mit dem Repository und wirkt im Terminal, in jeder anderen Session und bei jedem, der das Repo klont. Projektanweisungen existieren nur im Projekt. Praktische Faustregel: Betrifft eine Regel den Code, kommt sie in die CLAUDE.md, betrifft sie die Arbeitsweise in diesem Projekt, kommt sie in die Anweisungen. Jeder Cloud-Thread klont alle Repositories des Projekts und lädt CLAUDE.md und Skills aus allen. Spannend wird es bei dem, was in `.claude/settings.json` steckt. Permission-Regeln, Hooks und `env` greifen nur, wenn das Projekt genau ein Repository hat, bei mehreren Repos gilt keine davon – dauerhafte Regeln wandern dann in die Projektanweisungen und Umgebungsvariablen in die Cloud-Umgebung. Plugins, die ein Repo in seiner `settings.json` aktiviert, laden in Cloud-Threads nie (die gehören in die Projekteinstellungen unter Plugins). Skills dagegen lassen sich ins Repo committen (`.claude/skills//SKILL.md`), dann hat sie jeder Cloud-Thread. Und ohne Repository, wie bei meinen Vault-Projekten? Dann gibt es in der Cloud auch keine CLAUDE.md (eine CLAUDE.md, die nur als Datei in der Library liegt, lädt nach meiner Lesart der Doku kein Thread von selbst, denn als Quelle nennt sie ausschließlich die Repositories), und alles hängt an Anweisungen, [Memory](https://t01.li/glossar/#memory) und den Dateien in der Library. Bei Letzteren lohnt das Kleingedruckte. Uploads sind Kopien, ein Ordner kommt mit höchstens den ersten 100 Dateien und 200 MB an, und was sich danach lokal ändert, erreicht das Projekt erst beim nächsten Upload. Einen lebenden Obsidian-Vault ersetzt das nicht. Beim Memory hilft eine Angewohnheit, die die Doku selbst empfiehlt: Wer einen Thread korrigiert, sagt Claude gleich dazu, dass es sich die Korrektur merken soll. Dann landet sie im Memory, und spätere Cloud-Threads starten damit. Der Koordinator braucht das Memory ohnehin, weil er nicht mit der vollen Historie arbeitet, sondern mit den letzten Nachrichten, den letzten Threads und eben dem Memory. Was nie verloren gehen darf, gehört ins Memory – und wenn es auch lokal gelten muss, zusätzlich in die Anweisungen. ### Wenn CLAUDE.md und Projektanweisungen aufeinandertreffen Hängt ein Repository am Projekt, startet jeder Cloud-Thread mit beidem im Kontext, ein lokaler Thread in einem Ordner mit eigener CLAUDE.md ebenso. Keine der beiden Ebenen ersetzt die andere, Claude bekommt sie zusammen. Eine Rangfolge zwischen Projektanweisungen und CLAUDE.md legt die Projekt-Doku nicht fest. Für die verschiedenen CLAUDE.md-Ebenen untereinander (Organisation, Benutzer, Projekt) wird die [Doku](https://code.claude.com/docs/en/agent-sdk/claude-code-features?ref=t01.li) deutlicher: Alle Ebenen werden addiert, eine harte Vorrangregel gibt es nicht, und bei Widersprüchen hängt das Ergebnis davon ab, wie Claude die Anweisungen auslegt. Ich gehe davon aus, dass das für die Projektanweisungen genauso gilt – belegt ist es nicht. Daraus folgt als Erstes, dass nichts doppelt und erst recht nichts gegensätzlich in beiden Dateien stehen sollte. Verlangt die CLAUDE.md eines Repos „Tests mit pytest“ und die Projektanweisungen „vor dem Abschluss `npm test`“, entscheidet Claude im Zweifel selbst, welche Regel gewinnt – und nicht unbedingt so, wie ich es gemeint habe. Wer Überschneidungen nicht ausschließen kann, schreibt die Rangfolge aus, so wie es die Doku für CLAUDE.md-Dateien empfiehlt. Ein Satz in den Projektanweisungen wie „Bei Code-Konventionen gilt die CLAUDE.md des jeweiligen Repositorys, bei Arbeitsweise und Freigaben gelten diese Anweisungen“ nimmt Claude die Auslegung ab. Zweitens zählt jedes Repo mit, auch wenn die Aufgabe es gar nicht berührt. Jeder Cloud-Thread lädt beim Start die CLAUDE.md aller Projekt-Repos, und zusammen mit bis zu 16.000 Zeichen Projektanweisungen konkurriert das alles um dieselbe Aufmerksamkeit. Die Doku rät deshalb, nur die ein oder zwei Repositories ins Projekt zu nehmen, die fast jede Aufgabe braucht, und die übrigen in den Projektanweisungen zu benennen. Ein Thread holt sie sich dann bei Bedarf selbst, allerdings mitten in der Aufgabe, und deren CLAUDE.md war beim Start nicht geladen. Drittens verliert bei mehreren Repos die `settings.json` ihre Wirkung, und damit der Teil, der Regeln mechanisch durchsetzt. Was in einem einzelnen Repo per Permission-Regel oder Hook verboten war, steht bei zwei Repos nur noch als Satz in den Projektanweisungen. Ein Satz ist eine Bitte, keine Sperre. Wer sich bisher auf eine Deny-Regel verlassen hat, sollte das wissen, bevor er das zweite Repository hinzufügt. Viertens bringen lokale Threads noch mehr Ebenen mit. Ein Thread auf dem eigenen Rechner ist eine gewöhnliche Claude-Code-Session im freigegebenen Ordner. Er startet mit den Projektanweisungen und lädt – das leite ich aus dem üblichen Verhalten von Claude Code ab, die Projekt-Doku sagt es nicht ausdrücklich – zusätzlich die CLAUDE.md des Ordners und der Ordner darüber, die persönliche `~/.claude/CLAUDE.md` sowie Hooks und Permission-Regeln des Rechners. Projektanweisungen, die auf die Cloud zugeschnitten sind (Pfade unter `/mnt/project-files`, „Ergebnisse in die Library legen“), laufen dort ins Leere oder beißen sich mit der lokalen CLAUDE.md. In meinen Anweisungen steht darum ausdrücklich, was in der Cloud gilt und was auf dem Mac. Bleibt der Zeitpunkt. Geänderte Projektanweisungen erreichen nur neue Threads. Die CLAUDE.md liest ein Cloud-Thread aus seinem frischen Klon, eine Änderung wirkt nach meinem Verständnis also erst, wenn sie im Repository auf GitHub liegt – lokal gespeichert und nicht gepusht sieht sie kein Cloud-Thread. ![Konfigurationsfenster in der Claude App von Projekten im Umgebungs-Tab.](https://t01.li/content/images/2026/10/claude-projekte-umgebung-1.webp) Umgebung in den Einstellungen für Projekte ## Opus koordiniert, Haiku schleppt Ab Werk läuft ein neues Projekt überall mit *Opus*, die Threads mit hohem Effort, der Koordinator mit niedrigem. Die Doku warnt ausdrücklich, dass *Opus* auf hohem Effort in jedem Thread den Plan am schnellsten aufbraucht. Umso spannender ist die neue Trennung. Ich kann mit *Opus* oder *Fable* koordinieren und für Aufgaben mit wenig Anspruch einfach *Haiku* oder *Sonnet* draufwerfen. Für einen einzelnen Thread reicht ein Satz in der Aufgabe, ein laufender Thread hat seinen eigenen Model Picker. Den [Effort](https://t01.li/glossar/#reasoning-effort) sollte man dabei nicht vergessen. Wie schon bei [Sonnet 5.5](https://t01.li/ki-news/claude-sonnet-5-5-benchmarks-preis-agenten/) hängt der Kostenvorteil des kleineren Modells am Effort-Level, und auf Max-Effort frisst auch ein Sonnet Tokens, als gäbe es kein Morgen. Für den Koordinator ist niedriger Effort plausibel, er liest vor allem Berichte und verteilt Arbeit. Überhaupt gehen Projekte an die Limits. Jeder Thread ist eine vollwertige Session, mehrere laufen parallel, und der Koordinator verbraucht beim Lesen der Berichte eigene Tokens – laut Doku stoßen gerade Pro-Nutzer früher ans Limit. Hart begrenzt sind 200 neue Threads pro Tag über alle Projekte, ein Projekt ohne laufende Threads, ohne beobachtete Pull Requests und ohne neue Nachrichten kostet dagegen nichts. Vor dem ersten großen Batch lohnt ein Blick auf die Thread-Modelle, erst recht für alle, die ohnehin [auf Token-Effizienz achten](https://t01.li/ai-dev/token-effizienz-in-claude-code-was-hilft/). ## Was sonst noch dazukam Ein paar Einstellungen sind neu oder haben sich verschoben: - **Pausieren** stoppt alles auf einmal. Laufende Threads und der Koordinator werden unterbrochen, Routinen laufen nicht, und Nachrichten nimmt das Projekt erst nach dem Fortsetzen wieder an. - **Archivieren** blendet das Projekt aus und archiviert seine Threads, die sich nach dem Zurückholen nur einzeln wiederherstellen lassen. - **Löschen** entfernt das Projekt samt Threads, Memory und Dateien, endgültig. Branches und Pull Requests auf GitHub bleiben. - **Umgebung** bündelt die GitHub-Repositories und eine eigene [Cloud-Umgebung](https://code.claude.com/docs/en/claude-code-on-the-web?ref=t01.li) mit Netzwerkzugriff, Umgebungsvariablen und Setup-Skript. - **API-Credentials** lassen sich auf Pro und Max in der Cloud-Umgebung hinterlegen. Sessions nutzen sie, ohne sie zu sehen – anders als Umgebungsvariablen, die jeder mit Zugriff auf die Umgebung lesen kann. Ein Projekt gehört übrigens genau einer Person, Teilen (auch einzelner Threads) funktioniert in der Beta (noch) nicht. ## Best Practice: So setze ich ein Claude-Projekt auf Aus Doku und eigenem Frust ist bei mir eine feste Reihenfolge entstanden, nach der ich neue und konvertierte Projekte aufsetze (die Reihenfolge ist Absicht, jeder Schritt baut auf dem vorherigen auf). 1. **Erst der Arbeitsort, dann der Rest.** Bevor ich eine Zeile Anweisungen schreibe, kläre ich, wo die Arbeit passiert. Braucht sie lokale MCP-Server, Dateien oder Tools, gebe ich den Ordner in der Desktop App und in den Projekteinstellungen frei. Reicht die Cloud, prüfe ich Connectors und Netzwerkzugriff der Cloud-Umgebung. Repositories kommen nur ins Projekt, wenn fast jede Aufgabe sie braucht – den Rest nennen die Anweisungen. 2. **Projektanweisungen nach Anthropics fünf Punkten, plus drei eigene Zeilen.** Zweck, Arbeitsort, Prüfschritte, Verhalten bei fehlendem Zugriff und Freigaben sind gesetzt. Dazu kommen bei mir eine Regel für Widersprüche mit der CLAUDE.md, eine Zeile dazu, was in der Cloud anders gilt als auf dem Rechner, und der Hinweis, dass *Computer Use* kein Ersatz für einen fehlenden MCP-Server ist. Bei konvertierten Projekten schreibe ich die alten Anweisungen dafür neu, statt sie zu flicken. 3. **Das Ziel zuletzt, in einer Zeile.** Erst wenn klar ist, wo und wie gearbeitet wird, schreibe ich hin, woran sich Erfolg ablesen lässt. 4. **Der erste Thread ist ein Probelauf.** Er meldet nur, ob er in der Cloud oder lokal läuft und welche Tools, MCP-Server, Connectors und CLAUDE.md-Dateien er sieht. Kostet ein paar Tokens und hätte mir den Obsidian-Frust erspart. 5. **Am Anfang an der kurzen Leine.** Solange ein Projekt neu ist, schlägt der Koordinator Threads erst vor und wartet auf mein Okay, und es laufen nur wenige gleichzeitig. Läuft das Projekt rund, lockere ich das. 6. **Das Memory ausmisten.** Ab und zu lese ich unter **Projekteinstellungen** \> **Speicher** nach, was Claude sich notiert hat, und lösche Veraltetes – sonst starten Threads mit Notizen, die längst nicht mehr stimmen. Ein Gerüst für die Projektanweisungen, das diese Punkte abdeckt, kann für ein Obsidian Vault-Projekt wie meines so aussehen: ```text Zweck: Dieses Projekt pflegt meinen Obsidian-Vault. Arbeitsort: Alles, was den Vault liest oder schreibt, läuft als lokaler Thread im freigegebenen Vault-Ordner. Reine Recherche darf in der Cloud laufen. Prüfen: Vor „erledigt“ jede neue oder geänderte Notiz auf vollständiges Frontmatter und den richtigen Ordner prüfen. Fehlender Zugriff: Fehlt ein Ordner, ein MCP-Server, ein Connector oder ein Tool, im ersten Satz genau benennen, was fehlt, und stoppen. Kein Ersatz, kein Computer Use, nichts raten. Freigaben: Notizen löschen, verschieben oder umbenennen nur nach meiner Zustimmung. Rangfolge: Liegt im Ordner eine CLAUDE.md, gilt sie für Ordnerstruktur und Frontmatter. Für Arbeitsweise und Freigaben gelten diese Anweisungen. Cloud und lokal: Pfade unter /mnt/project-files gibt es nur in der Cloud. Lokal wird ausschließlich im freigegebenen Ordner gearbeitet. ``` Das sind keine 1.000 Zeichen. Der Rest der 16.000 darf gern leer bleiben. ## Fazit Die neuen Projekte sind für Arbeit gebaut, die länger läuft als eine Session und ständig neue Aufgaben produziert. Dafür ist der Koordinator mit eigenen Threads und eigenen Modellen ein echter Fortschritt, gerade weil er sich auch vom Smartphone aus füttern lässt, während die Threads in der Cloud weiterlaufen. Wer Projekte bisher als lokalen Assistenten mit lokalen MCP-Servern genutzt hat, merkt allerdings schnell, dass sich der Standard umgedreht hat: Lokal ist jetzt die Ausnahme, die man bewusst einschaltet. Von der Liste oben zählt für mich vor allem der erste Schritt: erst klären, wo die Arbeit passiert, dann schreiben. Die Doku hätte mir das alles vorher verraten, ich hätte sie nur lesen müssen.