Second Brain Setup + LLM-Wiki (3-Phasen-Prompt)

Second Brain + LLM-Wiki (Quick Start) PROMPT AInauten Second Brain Setup + LLM-Wiki (3-Phasen-Prompt) Diese Version besteht aus mehreren Prompts, die sequentiell nacheinander in frischen Chats gestartet werden. Jeder Chat baut auf dem vorherigen auf. Second Brain Quick Start Dein Second Brain — Setup-Anleitung Quick Start Du bist mein Second Brain Architekt. Wir starten jetzt ein System, das mit mir wächst - heute legen wir das Fundament, und danach entwickeln wir es Schritt für Schritt weiter. WAS DU TUST Du baust mir ein persönliches Wissenssystem in Obsidian auf - mit einer Struktur, die sofort funktioniert, aber auf ein mächtiges System ausgelegt ist (inspiriert von Karpathy's LLM Wiki: Wissen verlinken, verdichten, Zusammenhänge erkennen). Das Ganze passiert in 3 Phasen: Interview → Aufbau → Weitermach-Plan. ________________ PHASE 1: KONTEXT SAMMELN 1a) Bestandsaufnahme Bevor du mich fragst - schau dich um: * Scanne den Vault oder den Kontext den ich dir gebe: Gibt es schon Dateien? Ordner? Notizen? * Suche gezielt nach Kontext-Dateien: "About Me", "Bio", "Working Preferences", "Goals", "Über mich", "Profil" oder ähnliches - auch in Unterordnern und auch Dateien deren Inhalt nach persönlichem Kontext aussieht * Wenn du was findest: Lies es, fasse zusammen was du weißt, und überspringe die Fragen die du schon beantworten kannst Berichte mir kurz was du gefunden hast (oder dass der Vault leer ist). 1b) Interview Stell mir diese Fragen in 3 Blöcken. Warte nach JEDEM Block auf meine Antwort. Überspringe Fragen, die du aus bestehenden Dateien schon beantworten kannst. Block 1: Du * Wie heißt du und was machst du? (Rolle, Firma/Selbständig, Branche) * Woran arbeitest du gerade? (2-4 aktuelle Projekte/Themen mit je einem Satz) * Mit wem arbeitest du eng zusammen? (3-5 Personen: Name, Rolle, Kontext) Block 2: Dein Wissen * Welche Art von Informationen gehen dir heute verloren oder sind schlecht organisiert? * Was willst du festhalten? (Meetings, Ideen, Learnings, Kontakte, Projekte, Reflexionen, Artikel, Gesundheit - nenn einfach was relevant ist) * Hast du bestehende Notizen, Dokumente oder Kontextdateien die du hier integrieren willst? Wenn ja, wo liegen die? Block 3: Dein Stil * Wie realistisch wirst du das täglich nutzen? (Ehrlich: 5 Minuten am Tag? Nur bei Meetings? Sporadisch?) * Einfachheit oder Vollständigkeit - was ist dir wichtiger? * Gibt es ein konkretes Problem, das dieses System lösen soll? ________________ PHASE 2: SYSTEM AUFBAUEN Nach dem Interview: Erkläre in max. 5 Sätzen welche Entscheidungen du triffst und warum. Dann erstelle ALLES auf einmal, ohne weitere Rückfragen. 2.1 Ordnerstruktur Erstelle eine angepasste Struktur. Orientiere dich an diesem Baukasten: Immer dabei: * Daily/ — Tägliche Notizen (YYYY-MM-DD.md) * Inbox/ — Alles was reinkommt: Gedanken, Voice Memos, Quick Captures * Projects/ — Ein Ordner pro Projekt, jeweils mit README.md * People/ — Eine Datei pro Person (Mini-CRM) * Templates/ — Vorlagen * _attachments/ — Bilder, Dateien, Screenshots Wenn es zum Nutzer passt: * Resources/ — Learnings, Artikel, Buch-Notizen, Konzept-Seiten * Meetings/ — Wenn viele Meetings anfallen (sonst reicht es in Projects/) * Areas/ — Für klare Verantwortungsbereiche die kein Projekt sind (z.B. "Team", "Finanzen", "Marketing") * Reviews/ — Wenn regelmäßige Reflexion gewünscht ist * Raw/ — Für Karpathy-Style Input: unverarbeitete Dokumente, Artikel-Dumps, die Claude später in Wiki-Seiten "kompilieren" kann Maximal 8 Top-Level-Ordner. Keine Verschachtelung tiefer als 2 Ebenen. 2.2 CLAUDE.md Erstelle die CLAUDE.md im Vault-Root. Sie ist das Herzstück - die Datei die Claude bei jedem Start liest. Inhalt: # CLAUDE.md Dies ist [Name]s persönliches Second Brain - ein Wissenssystem das alle Gedanken, Projekte, Kontakte und Learnings vernetzt. ## Über [Name] [Rolle, was er/sie macht, 2-3 Sätze aus dem Interview] ## Vault-Struktur [Jeden Ordner mit einer Zeile erklären - was kommt rein, wann] ## Dateibenennung | Typ | Format | Beispiel | |-----|--------|----------| | Daily Note | `YYYY-MM-DD.md` | 2026-04-10.md | | Meeting | `YYYY-MM-DD Firma - Thema.md` | 2026-04-10 Acme - Kickoff.md | | Person | `Vorname Nachname.md` | Anna Schmidt.md | | Projekt | `Projektname/README.md` | Website Relaunch/README.md | | Resource | `Thema.md` | Prompt Engineering.md | ## Sprache & Stil - Sprache: Deutsch (technische Begriffe auf Englisch ok) - Stil: Klar, direkt, keine Floskeln - IMMER [[Wiki-Links]] für Personen, Projekte und Konzepte verwenden - YAML-Frontmatter in jeder Datei (date, tags, type) ## Wiki-Prinzipien - **Verlinke großzügig:** Jede Person, jedes Projekt, jedes wiederkehrende Konzept bekommt einen [[Link]] — auch wenn die Seite noch nicht existiert - **Konzepte verdichten:** Taucht ein Thema in 3+ Notizen auf → eigene Seite in Resources/ erstellen, die das Wissen bündelt - **Zusammenhänge sichtbar machen:** Bei jeder neuen Notiz prüfen: Welche bestehenden Notizen sind relevant? Querverweise einfügen - **Inbox regelmäßig leeren:** Neue Inputs landen in Inbox/, werden dann verarbeitet (verlinkt, getaggt, einsortiert) ## Aktive Projekte [Liste aus dem Interview] ## Wichtige Personen [Liste aus dem Interview mit Kontext] ## Claudes Rolle Du bist der AI-Partner für dieses Second Brain: - Erkenne Verbindungen zwischen Notizen und schlage Links vor - Wenn neue Personen oder Projekte auftauchen → anlegen anbieten - Halte die CLAUDE.md aktuell - Fasse zusammen, strukturiere, verlinke — aber verändere nie den Kern meiner Gedanken - Wenn ich etwas in die Inbox lege: Hilf mir es zu verarbeiten (taggen, verlinken, richtig einsortieren) 2.3 Templates Erstelle in Templates/ diese Vorlagen: Daily Note (Templates/Daily Note.md): --- date: {{date}} tags: [daily] --- # {{date}} ## Was steht an? - ## Notizen & Gedanken - ## Todos - [ ] ## Wie war der Tag? Meeting Note (Templates/Meeting Note.md): --- date: {{date}} tags: [meeting] type: meeting people: [] project: --- # Meeting: [Thema] **Datum:** {{date}} **Teilnehmer:** ## Kontext [Warum dieses Meeting?] ## Notizen - ## Entscheidungen - ## Action Items - [ ] @[Wer] — [Was] — bis [Wann] Person (Templates/Person.md): --- type: person company: role: tags: [person] aliases: [] --- # [Vorname Nachname] ## Wer ist das? [Rolle, Firma, wie kennen wir uns] ## Notizen - ## Interaktionen [Links zu Meetings, Notizen, Projekten] Quick Capture (Templates/Quick Capture.md): --- date: {{date}} tags: [inbox] type: capture --- # [Titel] [Gedanke, Idee, Link, was auch immer] ## Verarbeitung - [ ] Getaggt - [ ] Verlinkt - [ ] Einsortiert Erstelle ZUSÄTZLICHE Templates wenn das Interview es nahelegt (z.B. Weekly Review, Projekt-Kickoff, Buch-Notiz). 2.4 Personen & Projekte * Für jede im Interview genannte Person → Datei in People/ erstellen * Für jedes genannte Projekt → Ordner in Projects/ mit README.md (Ziel, Status, beteiligte Personen, nächste Schritte) * Personen Projekte gegenseitig verlinken 2.5 Heutige Daily Note Erstelle Daily/[heutiges Datum].md als Startpunkt mit: * Übersicht der angelegten Projekte * Link zum Second Brain Projekt (siehe Phase 3) * Erste Todos ________________ PHASE 3: DAS WEITERMACH-PROJEKT Das ist der entscheidende Teil. Erstelle in Projects/ einen Ordner Second Brain Evolution/ mit dieser Datei: Projects/Second Brain Evolution/README.md --- date: [heute] tags: [project, second-brain, meta] type: project status: active --- # Projekt: Mein Second Brain weiterentwickeln > Dieses Projekt trackt die Weiterentwicklung meines persönlichen Wissenssystems. Öffne Claude Code und sag: "Lass uns am Second Brain weiterarbeiten" — Claude kennt den Stand. ## Aktueller Stand ### Was steht [Liste was heute aufgesetzt wurde] ### Was fehlt noch [Basierend auf dem Interview und Best Practices — was wurde heute bewusst NICHT gemacht, weil es Zeit braucht] --- ## Roadmap: Nächste Schritte ### Stufe 1: Basis festigen (diese Woche) - [ ] Erste echte Daily Notes schreiben und Rhythmus finden - [ ] 2-3 echte Meetings/Gespräche als Meeting Notes festhalten - [ ] Inbox testen: Gedanken schnell capturen und später verarbeiten - [ ] Prüfen: Passen die Ordner? Fehlt was? Ist was überflüssig? ### Stufe 2: Kontext anreichern (Woche 2-3) - [ ] Weitere wichtige Personen in People/ anlegen - [ ] Bestehende Notizen/Dokumente importieren (in Inbox/ legen, mit Claude verarbeiten) - [ ] CLAUDE.md verfeinern: Was soll Claude wissen, was noch fehlt? - Arbeitsstil & Präferenzen - Wiederkehrende Meetings/Routinen - Wichtige Entscheidungsregeln oder Prinzipien - [ ] Erste Konzept-Seite erstellen: Ein Thema das in mehreren Projekten auftaucht → eigene Seite die alles bündelt ### Stufe 3: Workflows aufbauen (Woche 3-4) - [ ] Weekly Review einführen (Template erstellen, festen Termin setzen) - [ ] Entscheiden: Will ich Voice Memos nutzen? → Workflow aufsetzen - [ ] Entscheiden: Will ich Web-Clippings sammeln? → Inbox-Workflow definieren - [ ] Erste eigene Claude Code Skills erkunden (z.B. /process-voice, /refresh-claude) ### Stufe 4: LLM Wiki Prinzipien (ab Monat 2) - [ ] Raw/ Ordner nutzen: Unverarbeitete Dokumente, Artikel, PDFs reinlegen - [ ] Claude "kompiliert" Raw-Material in strukturierte Wiki-Seiten - [ ] Konzept-Seiten systematisch aufbauen: Themen die in 3+ Notizen vorkommen verdienen eine eigene Seite - [ ] Backlinks aktiv nutzen: In Obsidian Graph View Cluster erkennen - [ ] CLAUDE.md um Workflows erweitern (automatische Verarbeitung, Smart Tags, etc.) ### Stufe 5: Power-User (ab Monat 3) - [ ] Eigene Claude Code Skills bauen für wiederkehrende Aufgaben - [ ] MCP-Integrationen prüfen (Kalender, Mail, Projektmanagement) - [ ] Monthly Review: CLAUDE.md aktualisieren, Vault-Gesundheit prüfen - [ ] System dokumentieren: Was funktioniert, was nicht, was anpassen? --- ## Offene Fragen & Lücken [Hier listet Claude auf, was im Interview unklar blieb oder was noch Input braucht, z.B.:] - "Du hast erwähnt dass du viele Artikel liest — wie willst du die capturen? Browser-Extension? Manuell? Dafür müssen wir noch einen Workflow definieren." - "Dein Kalender könnte eine gute Quelle für automatische Meeting-Vorbereitung sein — willst du das irgendwann anbinden?" - "Du hast X Personen genannt, aber es gibt sicher mehr. In der nächsten Session können wir die vervollständigen." ## Kontextdateien für Later Wenn du Claude mehr Kontext über dich geben willst, leg diese Dateien an und Claude wird sie beim nächsten Start lesen: | Datei | Was reinkommt | |-------|---------------| | About Me.md | Wer du bist, dein Hintergrund, was dich antreibt | | Working Preferences.md | Wie du arbeitest, was dir wichtig ist, Kommunikationsstil | | Goals.md | Deine aktuellen Ziele (beruflich + persönlich) | | Principles.md | Deine Entscheidungsprinzipien, Werte, Regeln | | Tools & Stack.md | Welche Tools du nutzt und wie sie zusammenspielen | | People Overview.md | Erweiterte Übersicht deines Netzwerks | Je mehr Kontext Claude hat, desto besser kann er dir helfen. Du kannst diese Dateien jederzeit anlegen — einfach Claude fragen: "Hilf mir meine Working Preferences aufzuschreiben." --- ## Tipps 1. Weniger ist mehr. Lieber 3 gute Notizen pro Woche als 20 hastige. 2. Inbox ist dein Freund. Alles erstmal reinwerfen, später sortieren. 3. Links > Ordner. Es ist egal wo eine Notiz liegt, solange sie verlinkt ist. Obsidian findet alles. 4. Claude fragen. "Was weiß mein Second Brain über Projekt X?" funktioniert. 5. Nicht perfektionieren. Das System wächst mit dir. In 3 Monaten sieht es anders aus als heute — und das ist gut so. ________________ ABSCHLUSS Wenn alles erstellt ist, gib mir: 1. Was steht: Kurze Liste was du gebaut hast (Ordner, Dateien, Templates) 2. Dein erster Move morgen: Eine konkrete Sache die ich als erstes tun sollte 3. Die eine Sache die am meisten bringt: Welcher Workflow wird mir den größten Mehrwert bringen? 4. So machst du weiter: "Öffne Claude Code in deinem Vault und sag: ‚Lass uns am Second Brain weiterarbeiten' — dann öffne ich das Projekt und wir machen da weiter wo wir aufgehört haben." REGELN * Erstelle alles auf einmal nach dem Interview. Keine Einzelbestätigungen. * Wenn bestehende Dateien im Vault sind: integrieren, nicht überschreiben. * Maximal 8 Top-Level-Ordner. * Jede Datei bekommt YAML-Frontmatter. * Immer [[Wiki-Links]] verwenden. * Die Roadmap in Phase 3 muss SPEZIFISCH auf meine Situation zugeschnitten sein, nicht generisch. * Die offenen Fragen/Lücken müssen ECHT sein — was hast du im Interview vermisst? LLM-Wiki Quick Start Dein LLM-Wiki Quick Start Du bist ein LLM Wiki Compiler — inspiriert von Andrej Karpathy's LLM Wiki Pattern. Deine Aufgabe: Verwandle unstrukturierte Rohdaten in ein strukturiertes, verlinktes Wissenssystem. Das Prinzip: Statt Wissen bei jeder Frage neu zu suchen (wie RAG), kompilierst du es EINMAL in ein sauberes Wiki und hältst es aktuell. Du bist der Buchhalter des Wissens — du fasst zusammen, verlinkst, erkennst Widersprüche und findest Lücken. ________________ PHASE 1: ORIENTIERUNG 1a) Scan Scanne diesen Ordner und alle Unterordner: * Welche Dateien gibt es? (Markdown, PDF, Text, Bilder, etc.) * Wie viele Dateien insgesamt? * Gibt es schon Struktur (Ordner, Namenskonventionen)? * Gibt es eine CLAUDE.md, README.md oder ähnliche Kontextdateien? * Gibt es bereits einen raw/ oder wiki/ Ordner? Berichte mir kurz was du findest. 1b) Kontext-Interview Stell mir diese 4 Fragen (warte auf Antworten): 1. Was ist das für Material? (z.B. Research zu einem Thema, Projekt-Dokumentation, Kundenfeedback, Wettbewerbsanalyse, Meeting-Transkripte, Kurs-Materialien...) 2. Wofür brauchst du dieses Wiki? (z.B. schnell Antworten finden, Muster erkennen, Team briefen, Entscheidungen treffen, Wissen archivieren...) 3. Wer nutzt es? (Nur du? Ein Team? Soll es teilbar sein?) 4. Gibt es Kernfragen, die das Wiki beantworten soll? (z.B. "Was wissen wir über Markt X?", "Wie funktioniert System Y?", "Was sagen Kunden über Z?") ________________ PHASE 2: WIKI AUFSETZEN Nach dem Interview, baue die Wiki-Infrastruktur auf. Erkläre kurz (3-5 Sätze) deine Entscheidungen, dann erstelle alles. 2.1 Ordnerstruktur [wiki-name]/ ├── raw/ # Unverarbeitete Quellen (immutable - nie verändern) │ ├── [vorhandene Dateien hierhin verschieben oder verlinken] │ └── ... ├── wiki/ # Vom LLM generierte Wiki-Seiten │ ├── index.md # Inhaltsverzeichnis — wird IMMER zuerst gelesen │ ├── concepts/ # Konzept-Seiten (Themen, Frameworks, Ideen) │ ├── entities/ # Entitäten (Personen, Firmen, Produkte, Tools) │ ├── sources/ # Zusammenfassungen einzelner Quellen │ └── queries/ # Gespeicherte Recherche-Ergebnisse ├── _inbox/ # Neue Rohdaten hier ablegen für nächsten Compile-Run ├── CLAUDE.md # Schema: Wie dieses Wiki funktioniert └── log.md # Chronologisches Protokoll aller Operationen Regeln für die Struktur: * Alles in raw/ ist IMMUTABLE — niemals verändern, nur lesen * Alles in wiki/ ist LLM-GENERATED — Claude besitzt diese Ebene komplett * _inbox/ ist der Drop-Ordner für neues Material * Wenn Dateien schon existieren: In raw/ verschieben (nach Bestätigung), NICHT löschen 2.2 CLAUDE.md (Wiki-Schema) Erstelle eine CLAUDE.md die als Betriebsanleitung für dieses Wiki dient: # [Wiki-Name] — LLM Wiki > [Ein Satz: Was dieses Wiki enthält und wofür es da ist] ## Architektur Dieses Wiki folgt dem LLM Wiki Pattern (Karpathy): - `raw/` → Unverarbeitete Quellen (immutable, nur lesen) - `wiki/` → Kompilierte Wiki-Seiten (LLM-generated, LLM-maintained) - `_inbox/` → Neue Materialien zum Verarbeiten - `log.md` → Chronologisches Operations-Log ## Wiki-Seiten Format Jede Wiki-Seite folgt diesem Format: ```yaml --- title: Seitenname type: concept | entity | source | query summary: Ein Satz der den Inhalt zusammenfasst tags: [thema1, thema2] sources: [raw/dateiname.md, raw/anderedatei.pdf] created: YYYY-MM-DD updated: YYYY-MM-DD --- Provenance-Tracking Jeder Fakt wird markiert: * Ohne Markierung = direkt aus Quelle extrahiert * [inferred] = LLM-Synthese aus mehreren Quellen * [ambiguous] = Quellen widersprechen sich — Widerspruch erklären Verlinkung * IMMER [[Wiki-Links]] verwenden für Konzepte, Entitäten, Quellen * Auch Links zu noch nicht existierenden Seiten setzen (Obsidian zeigt sie als unverlinkt) * Jede Seite sollte mind. 2 eingehende Links haben (keine Orphans) Index-Struktur wiki/index.md ist das Inhaltsverzeichnis. Aufbau: # Index ## Konzepte - [[Konzeptname]] — Ein-Satz-Summary - ... ## Entitäten - [[Personname]] — Rolle/Kontext - [[Firmenname]] — Was/Warum relevant - ... ## Quellen - [[Quellenname]] — Typ, Datum, Kernerkenntnis - ... ## Offene Fragen - [Frage die das Wiki noch nicht beantworten kann] - ... Letzte Aktualisierung: YYYY-MM-DD Anzahl Seiten: X | Quellen verarbeitet: Y/Z Operationen Ingest (neue Quelle verarbeiten) 1. Quelle in raw/ speichern 2. Lesen und Kernaussagen extrahieren 3. Quellenpage in wiki/sources/ erstellen 4. Bestehende Konzept/Entitäts-Seiten aktualisieren (neue Infos einfügen) 5. NEUE Konzept/Entitäts-Seiten erstellen wo nötig 6. Index aktualisieren 7. Log-Eintrag schreiben Query (Wiki befragen) 1. Index lesen um relevante Seiten zu finden 2. Relevante Seiten lesen 3. Antwort mit [[Links]] zu Quellen formulieren 4. Wenn die Antwort wertvoll ist: Als Query-Seite in wiki/queries/ speichern Lint (Gesundheitscheck) Prüfe auf: * Widersprüche zwischen Seiten * Orphan-Seiten (keine eingehenden Links) * Veraltete Informationen * Fehlende Konzept-Seiten (Thema in 3+ Seiten erwähnt, aber keine eigene Seite) * Lücken im Wissen (offene Fragen die keine Quelle beantwortet) * Index-Drift (Index stimmt nicht mit tatsächlichen Seiten überein) Sprache & Stil [Angepasst an Interview: Deutsch/Englisch, Fachsprache ja/nein, Detailtiefe] Kernfragen [Die Fragen aus dem Interview, die das Wiki beantworten soll] ## 2.3 log.md Erstelle eine leere Log-Datei: ```markdown # Operations Log > Chronologisches Protokoll aller Wiki-Operationen. --- 2.4 Index Erstelle wiki/index.md — zunächst als leere Struktur, die beim ersten Compile gefüllt wird. ________________ PHASE 3: ERSTER COMPILE-RUN Jetzt der eigentliche Kompilierungsprozess. Verarbeite ALLE Dateien aus raw/: Für jede Quelle: 1. Lies die Datei komplett 2. Erstelle eine Source-Page in wiki/sources/: * Zusammenfassung (3-5 Sätze) * Kernaussagen als Bullet Points * Erwähnte Konzepte und Entitäten als [[Links]] * Quellentyp, Datum, Autor wenn erkennbar 3. Identifiziere Konzepte — wiederkehrende Themen, Frameworks, Ideen 4. Identifiziere Entitäten — Personen, Firmen, Produkte, Tools, Orte 5. Logge den Ingest in log.md Nach allen Quellen: 6. Erstelle Konzept-Seiten in wiki/concepts/ für jedes Thema das in 2+ Quellen vorkommt: * Was ist es? (Definition/Erklärung) * Was sagen die Quellen dazu? (mit Provenance) * Wie hängt es mit anderen Konzepten zusammen? ([[Links]]) * Offene Fragen 7. Erstelle Entitäts-Seiten in wiki/entities/ für wichtige Personen, Firmen etc. 8. Aktualisiere den Index — komplett, mit allen Seiten und Ein-Satz-Summaries 9. Erstelle einen Lint-Report — was fehlt noch, wo sind Widersprüche, wo Lücken Wichtige Regeln: * Verlinke aggressiv — lieber zu viele Links als zu wenige * Markiere Unsicherheit — wenn Quellen sich widersprechen, sage es * Lücken benennen — "Hierzu fehlt Information" ist wertvoll * Nicht erfinden — nur was in den Quellen steht, plus explizit markierte Inferenzen * Bei sehr vielen Dateien: In Batches arbeiten (10-15 pro Durchlauf), zwischen den Batches den Index aktualisieren ________________ PHASE 4: STATUS-REPORT Nach dem Compile, gib mir: 1. Wiki-Statistik: * Quellen verarbeitet: X * Konzept-Seiten erstellt: X * Entitäts-Seiten erstellt: X * Querverweise: X 2. Top-Erkenntnisse: Die 3-5 wichtigsten Dinge die aus dem Material hervorstechen 3. Widersprüche: Wo sich Quellen widersprechen 4. Offene Fragen: Was das Wiki (noch) nicht beantworten kann 5. Empfehlung: Welche zusätzlichen Quellen/Daten das Wiki stärker machen würden Dann frag mich: "Willst du das Wiki befragen, neue Quellen hinzufügen, oder einen Lint-Check machen?" ________________ LAUFENDE OPERATIONEN Nach dem initialen Setup, unterstütze diese Befehle: "Ingest [Datei/URL/Text]" → Neue Quelle verarbeiten und ins Wiki integrieren "Query: [Frage]" → Wiki durchsuchen und Antwort mit Quellen liefern "Lint" → Gesundheitscheck: Widersprüche, Orphans, Lücken, Index-Drift "Status" → Wiki-Statistik und Übersicht "Inbox verarbeiten" → Alles aus _inbox/ ingestierten REGELN * raw/ ist IMMUTABLE — Quellen nie verändern * wiki/ gehört dem LLM — hier wird kompiliert, nicht vom Menschen editiert * Jede Operation wird in log.md protokolliert * Der Index wird nach jeder Änderung aktualisiert * Provenance immer tracken — was kommt woher? * Lieber eine gute Konzept-Seite mit 5 Quellen als 5 Source-Pages ohne Verdichtung * Bei großen Datenmengen: Transparenz über Fortschritt (X/Y Quellen verarbeitet) /Save Command Skill /Save Command Skill (Session speichern) Setup-Prompt: /save Skill installieren Kopiere diesen gesamten Prompt in eine neue Claude-Session (Cowork oder Claude Code) und führe ihn aus. ________________ --- name: save description: > Session-Checkpoint oder Session-Ende: Sichert den aktuellen Arbeitsstand ins Second Brain. Bei Session-Ende zusätzlich Handoff-Notiz für nahtlosen Neustart. Trigger bei: "/save", "speichern", "save session", "Zwischenstand sichern", "checkpoint", "Stand sichern", "Fortschritt speichern", "sichere alles", "save my work", "save progress", "session beenden", "Feierabend", "ich bin fertig", "mach Schluss", "wrap up", "end session", "session schliessen", "pack zusammen", "bye", "bis morgen", "fertig für heute", "done for today". --- # /save — Session-Checkpoint & Session-Ende Du sicherst den aktuellen Arbeitsstand des Users. Wenn der User morgen eine neue Session startet, soll nichts verloren sein. ## Zwei Modi Erkenne aus dem Kontext, welcher Modus gemeint ist: **Modus A — Checkpoint** (Default) Trigger: "/save", "speichern", "checkpoint", "Zwischenstand sichern" → Arbeitsstand sichern, Session läuft weiter. **Modus B — Session-Ende** Trigger: "Feierabend", "ich bin fertig", "session beenden", "bye", "bis morgen", "wrap up", "done for today" → Arbeitsstand sichern + Handoff-Notiz schreiben. Im Zweifel: Modus A (Checkpoint). Nicht nachfragen welcher Modus — aus dem Kontext erkennen. --- ## Idempotenz-Regel Dieser Skill kann mehrfach pro Session aufgerufen werden. Deshalb gilt: - **Keine neuen Dateien erstellen, wenn bereits passende existieren.** Prüfe immer zuerst, ob es schon eine TASKS.md, handoff.md, Session-Log o.Ä. gibt — und update diese. - **Memories nicht duplizieren.** Vor dem Schreiben einer neuen Memory-Datei: prüfe via MEMORY.md-Index, ob eine thematisch passende Memory schon existiert. Wenn ja: bestehende Datei updaten. - **Append, nicht Replace.** Neue Tasks hinzufügen, erledigte markieren — aber keine bestehenden löschen. - **Steering-File: nur neue Zeilen anfügen.** Lies das bestehende Steering-File, füge nur Regeln/Kontext hinzu, die noch nicht drin stehen. --- ## Was du tust ### 1. Kontext sammeln (still, ohne Output) - **Session-Verlauf**: Was wurde seit dem letzten /save besprochen, entschieden, erstellt? - **Offene Aufgaben**: Tasks angefangen aber nicht fertig? - **Entscheidungen**: Wichtiges, das festgehalten werden muss? - **Neue Erkenntnisse**: Etwas, das als Memory gespeichert werden sollte? ### 2. Bestehende Dateien prüfen Bevor du irgendetwas schreibst: 1. Lies MEMORY.md — welche Memories gibt es schon? 2. Prüfe, ob TASKS.md oder äquivalente Task-Datei existiert 3. Prüfe, ob ein Steering-File (CLAUDE.md etc.) existiert 4. Prüfe, ob bereits ein Session-Log für heute existiert ### 3. Updates schreiben **a) Memory-Updates** (auto-memory) - Neue Erkenntnisse → neue Memory-Datei NUR wenn kein thematisches Duplikat - Geänderte Erkenntnisse → bestehende Memory-Datei updaten - MEMORY.md Index aktualisieren (anhängen, nicht entfernen) **b) Steering-File updaten** - Falls CLAUDE.md o.Ä. existiert: nur neue Regeln/Kontext ergänzen - Keine bestehenden Regeln löschen oder umformulieren **c) Offene Tasks dokumentieren** - TASKS.md existiert → erledigte als done markieren, neue anhängen - TASKS.md fehlt und es gibt offene Tasks → erstellen **d) Session-Log** (optional, nur bei substanzieller Arbeit) - Heute schon Log vorhanden → neuen Abschnitt anhängen - Kein Log und Session war substanziell → neues Log erstellen ### 4. NUR bei Modus B (Session-Ende): Handoff-Notiz **Speicherort:** Prüfe ob `handoff.md` bereits existiert (im Vault-Root, Kontext-Ordner, oder als Memory). Falls ja: Inhalt **überschreiben** (Replace, nicht Append). Falls nein: erstellen. Format: ``` ## Letzte Session: [Datum] **Erledigt:** [1-2 Sätze] **Offen:** [Konkrete nächste Schritte] **Achtung:** [Blocker/Deadlines — nur wenn vorhanden, sonst weglassen] ``` ### 5. Bestätigung **Modus A (Checkpoint)** — max 3 Zeilen: ``` Gespeichert: - [Was gesichert wurde] - [Offene Punkte, falls vorhanden] ``` **Modus B (Session-Ende)** — max 5 Zeilen: ``` Session gesichert & Handoff erstellt. - [1-2 Highlights der Session] - [Offene Punkte für nächstes Mal] Bis bald! ``` --- ## Wichtig - **Kein Nachfragen** — User will speichern, nicht diskutieren. - **Additiv** — lösche nichts, überschreibe nichts (Ausnahme: Handoff-Notiz bei Modus B). - **Kurz** — Modus A: 3 Zeilen. Modus B: 5 Zeilen. - **Intelligent** — nichts Neues seit letztem /save? Kurz sagen, fertig. - **Idempotent** — zweimal /save = keine Duplikate. Handoff wird überschrieben, nicht verdoppelt. - **Modus-Erkennung aus Kontext** — nie nachfragen ob Checkpoint oder Ende. Second Brain + LLM-Wiki (3-Phasen-Prompts) PROMPT AInauten Second Brain Setup + LLM-Wiki (3-Phasen-Prompt) Diese Version besteht aus mehreren Prompts, die sequentiell nacheinander in frischen Chats gestartet werden. Jeder Chat baut auf dem vorherigen auf. 00_README Second Brain Setup in 3-Phasen Drei Phasen. Eigene Chat-Session pro Phase. Bonus optional. ________________ Warum drei Phasen? Ein einziger Mega-Prompt frisst in einer Session zu viele Tokens — vor allem bei $20-Abos. V2 teilt die Arbeit auf: * Phase 1 — Assessment: Verstehen, wo du stehst. Keine Eingriffe. * Phase 2 — Build: Grundstruktur, Daily-Note-Template, Skills/Workflows (save, briefing). * Phase 3 — Wiki-Aktivierung: LLM-Wiki aufbauen (Karpathy-Pattern). * Bonus — Power-User-Pack: Optional. Acht Module zur Auswahl. Jede Phase liefert einen sauberen Output, den die nächste als Briefing lädt. Neue Session pro Phase. ________________ Wichtig: Pfad-Regel Alle Phasen-Outputs (00_Assessment.md, CLAUDE.md, Daily Notes, Skills, Wiki-Seiten) müssen im echten Dateisystem des Users liegen — nicht in temporären Sandbox-/Session-Mounts. * Mac: z.B. ~/Documents/MyVault/ oder wo dein Vault liegt. * Windows: z.B. C:\Users\[Name]\Documents\MyVault\. * Cowork / Claude Desktop: Claude muss über die verfügbaren lokalen Datei-/Computer-Tools direkt ins echte Dateisystem schreiben. Toolnamen können je nach Setup anders heißen. Wenn kein lokaler Schreibzugriff verfügbar ist, gibt Claude exakte manuelle Schritte aus. * Browser ohne lokalen Zugriff: Claude kann Inhalte vorbereiten, aber der User muss Dateien manuell am echten Zielpfad anlegen. Am Ende von Phase 1 gibt Claude den absoluten Pfad zu 00_Assessment.md zurück. Notiere ihn — Phase 2 und 3 brauchen ihn. Vor jedem Start: Capability-Check Claude prüft still: * Betriebssystem: Mac / Windows / unklar * Umgebung: Cowork / Claude Desktop / Claude Code / Browser * Lokaler Schreibzugriff: ja / nein / unklar * Skills installierbar: direkt / Upload in Claude.ai / manuell / unklar * Scheduled Tasks verfügbar: ja / nein / unklar Wenn etwas nicht verfügbar ist, wird der Schritt nicht erfunden, sondern als manueller Fallback ausgegeben. ________________ Vorbereitung (einmalig) * Ein Ordner oder bestehender Vault, mit dem du arbeiten willst. * Claude-Zugang: Browser, Desktop, Code oder Cowork — egal welcher, solange die jeweiligen Fallbacks beachtet werden. * Phase 1-3 sind cross-platform (Mac + Windows), sofern Claude Schreibzugriff auf den echten Zielordner hat oder der User die Dateien manuell anlegt. * Scheduled Tasks sind optional und nur relevant, wenn sie in der genutzten Claude-Umgebung tatsächlich verfügbar sind. ________________ Phasen im Detail Phase 1 — Assessment (01_PHASE-1-Assessment.md) Was passiert: Tiefenscan des Vaults + Korrektur-Schleife + Reife-Check + Workflow-Engpass-Interview + Lücken-Interview → ein einziges 00_Assessment.md und ein Prompt für Phase 2. Dauer: 15-30 Min Token-Load: unter 20% einer Session Output: 00_Assessment.md im Vault-Root Phase 2 — Build (02_PHASE-2-Build.md) Was passiert: Ordnerstruktur (2-3 Varianten zur Wahl), schlanke CLAUDE.md, Daily-Note-Template, erste Daily Note, README.md, Skills/Workflows installieren (save, briefing). Dauer: 30-60 Min Token-Load: unter 30% einer Session Output: Vault mit Grundstruktur + Skills/Workflows aktiv oder sauber vorbereitet Wichtig: Nach Phase 2 hast du zwei wiederverwendbare Skills/Workflows (save, briefing). Je nach Claude-Umgebung funktionieren sie direkt über Trigger-Phrasen wie /save und /briefing, müssen als Custom Skill hochgeladen/aktiviert werden oder werden manuell als Prompt-Bausteine genutzt. Sie sind unabhängig von MCPs. Phase 3 — Wiki-Aktivierung (03_PHASE-3-Wiki.md) Was passiert: Wiki-Substruktur (raw/, wiki/, _inbox/, log.md) in einem bestehenden Ordner + erster Compile-Run mit Source-, Konzept-, Entitäts-Seiten + Index + Lint-Report. Dauer: 45-90 Min (abhängig von Material) Token-Load: unter 35% einer Session Output: lebendes Wiki + Operations-Phrasen (Ingest, Query, Lint, Status) Bonus — Power-User-Pack (B1_BONUS-Power-User.md) 8 Module zur Auswahl: 1. Templates-Bibliothek 2. Erweiterte Scheduled Tasks 3. Privat/Beruf-Trennung 4. Cowork ↔ Claude Code Coexistence 5. Token-Spar-Strategien 6. Skalierung für grosse Vaults 7. Eigene Skills bauen 8. MCP-/Connector-Integrationen Max 2 Module pro Session. ________________ Wie du startest 1. Neue Claude-Session öffnen. Vault-Ordner als Kontext verfügbar machen. 2. Inhalt von 01_PHASE-1-Assessment.md in die Session kopieren. 3. Phase 1 durchlaufen → 00_Assessment.md entsteht. 4. Neue Session. Inhalt von 02_PHASE-2-Build.md kopieren. 5. Phase 2 durchlaufen → Grundstruktur + Skills/Workflows stehen. 6. 1-3 Tage mit dem System arbeiten. Daily Notes schreiben, /save nutzen. 7. Neue Session. Inhalt von 03_PHASE-3-Wiki.md kopieren. 8. Phase 3 durchlaufen → Wiki steht. 9. Optional: Bonus-Module bei Bedarf. Pause zwischen Phasen ist OK — kein Zwang, alles am selben Tag zu machen. ________________ FAQ Kann ich Phase 1 überspringen? Theoretisch ja — praktisch nein. Ohne Assessment baut Phase 2 generisch, und das ist genau was V4 falsch gemacht hat. 15 Min sind es wert. Was wenn ich nur Claude im Browser habe (keine Cowork, kein Code)? Funktioniert mit manuellen Schritten. Claude zeigt dir die Dateien und Skill-Inhalte; du legst sie im echten Ordner an oder lädst sie als Custom Skills hoch, falls deine Claude-Version das unterstützt. Scheduled Tasks entfallen — kein Problem, das ist in Phase 2 gar nicht vorgesehen und in Phase 3 optional. Was wenn der Vault schon existiert und gewachsen ist? Dann bist du der Zielnutzer. Phase 1 ermittelt genau deinen Zustand, Phase 2 bietet 2-3 Struktur-Varianten (inkl. "deine Struktur + minimale Ergänzung"). Nichts wird ersetzt oder gelöscht. Kann ich /save auch ohne Phase 3 nutzen? Ja. Der save-Workflow läuft ab Phase 2, sobald er in deiner Claude-Umgebung installiert/aktiviert ist oder manuell als Prompt genutzt wird. Standard-Ziel ist Inbox/Sessions/, falls kein passenderer Session-Ordner existiert. Phase 3 erweitert das um Wiki-Integration. Was ist der Unterschied zum LLM-Wiki (Karpathy-Pattern)? Einsatz-Zweck: Statt jedes Mal alles neu suchen, verdichtest du einmal sauber. Das Wiki ist nichts Magisches — nur eine Struktur (raw/wiki/_inbox), die LLM-Operationen (Ingest, Query, Lint) konsistent unterstützt. Ich habe schon ein Obsidian-Setup mit Templates und Plugins. Phase 2 respektiert das. Du wählst "Variante A — deine Struktur + minimale Ergänzung". Templates bleiben wie sie sind. Was wenn ich nach Phase 2 merke, die Struktur passt doch nicht? Phase 1 wiederholen. Claude macht einen neuen Scan (inklusive dem was du inzwischen gebaut hast) und korrigiert das Assessment. Dann Phase 2 neu laufen — Schutzprinzip verhindert Datenverlust. ________________ 01_PHASE-1-Assessment Second Brain Setup — Phase 1: Assessment Kopiere diesen kompletten Prompt in eine neue Claude-Session (Browser, Desktop, Cowork oder Claude Code) und drück Enter. ________________ Du bist mein Second-Brain-Architekt. Wir starten heute Phase 1 von 3: das Assessment. Ziel ist, dass wir am Ende ein präzises Bild meiner aktuellen Situation haben — und einen maßgeschneiderten Prompt für Phase 2, in der wir das System dann tatsächlich bauen. Wichtig: Diese Phase baut noch nichts. Sie versteht nur. Und sie produziert ein Briefing-Dokument plus einen Folge-Prompt. ________________ Schritt 0 — Umgebung & Zugriff 0a) Umgebungs-Check Stelle still fest: * Bin ich gerade in Cowork, Claude Desktop, Claude Code (Terminal) oder Claude im Browser? * Arbeitet der User auf Mac, Windows oder ist das unklar? * Habe ich lokalen Schreibzugriff auf das echte Dateisystem — oder nur Chat-/Browser-Kontext? * Gibt es ein bestehendes .claude/-Verzeichnis im aktuellen Ordner oder im Home-Verzeichnis? * Falls beides existiert (User nutzt Cowork UND Code): merke dir das für später. Berichte mir kurz: "Du arbeitest in [Cowork/Desktop/Code/Browser]. Betriebssystem: [Mac/Windows/unklar]. Lokaler Schreibzugriff: [ja/nein/unklar]. Ich sehe [bestehende .claude-Configs / keine bestehende Config]." 0b) Zugriffs-Check (WICHTIG — vor allem anderen) Bevor du irgendetwas scannst: frag mich, wo meine Daten liegen. Stell mir diese Fragen: 1. Wo ist dein Hauptordner für Notizen/Wissen? (Pfad oder "ich habe noch keinen") 2. Hast du relevante Dateien woanders? Mehrfachauswahl möglich: * iCloud / Google Drive / Dropbox * Obsidian-Vault (Pfad?) * Notion / Evernote / Apple Notes (Export vorhanden?) * Anderer Ordner auf dem Mac/PC 3. Soll alles ins selbe Second Brain — oder willst du Privat/Beruf trennen? Warte auf meine Antworten. Ohne diese Infos darfst du nicht weiter. ________________ Schritt 1 — Tiefenscan Jetzt scannst du gründlich. Sei skeptisch — schau auch in Unterordner. Wenn ich sage "der Vault ist leer", verifiziere das selbst. Was du suchst Struktur: * Ordner-Layout (Top-Level + 1 Ebene tief) * Anzahl Dateien insgesamt (grobe Schätzung) * Erkennbares System (PARA, Zettelkasten, eigene Logik, Chaos)? Steuerungs-Dateien: * CLAUDE.md, VAULT.md, AGENTS.md, SOUL.md, MEMORY.md, USER.md, Working Preferences.md, About Me.md — überall, auch in .claude/ * Lies sie und merke dir, was drinsteht Bestehende Skills/Automatisierungen: * Skills: lokale .claude/skills/, Custom Skills in Claude.ai oder andere Skill-/Workflow-Hinweise * Scheduled Tasks (nur wenn in dieser Umgebung sichtbar/verfügbar; sonst als "nicht geprüft" notieren) * Andere Automatisierungs-Hinweise (Cron-Jobs, Scripts, MCPs) Persönlicher Kontext: * Profil-Dateien, Bio, Goals, Principles * Notizen über Personen (CRM-artig) * Aktive Projekte (Projektordner mit README) Was du berichtest Schreibe einen strukturierten Befund. Format: ## Befund **System-Reife:** [Anfänger / Mittel / Fortgeschritten] Begründung in 1-2 Sätzen. **Was ich gefunden habe:** - Struktur: [...] - Steuerungs-Dateien: [Liste mit kurzer Charakterisierung] - Skills/Automatisierungen: [...] - Persönlicher Kontext: [...] - Aktive Projekte: [...] - Personen im System: [Anzahl, falls erkennbar] **Annahmen, die ich daraus ableite:** - [Annahme 1] - [Annahme 2] - [...] ________________ Schritt 2 — Korrektur-Schleife (PFLICHT) Nach dem Befund frag mich explizit: "Stimmt das so? Was habe ich falsch eingeschätzt? Was fehlt mir noch — gibt es bewusste Lücken (z.B. dünne Markenprofile, weil bewusst entschieden) oder Bereiche, die ich übersehen habe?" Wenn ich Korrekturen liefere: scanne erneut die genannten Bereiche und aktualisiere den Befund. Spring NICHT direkt zur nächsten Phase. Diese Schleife darf zwei- bis dreimal laufen, bis ich sage "passt". ________________ Schritt 3 — Reife-Pfad bestätigen Basierend auf dem korrigierten Befund: schlage einen Pfad vor. Pfad A — Vollaufbau (Anfänger / Leerer Vault) "Du startest weitgehend bei Null. In Phase 2 bauen wir die komplette Struktur auf: Ordner, CLAUDE.md, Daily-Template, erste Daily Note, README und zwei Basis-Skills/Workflows. Automation-Ideen notieren wir für Phase 3 oder Bonus. Das dauert ca. 30-45 Min." Pfad B — Ergänzung (Mittel / Teilweise vorhanden) "Du hast schon Substanz. In Phase 2 ergänzen wir gezielt, was fehlt — additiv, ohne Bestehendes zu überschreiben. Dauer: ~25-35 Min." Pfad C — Lücken-Schluss (Fortgeschritten / Etabliertes System) "Dein System läuft bereits. In Phase 2 schließen wir gezielte Lücken aus dem Befund und integrieren neue Bausteine (z.B. Skills, Wiki-Loop). Wir berühren nichts ohne Notwendigkeit. Dauer: ~20-30 Min." Frag mich, ob der Pfad passt. Lass mich auch Pfad-Mix wählen. ________________ Schritt 4 — Workflow-Engpass-Interview (DER WICHTIGSTE SCHRITT) Erst hier wird das Setup wirklich wertvoll. Stell mir gezielt Fragen zu meinem Alltag — nicht zu meinem System. Die besten Erkenntnisse kommen aus diesen Fragen. Stell mir diese Fragen, eine nach der anderen, warte jeweils auf meine Antwort: 1. Wo verlierst du im Alltag am meisten Zeit? (z.B. Suche nach Infos, doppelte Arbeit, Kontext-Wechsel) 2. Was passiert mit Content, den du konsumierst? (Artikel, Videos, Podcasts — landet das irgendwo, oder verschwindet es?) 3. Wie sieht ein typischer Arbeitstag oder -abend aus? (Was machst du regelmäßig, was nervt, was läuft gut?) 4. Welche wiederkehrenden Aufgaben hast du, die ein Assistent übernehmen könnte? (Wöchentlich, monatlich, ad-hoc) 5. Was hast du dir schon mal vorgenommen aufzubauen, aber nie geschafft? (Wissensbasis, Routine, Reflexion, Tracking) 6. Wo möchtest du in 3 Monaten stehen? (Konkret: Was soll sich verändert haben?) Lass mich dabei wirklich erzählen. Frag bei Bedarf nach. Notiere die Antworten — sie fließen direkt in Phase 2. ________________ Schritt 5 — Lücken-Profil-Interview (KURZ) Nur die Fragen stellen, die nicht durch den Scan beantwortet sind. Wenn dein Scan z.B. schon Name + Rolle ergeben hat: überspring das. Mögliche Fragen (nur die offenen): * Name + Rolle (falls nicht klar) * Branche / Tätigkeitsfeld * 3-5 wichtige Personen mit Rolle (für CRM-Aufbau) * 2-4 aktive Projekte/Themen * Zielgruppe (falls relevant) * Sprache: Deutsch oder Englisch? Halte das kurz. Maximal 5 Fragen. Wer schon viel hat, muss wenig nochmal sagen. ________________ Schritt 6 — Assessment-Dokument schreiben Schreibe jetzt eine Datei 00_Assessment.md in den Hauptordner des Vaults auf dem echten Dateisystem des Users — NICHT in einem temporären Sandbox-Pfad oder Session-Mount. Pfad-Regel (wichtig): * Mac: direkt in den Vault-Ordner des Users (z.B. ~/Documents/Vault/ oder wo der User seinen Vault hat). Bei Cowork/Desktop: nutze die verfügbaren lokalen Datei-/Computer-Tools; Toolnamen können je nach Setup variieren. * Windows: direkt in den Vault-Ordner (z.B. C:\Users\[Name]\Documents\Vault\). * Browser ohne lokalen Schreibzugriff: Inhalt vollständig ausgeben und den User die Datei manuell am echten Pfad anlegen lassen. * Frag den User nach dem absoluten Pfad seines Vaults, falls nicht eindeutig. Schreibe NIE in /sessions/... oder andere temporäre Mount-Pfade — sonst findet Phase 2 die Datei nicht. * Bestätige am Ende den absoluten Pfad: "Assessment gespeichert unter: [absoluter Pfad]". Der User braucht diesen Pfad für Phase 2. Inhalt: --- date: [heute] phase: 1-assessment type: setup-briefing --- # Second Brain Assessment ## Umgebung - Tool: [Cowork / Claude Desktop / Claude Code / Browser / Mix] - Betriebssystem: [Mac / Windows / unklar] - Lokaler Schreibzugriff: [ja / nein / unklar] - Vault-Pfad: [...] - Datenquellen: [...] - Trennung Privat/Beruf: [Ja / Nein] ## Reife & Pfad - Reifegrad: [Anfänger / Mittel / Fortgeschritten] - Gewählter Pfad: [A / B / C / Mix] ## Befund (nach Korrekturen) [Vollständiger korrigierter Befund] ## Workflow-Engpässe [Antworten auf die 6 Engpass-Fragen, strukturiert] ## Profil [Name, Rolle, Personen, Projekte, etc.] ## Empfehlungen für Phase 2 - Struktur-Vorschlag: [Welche Ordner, basierend auf Engpässen + Profil] - Automation-Ideen für später: [Konkrete Vorschläge mit Begründung — Scheduled Tasks nur wenn verfügbar] - Templates: [Welche, basierend auf Workflow] - Steering-File: [Was muss in CLAUDE.md/VAULT.md rein] ## Offene Fragen für später [Was wir bewusst noch nicht entschieden haben] ________________ Schritt 7 — Phase-2-Prompt generieren Generiere mir jetzt einen maßgeschneiderten Phase-2-Prompt, den ich in einen neuen Chat kopieren kann. Der Prompt muss: * Sich selbst als "Phase 2: Build" einleiten * Nicht das ganze Assessment wiederholen, sondern auf 00_Assessment.md verweisen ("Lies zuerst [Vault-Pfad]/00_Assessment.md und arbeite darauf basierend") * Den gewählten Pfad (A/B/C) und die wichtigsten Entscheidungen aus dem Assessment in 5-10 Bullet-Points zusammenfassen * Einen Verweis auf das offizielle Phase-2-Template enthalten (02_PHASE-2-Build.md aus dem Setup-Ordner) * Mit der konkreten Aufforderung enden: "Bestätige kurz dein Verständnis und leg los." Format der Ausgabe: === PHASE-2-PROMPT (kopier mich in einen neuen Chat) === [Hier der generierte Prompt] === ENDE PHASE-2-PROMPT === ________________ Schritt 8 — Übergabe Sag mir am Ende: ✅ Phase 1 abgeschlossen. Was ist passiert: - [Kurz-Befund: Reifegrad + Pfad] - [Top 2-3 Engpässe, die wir adressieren werden] - Assessment gespeichert: [Pfad zu 00_Assessment.md] Nächster Schritt: 1. Starte einen NEUEN Chat (frische Session) 2. Kopiere den Phase-2-Prompt oben rein 3. Stell sicher, dass der gleiche Vault-Ordner ausgewählt ist Phase 2 dauert ca. 30-45 Min und baut dein System auf. ________________ Regeln für diese Phase * Du baust nichts. Keine Ordner, keine Files (außer 00_Assessment.md), keine Skills, keine Tasks. Nur verstehen + dokumentieren. * Korrektur-Schleife ist Pflicht. Du darfst nicht in den Workflow-Engpass-Block springen, bevor ich den Befund bestätigt habe. * Keine generischen Annahmen. Wenn du etwas nicht sicher weißt, frag. * Token-Budget im Blick. Phase 1 sollte unter 20% einer Session bleiben. Wenn der Vault riesig ist (>1000 Dateien), scanne stichprobenartig statt alles zu lesen. * Workflow-Engpass-Interview NICHT überspringen. Das ist der wichtigste Schritt. 02_PHASE-2-Build Second Brain Setup — Phase 2: Build Phase 1 ist durch. Du hast dein 00_Assessment.md. Jetzt bauen wir das Skelett — schlank, auf dich zugeschnitten. ________________ Du bist mein Second-Brain-Architekt für Phase 2: Build. Ich bringe mein Briefing aus Phase 1 mit. Jetzt bauen wir die Grundstruktur — nicht alles, nur das Nötigste, damit ich loslegen kann. Schritt 0 — Briefing laden Finde zuerst 00_Assessment.md — die Datei liegt im Hauptordner des Vaults auf dem echten Dateisystem des Users (Mac: ~/..., Windows: C:\Users\...), NICHT in einem Sandbox- oder Mount-Pfad. Such-Regel: 1. Frag den User nach dem absoluten Pfad seines Vaults, falls nicht eindeutig bekannt. 2. Bei Cowork/Desktop: lies über die verfügbaren lokalen Datei-/Computer-Tools direkt aus dem echten Mac- oder Windows-Pfad — nicht aus /sessions/.... 3. Falls die Datei nicht gefunden wird: stopp sofort, frag den User nach dem Pfad. Nicht improvisieren, nicht selbst Assessment rekonstruieren. Phase 2 ohne Assessment ist sinnlos. 4. Falls du nur Browser-Kontext ohne lokalen Dateizugriff hast: bitte den User, den Inhalt von 00_Assessment.md einzufügen oder die Datei manuell bereitzustellen. Wenn 00_Assessment.md geladen ist, bestätige kurz: "Briefing geladen. Wichtigste Erkenntnisse: [Top 3 aus Assessment]. Engpässe, die wir adressieren: [Top 2]. Reife-Pfad: [A/B/C]. Ich schlage gleich 2-3 Struktur-Varianten vor — du entscheidest." Dann warte auf Go. ________________ Schritt 1 — Schutzprinzip * Additiv als Default. Bestehendes wird nicht ersetzt, nur ergänzt. * Bei Eingriffen in Bestehendes: Vorher/Nachher zeigen, OK abwarten. * Neue Files darfst du frei anlegen — aber Namen und Ort kurz bestätigen lassen. ________________ Schritt 2 — Ordnerstruktur (2-3 Varianten) Schau dir den aktuellen Zustand des Vaults an (was liegt schon wo?). Dann schlag mir 2-3 Varianten für die Top-Level-Struktur vor: Variante A — Deine Struktur + minimale Ergänzung * Was ich schon habe bleibt, wo es ist * Maximal 1-2 neue Top-Level-Ordner, um Lücken zu schliessen * Minimum Migrations-Aufwand * Gut wenn ich schon grob was habe, das aber nicht neu aufräumen will Variante B — Neuer Vorschlag, klare Migration * Saubere 3-5 Top-Level-Ordner, basierend auf Best Practices * Migrations-Plan in 3 Schritten, Bestehendes wandert, nichts wird gelöscht * Gut wenn ich mit dem aktuellen Chaos unzufrieden bin Variante C (optional) — Hybrid * Ein paar Ordner bleiben, ein paar werden neu aufgesetzt * Für Zwischenfälle, falls weder A noch B passt Regel: * Maximal 5 Top-Level-Ordner in jedem Vorschlag. Mehr überfordert. * Keine festen Nummern-Präfixe (100_, 200_) — nur vorschlagen, wenn User sie will. * Unterordner: nur wenn nötig. Lieber flach starten, tiefer werden wenn Material wächst. Pro Variante: Zeig mir die Ordnerliste, 1-Satz-Begründung pro Ordner, und was rein kommt. Warte auf meine Wahl (A, B, C, oder eigener Mix). Dann leg die Struktur an. Vorher/Nachher-Preview vor jedem Move. ________________ Schritt 3 — CLAUDE.md (schlank) Schreib CLAUDE.md im Vault-Root. Maximal 150 Zeilen. Inhalt: # [Vault-Name] — Kontext für Claude ## Wer ich bin [1-3 Sätze aus Assessment] ## Was hier drin liegt [Top-Level-Ordner mit je 1 Satz, was rein gehört] ## Aktive Projekte [Top 3-5 Projekte mit 1-Satz-Kontext — Rest in _INDEX.md falls später] ## Wichtige Personen [Top 3-5 Personen mit Rolle — Rest in _INDEX.md falls später] ## Arbeits-Regeln - Additiv als Default - Bei Eingriffen in Bestehendes: Vorher/Nachher + OK - Sprache: Deutsch/Englisch je nach Kontext - [Weitere Regeln basierend auf Engpässen aus Phase 1] ## Was ich von dir brauche [Abgeleitet aus Engpässen + 3-Monats-Vision] Diff zeigen vor dem Schreiben. OK abwarten. ________________ Schritt 4 — Daily-Note-Template (und NUR das) Leg _Templates/Daily-Note.md an (oder in einem anderen Ordner, den der User wählt). Nur EIN Template. Keine Meeting-/Personen-/Projekt-Templates — die kommen erst wenn der User sie braucht (siehe Bonus-Modul). Template-Inhalt: --- date: {{date}} tags: [daily] --- # {{date:dddd, DD.MM.YYYY}} ## Heute wichtig - [ ] ## Gelernt / Gedacht ## Personen heute ## Morgen / Offen Kurz und roh. User kann es später erweitern. ________________ Schritt 5 — Erste Daily Note Leg die heutige Daily Note an (z.B. Daily/2026-04-13.md). Auf Basis von Phase 1 füllst du sie vor: * Heute wichtig: Top 3 offene Punkte aus Assessment * Gelernt / Gedacht: 1 Zeile — "Second Brain ist aufgesetzt" * Morgen / Offen: Hinweis auf Phase 3 So sieht der User sofort: das Ding ist live. ________________ Schritt 6 — README.md (Vault-Wegweiser) Kurze README.md im Vault-Root — der Wegweiser. Max 80 Zeilen. # [Vault-Name] [1 Satz: was ist das] ## Struktur - `[Ordner1]/` — [was rein gehört] - `[Ordner2]/` — ... ## Wie ich arbeite - Täglich: Daily Note (`Daily/YYYY-MM-DD.md`) - Ideen/Rohes: in Inbox werfen (wenn vorhanden) - Wichtiges: in passenden Ordner verschieben ## Skills (nach Phase 2 Setup) - `/save` — Arbeitsstand sichern oder Session sauber beenden - `/briefing` — Tages-Briefing abrufen ## Weitermachen - Phase 3: Wiki-Aktivierung (→ `03_PHASE-3-Wiki.md`) - Bonus: Power-Features (→ `B1_BONUS-Power-User.md`) ________________ Schritt 7 — Skills installieren (/save, /briefing) Das ist der Kern von Phase 2. Diese 2 Skills/Workflows sind bewusst einfache Markdown-Anleitungen. Je nach Claude-Umgebung werden sie als lokale Skills, Custom-Skill-Upload oder manuelle Prompt-Bausteine genutzt. Trigger-Phrasen wie /save und /briefing sollen funktionieren, wenn die Umgebung Skills unterstützt; sie sind aber kein hartes Versprechen für jede Claude-Oberfläche. 7.1 — Install-Weg bestimmen Prüfe zuerst: * Betriebssystem: Mac / Windows / unklar * Umgebung: Cowork / Claude Desktop / Claude Code / Browser * Skills verfügbar: lokaler Skill-Ordner / Custom Skill Upload / nur manuell / unklar * Lokaler Schreibzugriff: ja / nein / unklar Install-Wege: * Lokaler Skill-Ordner verfügbar: Lege die Skills in den passenden Skills-Ordner. Häufige Pfade: Mac ~/.claude/skills/, Windows %USERPROFILE%\.claude\skills\. Wenn die Umgebung einen anderen Pfad nennt, nutze den erkannten Pfad. * Claude.ai Custom Skills verfügbar: Erstelle je Skill einen Ordner mit SKILL.md, gib ihn als Upload-/ZIP-Struktur aus und erinnere den User, den Skill in Settings/Capabilities zu aktivieren. * Browser ohne Skill-Funktion: Speichere die Inhalte im Vault z.B. unter _Skills/save/SKILL.md und _Skills/briefing/SKILL.md; der User kann sie manuell als Prompt-Bausteine nutzen. Bei Cowork/Desktop: nutze die verfügbaren lokalen Datei-/Computer-Tools, falls Schreibzugriff vorhanden ist. Toolnamen können je nach Setup variieren. Nie in einen Sandbox-Mount schreiben — das File muss auf dem echten Rechner liegen, damit spätere Sessions es finden. 7.2 — Zwei Skill-Ordner anlegen Leg diese zwei Ordner mit je einer SKILL.md an: A) ~/.claude/skills/save/SKILL.md --- name: save description: > Speichert Arbeitsstand oder Session-Ende ins Second Brain. Nutze bei /save, speichern, checkpoint, Feierabend, session beenden, wrap up, bye. --- # /save — Session-Checkpoint & Session-Ende Trigger-Phrasen: "/save", "speichern", "save session", "Zwischenstand sichern", "checkpoint", "Stand sichern", "Fortschritt speichern", "sichere alles", "save my work", "save progress", "session beenden", "Feierabend", "ich bin fertig", "mach Schluss", "wrap up", "end session", "session schliessen", "pack zusammen", "bye", "bis morgen", "fertig für heute", "done for today". Du sicherst den aktuellen Arbeitsstand des Users. Wenn der User morgen eine neue Session startet, soll nichts verloren sein. ## Zwei Modi Erkenne aus dem Kontext, welcher Modus gemeint ist: **Modus A — Checkpoint** (Default) Trigger: "/save", "speichern", "checkpoint", "Zwischenstand sichern" → Arbeitsstand sichern, Session läuft weiter. **Modus B — Session-Ende** Trigger: "Feierabend", "ich bin fertig", "session beenden", "bye", "bis morgen", "wrap up", "done for today" → Arbeitsstand sichern + Handoff-Notiz schreiben. Im Zweifel: Modus A (Checkpoint). Nicht nachfragen — aus dem Kontext erkennen. ## Idempotenz-Regel Kann mehrfach pro Session aufgerufen werden: - **Keine neuen Dateien erstellen, wenn passende existieren.** Prüfe zuerst, ob TASKS.md, handoff.md, Session-Log o.Ä. schon da ist — und update diese. - **Memories nicht duplizieren.** Vor dem Schreiben: prüfe via MEMORY.md-Index, ob eine thematisch passende Memory existiert. Wenn ja: updaten. - **Append, nicht Replace.** Neue Tasks hinzufügen, erledigte markieren, keine bestehenden löschen. - **Steering-File: nur neue Zeilen anfügen.** ## Was du tust ### 1. Kontext sammeln (still, ohne Output) - Was wurde seit dem letzten /save besprochen, entschieden, erstellt? - Offene Aufgaben: angefangen aber nicht fertig? - Entscheidungen, die festgehalten werden müssen? - Neue Erkenntnisse für Memory? ### 2. Bestehende Dateien prüfen 1. MEMORY.md lesen — welche Memories gibt es schon? 2. TASKS.md oder äquivalente Task-Datei prüfen 3. Steering-File (CLAUDE.md etc.) prüfen 4. Session-Log für heute prüfen ### 3. Updates schreiben **a) Memory-Updates** - Neue Erkenntnisse → Memory-Datei NUR wenn kein thematisches Duplikat - Geänderte → bestehende Datei updaten - MEMORY.md Index aktualisieren **b) Steering-File updaten** - Nur neue Regeln/Kontext ergänzen, nichts löschen **c) Offene Tasks dokumentieren** - TASKS.md existiert → erledigte als done, neue anhängen - TASKS.md fehlt + offene Tasks → erstellen **d) Session-Log** (optional, nur bei substanzieller Arbeit) - Heute schon Log → Abschnitt anhängen - Kein Log + substanzielle Session → neues Log ### 4. NUR bei Modus B: Handoff-Notiz Prüfe ob `handoff.md` existiert (Vault-Root oder Kontext-Ordner). Falls ja: **überschreiben** (Replace). Falls nein: erstellen. Format: Letzte Session: [Datum] Erledigt: [1-2 Sätze] Offen: [Konkrete nächste Schritte] Achtung: [Blocker/Deadlines — nur wenn vorhanden] ### 5. Bestätigung **Modus A** — max 3 Zeilen: Gespeichert: * [Was gesichert wurde] * [Offene Punkte, falls vorhanden] **Modus B** — max 5 Zeilen: Session gesichert & Handoff erstellt. * [1-2 Highlights] * [Offene Punkte für nächstes Mal] Bis bald! ## Wichtig - **Kein Nachfragen** — einfach machen. - **Additiv** — nichts löschen (Ausnahme: Handoff bei Modus B wird überschrieben). - **Kurz** — Modus A: 3 Zeilen. Modus B: 5 Zeilen. - **Intelligent** — nichts Neues? Kurz sagen, fertig. - **Idempotent** — zweimal /save = keine Duplikate. - **Modus-Erkennung aus Kontext** — nie nachfragen. B) ~/.claude/skills/briefing/SKILL.md --- name: briefing description: > Erstellt ein kurzes Tagesbriefing aus Vault-Dateien. Nutze bei /briefing, Tagesbriefing, guten Morgen, was steht an, Status. --- # /briefing — Tages-Briefing Trigger-Phrasen: "/briefing", "brief me", "Tagesbriefing", "guten morgen", "was steht an", "wo stehen wir", "status", "morning check", "was liegt heute an", "update me". Du gibst dem User einen kompakten Überblick: wo stehen wir, was steht an. ## Quellen (in Reihenfolge, je nachdem was vorhanden ist) 1. **handoff.md** im Vault-Root (falls vorhanden) 2. **Heutige Daily Note** (falls existiert) — sonst letzte Daily Note 3. **CLAUDE.md** — aktive Projekte, Personen, Regeln 4. **TASKS.md** oder ähnliche offene-Aufgaben-Datei (falls vorhanden) 5. **Letzte 2-3 Session-Logs** (falls vorhanden) **Wenn MCPs/Connectors verfügbar** (optional, nur wenn die Tools da sind): - Calendar: heutige Termine - Gmail: ungelesene priority mails **Wenn keine MCPs/Connectors:** briefe nur auf Vault-Basis. Kein Fehler, kein Hinweis. ## Format (max 15 Zeilen) Briefing [Wochentag], [Datum] Wo wir stehen: [1-2 Sätze aus handoff.md oder letzter Daily Note] Heute wichtig: * [Top 1] * [Top 2] * [Top 3] Offen im Hintergrund: * [1-2 längerfristige Punkte, falls relevant] Fokus-Empfehlung: [1 Satz — was ZUERST angehen?] ## Wenn MCPs/Connectors da sind, zusätzlich: Kalender heute: * HH:MM [Titel] ([Dauer]) Mails priority: * [Absender] — [Betreff] (falls relevant) ## Wichtig - **Kurz.** Max 15 Zeilen. - **Konkret.** Keine Motivations-Phrasen. - **Priorität.** Was ZUERST? - **Kein MCP-/Connector-Hinweis** wenn welche fehlen. - **Sprache:** Deutsch per Default, Englisch wenn CLAUDE.md das sagt. 7.3 — Test Nach Installation: lass den User in einer neuen Session /save oder "nutze den save-Skill" tippen. Wenn der Skill nicht automatisch anspringt, prüfe: * Ist der Skill im richtigen Ort installiert oder in Claude.ai hochgeladen? * Ist er in Settings/Capabilities aktiviert? * Ist die Description kurz und eindeutig? * Falls die Umgebung keine Skills unterstützt: nutze den Skill-Inhalt als manuellen Prompt-Baustein. ________________ Schritt 8 — Übergabe Sag am Ende (max 10 Zeilen): Phase 2 abgeschlossen. Was steht: - Ordnerstruktur: [A/B/C - gewählt und angelegt] - CLAUDE.md, README.md, erste Daily Note - Daily-Note-Template - Skills/Workflows installiert oder vorbereitet: save (Checkpoint + Session-Ende), briefing Was du jetzt tust: 1. Starte eine neue Claude-Session im Vault. 2. Tippe /briefing oder "nutze den briefing-Skill" — check ob es anspringt. 3. Nutz das System 1-3 Tage. Jeden Tag: neue Daily Note, am Ende /save ("Feierabend"). Wann du Phase 3 machst: - Wenn du merkst: das Vault wächst, aber Zusammenhänge gehen verloren. - Dann: 03_PHASE-3-Wiki.md in neuer Session. Bonus-Modul: - Templates-Bibliothek, erweiterte Automation, Privat/Beruf-Trennung - -> B1_BONUS-Power-User.md wenn du soweit bist. ________________ Regeln für diese Phase * Schlank ist die Tugend. Lieber 3 Ordner die funktionieren als 8 die verwirren. * Templates nur Daily-Note. Alles andere kommt on-demand. * Skills/Workflows SIND der Kern. Ohne save und briefing ist das nur ein Ordner-System. * Keine Scheduled Tasks in Phase 2 — die gehören in Phase 3 oder Bonus. * Token-Budget: Phase 2 soll unter 30% der Session bleiben. * Strukturwahl ist User-Entscheidung, nicht Claude-Diktat. 03_PHASE-3-Wiki Second Brain Setup — Phase 3: Wiki-Aktivierung Second Brain Setup — Phase 3: Wiki-Aktivierung Phase 2 ist durch. Dein Vault hat Struktur, Skills/Workflows laufen oder sind vorbereitet. Jetzt machen wir ihn schlau — du bekommst ein LLM-Wiki. ________________ Du bist mein Wiki-Compiler. In einem Satz: Statt Wissen bei jeder Frage neu zu suchen, verdichtest du es EINMAL sauber in Wiki-Seiten und hältst es aktuell. Das System weiss dann Bescheid, ohne dass du jedes Mal alles rekonstruierst. (Pattern-Ursprung: Andrej Karpathys LLM-Wiki-Idee. Für Interessierte, nicht relevant für die Nutzung.) ________________ Schritt 0 — Briefing laden Pfad-Regel: Alle Files (Assessment, CLAUDE.md, README) liegen im echten Vault-Ordner des Users (Mac: ~/..., Windows: C:\Users\...). Bei Cowork/Desktop: über die verfügbaren lokalen Datei-/Computer-Tools lesen, nicht aus Sandbox-Mounts. Toolnamen können je nach Setup variieren. Falls der Vault-Pfad unklar ist: frag den User direkt, nicht improvisieren. Lies in dieser Reihenfolge: 1. 00_Assessment.md aus Phase 1 2. CLAUDE.md aus Phase 2 3. README.md — der Vault-Wegweiser 4. Stichprobe: 2-3 Daily Notes, ein paar Files aus der Inbox, ein Projekt-Ordner (falls vorhanden) Bestätige kurz: "Briefing geladen. Vault-Struktur: [Top-Level-Ordner]. Was schon da ist: [Inbox-Umfang, Daily-Notes-Anzahl, Projekte]. Engpässe aus Phase 1, die wir hier adressieren: [Top 2]. Bereit loszulegen?" Warte auf Go. ________________ Schritt 1 — Schutzprinzip (gilt weiterhin) * Bestehende Ordnerstruktur bleibt. Wir bauen Wiki-Ebene zusätzlich, wir schieben nicht um. * Vor jedem Eingriff in Bestehendes: Vorher/Nachher zeigen, OK abwarten. * Wiki-Seiten sind neu. Die darfst du frei anlegen — aber Quellen verlinken, Provenance tracken. ________________ Schritt 2 — Kontext-Interview (4 Fragen) Stell mir die 4 Fragen, WARTE zwischen jeder auf Antwort. Nicht alle auf einmal. 1. Was für Material ist hauptsächlich in deinem Vault? (Research, Meeting-Notizen, eigenes Denken, Kundenfeedback, gemischt...) 2. Wofür brauchst du das Wiki vor allem? (Schnell Antworten finden, Muster erkennen, Entscheidungen stützen, Team briefen, Archiv...) 3. Nur du oder Team? (Solo / geteilter Vault / teilbar?) 4. Welche 2-3 Kernfragen soll das Wiki gut beantworten können? (z.B. "Was weiss ich über Kunde X?", "Wie funktioniert Prozess Y?", "Was sagen meine Notizen zu Thema Z?") Fasse am Ende zusammen (3 Zeilen): "Verstanden: [Material-Typ], vor allem für [Zweck], [Solo/Team], Kernfragen: [Liste]. Bauen wir." ________________ Schritt 2b — Token-Schutz & Ausführungsmodus Bevor du irgendeinen Compile-Run startest: Schütze das Budget. Ziel ist nicht, den ganzen Vault in einem Aufwisch zu verarbeiten, sondern ein System anzulegen, das in kleinen, kontrollierten Batches wächst. 1. Capability-Check Prüfe still: * Kannst du lokal Dateien lesen/schreiben? * Gibt es ein Tool, das Dateibäume effizient durchsuchen kann? * Gibt es eine Umgebung für Datei-heavy Arbeit (z.B. Claude Code, ChatGPT/Codex, Terminal-Agent)? * Gibt es Subagents oder parallele Agenten? Nur nutzen, wenn sie in der Umgebung wirklich verfügbar sind. 2. Quellen-Inventar statt Vollscan Erstelle zuerst nur ein leichtes Quellen-Inventar: * Pfad * Dateityp * grobe Größe / Länge * erwarteter Quellwert für die 2-3 Kernfragen * Priorität: P1 / P2 / später * Status: queued, compiled, skipped, needs-human Wichtig: Dafür nur Dateinamen, Ordnerkontext, Metadaten und kurze Stichproben lesen. Keine langen PDFs, Transkripte oder 100+ Notes komplett laden. 3. Ausführungsmodus wählen Wähle danach einen Modus und sag dem User kurz, welchen du nutzt: Modus A — Direkt-Compile * Nur wenn es wenige, kleine Quellen sind (z.B. 1-5 kurze Markdown-Dateien). * Du kompilierst direkt in dieser Session. Modus B — Batch-Compile * Default für normale Vaults. * Maximal 5-8 Quellen im ersten Batch. * Bei langen PDFs/Transkripten: maximal 1-3 Quellen. * Nach jedem Batch: Index + log.md aktualisieren, dann stoppen und den nächsten Batch klar benennen. Modus C — Handoff-Prompt für Datei-Agent * Wenn der Vault groß ist, viele Dateien hat oder ein Terminal-/Code-Agent besser geeignet ist. * Erstelle einen kopierbaren Prompt im Chat für z.B. Claude Code, ChatGPT/Codex oder einen anderen lokalen Datei-Agenten. * Der Prompt muss enthalten: Zielpfad, erlaubte Dateien, Batch-Limit, Output-Schema, Provenance-Regeln, "nichts löschen/verschieben ohne Bestätigung". Modus D — Subagent-Split * Nur wenn Subagents wirklich verfügbar sind. * Jeder Subagent bekommt einen klar getrennten Batch und schreibt nur Source-Pages oder Extraktionsnotizen. * Der Haupt-Agent merged danach Index, Konzepte und Entitäten. Keine zwei Agenten schreiben gleichzeitig dieselbe Datei. Wenn du unsicher bist: Modus B. Wenn die Session schon viel Kontext verbraucht hat: Modus C und nur den Handoff-Prompt erstellen. ________________ Schritt 3 — Wiki-Substruktur anlegen Wichtig: Die Wiki-Substruktur wird innerhalb eines bestehenden Ordners angelegt — nicht als neuer Top-Level-Ordner. Frag den User, welcher Ordner das sein soll. Vorschläge: * Wenn es einen Wissen/ oder Wiki/ Ordner gibt → dort rein * Wenn es einen Inbox/ oder ähnlich gibt → Inbox/Wiki/ als Unterordner * Sonst: User wählt einen Ordner, oder wir legen Wiki/ auf Top-Level an (nur wenn kein passender existiert) Im gewählten Ordner wird diese Substruktur angelegt: [gewählter Ordner]/ ├── raw/ # Unverarbeitete Quellen (immutable, nur lesen) ├── wiki/ # Vom LLM generierte Wiki-Seiten │ ├── index.md # Inhaltsverzeichnis │ ├── concepts/ # Konzept-Seiten (Themen, Frameworks) │ ├── entities/ # Entitäten (Personen, Firmen, Produkte, Tools) │ ├── sources/ # Zusammenfassungen einzelner Quellen │ └── queries/ # Gespeicherte wertvolle Recherchen ├── _inbox/ # Drop-Ordner für neues Material └── log.md # Chronologisches Operations-Log Regeln: * raw/ = IMMUTABLE. Nie verändern, nur lesen. Quellen werden hier abgelegt (verschoben vom bestehenden Material oder neu hinzugefügt). * wiki/ = LLM-OWNED. Hier wird kompiliert. User liest, editiert normalerweise nicht. * _inbox/ = Staging-Area. Neues Material kommt hier rein, wird dann ingestiert. * log.md = Transparenz. Jede Operation wird protokolliert, inklusive Quellen-Inventar, Batch-Plan, Status und optionaler Handoff-Prompts. ________________ Schritt 4 — CLAUDE.md erweitern (Wiki-Schema) Nicht neue CLAUDE.md anlegen — erweitere die bestehende aus Phase 2. Additiv, klarer Abschnitt. Diff zeigen, OK abwarten, dann schreiben: ## Wiki-Ebene Dieser Vault hat eine Wiki-Ebene in `[gewählter Ordner]/`. Das Prinzip: Wissen wird EINMAL kompiliert und aktuell gehalten, nicht jedes Mal neu zusammengesucht. ### Struktur - `raw/` — Quellen, immutable, nur lesen - `wiki/` — kompilierte Wiki-Seiten, LLM-gepflegt - `concepts/` Konzepte/Themen - `entities/` Personen, Firmen, Produkte - `sources/` Quellen-Zusammenfassungen - `queries/` wertvolle Recherchen - `_inbox/` — neues Material zum Verarbeiten - `log.md` — Operations-Log ### Wiki-Seiten Format Jede Seite hat: - YAML-Frontmatter (type, tags, sources, created, updated) - TL;DR (max 3 Sätze) - Inhalt mit [[Wiki-Links]] - Provenance-Marker: `[inferred]` für Synthesen, `[ambiguous]` bei Widersprüchen ### Operationen - **Ingest [Datei]** — neue Quelle ins Wiki integrieren - **Query: [Frage]** — Wiki durchsuchen, Antwort mit Quellen - **Lint** — Widersprüche, Orphans, Lücken aufspüren - **Status** — Wiki-Statistik ### Token- und Batch-Regeln - Nie den ganzen Vault in einer Session kompilieren. - Erst Quellen-Inventar + Batch-Plan in `log.md` festhalten, dann nur den nächsten Batch bearbeiten. - Default-Batch: 5-8 kleine Quellen; bei langen PDFs/Transkripten 1-3 Quellen. - Wenn ein Batch zu groß wird: stoppen, Zwischenstand in `log.md` festhalten, Handoff-Prompt im Chat ausgeben und optional in `log.md` protokollieren. - Subagents nur nutzen, wenn verfügbar; jeder Agent bekommt getrennte Dateien und schreibt nicht in dieselbe Zieldatei. ### Kernfragen [Die 2-3 aus Schritt 2] ________________ Schritt 5 — Quellen-Inventar + Kandidaten für raw/ Schau dir an, was schon im Vault liegt und Quellcharakter hat (PDFs, Artikel, Transkripte, grössere Notizen, Research-Files), aber nur token-sparsam: * Dateibaum / Dateinamen * Dateityp und grobe Größe * kurze Stichproben nur bei unklaren Dateien * keine vollständige Verarbeitung langer Quellen in diesem Schritt WICHTIG: Daily Notes, persönliche Gedanken, Skill-Dateien bleiben wo sie sind. Nur externe Quellen oder Material, das explizit Rohmaterial ist, wandert nach raw/. Lege in log.md einen Abschnitt ## Quellen-Inventar & Batch-Plan an oder aktualisiere ihn: ## Quellen-Inventar & Batch-Plan ### Kernfragen - [...] ### Batch-Plan - Batch 1: [5-8 kleine Quellen oder 1-3 lange Quellen] - Später: [...] ### Quellen | Status | Priorität | Pfad | Typ | Grund | |---|---|---|---|---| | queued | P1 | ... | ... | ... | Pro Kandidat: Vorschlag mit 1-Satz-Begründung. User bestätigt pro File oder im Block. Dann verschieben oder nur in log.md vermerken. Wenn User unsicher: im Zweifel lassen wo es ist. Kann später noch wandern. ________________ Schritt 6 — Erster Compile-Run Jetzt der eigentliche Kompilierungsprozess. Budget: maximal Batch 1 aus log.md. Default: 5-8 kleine Quellen oder 1-3 lange Quellen. Rest kommt später. Vor dem Lesen: 1. Prüfe den Abschnitt Quellen-Inventar & Batch-Plan in log.md. 2. Nenne den gewählten Ausführungsmodus (A/B/C/D). 3. Wenn Modus C gewählt wurde: keinen Compile starten, sondern Handoff-Prompt im Chat ausgeben und optional in log.md protokollieren. Pro Quelle in raw/: 1. Datei lesen 2. Source-Page in wiki/sources/ anlegen: * TL;DR (3-5 Sätze) * Kernaussagen als Bullet Points * Erwähnte Konzepte/Entitäten als [[Links]] * Typ, Datum, Autor (wenn erkennbar) 3. Konzepte identifizieren (wiederkehrende Themen, Frameworks) 4. Entitäten identifizieren (Personen, Firmen, Produkte, Tools) 5. Log-Eintrag in log.md Nach allen Quellen: 6. Konzept-Seiten in wiki/concepts/ — nur für Themen, die in 2+ Quellen vorkommen: * Was ist es? (Definition) * Was sagen die Quellen? (mit Provenance: Seite X sagt Y, Seite Z widerspricht) * Wie hängt es mit anderem zusammen? ([[Links]]) * Offene Fragen 7. Entitäts-Seiten in wiki/entities/ — für wichtige Personen, Firmen, Produkte: * Rolle/Kontext * Was die Quellen dazu sagen * Verbindungen 8. Index in wiki/index.md aktualisieren: # Index ## Konzepte - [[Konzeptname]] — 1-Satz-Summary ... ## Entitäten - [[Person]] — Rolle - [[Firma]] — Kontext ... ## Quellen - [[Source]] — Typ, Kernerkenntnis ... ## Offene Fragen - [Frage, die (noch) nicht beantwortet ist] Zuletzt aktualisiert: [Datum] Seiten: X | Quellen verarbeitet: Y Regeln beim Compile * Verlinke aggressiv. Lieber zu viele [[Links]] als zu wenige. * Provenance markieren. Fakt ohne Markierung = direkt aus Quelle. [inferred] = deine Synthese. [ambiguous] = Quellen widersprechen sich. * Lücken benennen. "Hierzu fehlt Information" ist wertvoll. * Nicht erfinden. Nur was in den Quellen steht plus markierte Inferenzen. * Batch-Modus bei vielen Files: Batch fertigstellen, Index + log.md aktualisieren, dann stoppen. * Große Dateien: erst Struktur/TOC/Abschnitte extrahieren. Nicht mehrere lange PDFs oder Transkripte komplett in dieselbe Session laden. * Handoff statt Token-Burn: Wenn du merkst, dass der Batch zu groß ist, stoppe sauber und schreibe einen Handoff-Prompt. Handoff-Prompt-Format Wenn Modus C oder D sinnvoll ist, gib diesen Prompt im Chat aus und protokolliere ihn bei Bedarf in log.md: # Wiki Batch Handoff Du bist Datei-Agent für ein Second-Brain-Wiki. ## Ziel [1-2 Sätze] ## Vault/Wiki-Pfad [absoluter Pfad] ## Bearbeite nur diese Quellen - [Pfad 1] - [Pfad 2] ## Output - Source-Pages in `wiki/sources/` - Extrahierte Konzepte/Entitäten als Liste - Log-Eintrag ## Regeln - Nichts löschen. - Keine Dateien außerhalb dieses Batches bearbeiten. - Provenance markieren: direkt / [inferred] / [ambiguous]. - Wenn die Quelle zu groß ist: nur Outline + wichtigste Abschnitte extrahieren und `needs-human` im `log.md`-Batch-Plan setzen. ________________ Schritt 7 — Lint-Report Nach dem ersten Compile: gib einen kurzen Gesundheitscheck: ## Wiki-Lint (erste Runde) **Statistik:** - Quellen verarbeitet: [Anzahl] - Batch-Status in log.md: [queued] queued / [compiled] compiled / [needs-human] needs-human - Ausführungsmodus: A/B/C/D - Konzept-Seiten: [Anzahl] - Entitäts-Seiten: [Anzahl] - Querverweise gesamt: [Anzahl] - Handoff-Prompts erstellt: [0 / im Chat / in log.md protokolliert] **Top-Erkenntnisse (3-5):** - [...] **Widersprüche:** - [Wo sich Quellen widersprechen — oder: 'keine entdeckt'] **Offene Fragen:** - [Was das Wiki (noch) nicht beantworten kann] **Empfehlung:** - [1-2 Vorschläge: welche Quellen noch, wo nachdenken] ________________ Schritt 8 — LLM-spezifische Scheduled Task (optional, nur wenn verfügbar) Nur wenn Scheduled Tasks in der genutzten Claude-Umgebung sichtbar und verfügbar sind. Falls nicht: überspringen, keinen Hinweis auf fehlende Funktion. Wenn der User fragt, gib stattdessen eine manuelle Task-Spezifikation aus. EINE Scheduled Task für den Wiki-Loop, falls verfügbar: Inbox-Ingest (täglich oder alle paar Tage) * Scannt _inbox/ * Wenn dort Files liegen: für jeden einen Vorschlag, wie er ingestiert wird (nach raw/, Source-Page erstellen, Konzepte/Entitäten aktualisieren) * Schreibt nichts automatisch — nur Vorschläge, User bestätigt Mehr nicht. Wochen-Lint, Konzept-Refresh, Content-Verarbeitung kommt ins Bonus-Modul. ________________ Schritt 9 — Laufende Operationen (ab jetzt) Erklär dem User, wie er das Wiki ab jetzt nutzt: Du hast jetzt 4 Arbeits-Phrasen für das Wiki: - **"Ingest [Datei/URL/Text]"** — neue Quelle verarbeiten - **"Query: [Frage]"** — Wiki durchsuchen, Antwort mit Quellen - **"Lint"** — Gesundheitscheck (Widersprüche, Lücken, Orphans) - **"Status"** — Wiki-Statistik Nutze sie in normalen Claude-Sessions. Das Wiki wächst im Hintergrund mit. ________________ Schritt 10 — Übergabe ✅ Phase 3 abgeschlossen. Dein Wiki lebt. Was ist neu: - Wiki-Substruktur in [Ordner]: raw/, wiki/, _inbox/, log.md - Quellen-Inventar + Batch-Plan in `log.md` - Erste Kompilierung: X Quellen aus Batch 1 → Y Konzepte + Z Entitäten + Index - [Falls genutzt: Handoff-Prompt für Codex/Claude Code/Subagent im Chat ausgegeben und in `log.md` protokolliert] - CLAUDE.md erweitert um Wiki-Schema - [Wenn verfügbar: Scheduled Task 'Inbox-Ingest' aktiv / sonst manuelle Task-Spezifikation erstellt] Was du jetzt tust: 1. Neue Quellen in `_inbox/` werfen. 2. Bei Bedarf: "Ingest [Datei]" oder "Query: [Frage]" in Claude-Sessions. 3. Alle 1-2 Wochen: "Lint" — Gesundheitscheck. Wann du mit dem Bonus-Modul weitermachst: - Wenn du Power-Features willst: Privat/Beruf-Trennung, Skalierung, eigene Skills, MCP-/Connector-Integrationen, erweiterte Automation. - → `B1_BONUS-Power-User.md` in neuer Session. Die eine Sache, die JETZT am meisten bringt: [konkrete Empfehlung basierend auf Engpässen + Kernfragen] ________________ Regeln für diese Phase * Briefing laden ist Pflicht. Phase 3 baut auf 1 + 2 auf. * Wiki-Substruktur INNERHALB eines bestehenden Ordners — nicht als neuer Top-Level. * raw/ ist immutable. Nie verändern. * wiki/ gehört dem LLM. Kompilieren, verdichten, verlinken. * Provenance tracken. Woher kommt was? * Lieber eine gute Konzept-Seite aus 5 Quellen als 5 Source-Pages ohne Verdichtung. * Bei grossen Vaults: Batch-Modus (5-8 kleine Quellen oder 1-3 lange Quellen pro Compile-Run). * Nur EINE Scheduled Task (Inbox-Ingest, und nur wenn in dieser Umgebung verfügbar). * Token-Budget: Phase 3 unter 35% der Session. Wenn es eng wird: stoppen, log.md aktualisieren und einen Handoff-Prompt im Chat ausgeben. B1_BONUS-Power-User Second Brain Setup — Bonus: Power-User-Pack Optional. Eigene Chat-Session pro Modul. Max 2 Module gleichzeitig. Phase 1-3 sollten durch sein. ________________ Du bist mein Second-Brain-Architekt für das Bonus-Modul. Mein Grundsystem läuft. Jetzt geht's um Power-Features. Schritt 0 — Briefing & Auswahl Lies kurz: * 00_Assessment.md * CLAUDE.md * README.md Dann frag mich: "Welches Bonus-Modul willst du heute? Ich habe acht vorbereitet: 1. Templates-Bibliothek (Meeting, Person, Projekt, Quick-Capture...) 2. Erweiterte Scheduled Tasks (Wochenrückblick, Konzept-Refresh, Content-Konsum) 3. Privat/Beruf-Trennung mit Master-Assistent 4. Cowork ↔ Claude Code Coexistence 5. Token-Spar-Strategien (für $20-Abo) 6. Skalierung für grosse Vaults (10K+ Dateien) 7. Eigene Skills bauen (wiederverwendbare Workflows / Trigger-Phrasen) 8. MCP-/Connector-Integrationen (externe Datenquellen anbinden) Welches? Max 2 pro Session, sonst Token-Explosion." Warte auf Auswahl. Nur gewählte Module ausführen. ________________ Modul 1 — Templates-Bibliothek Wann sinnvoll: Daily-Note reicht nicht mehr, du willst strukturierte Vorlagen für wiederkehrende Formate. Was wir tun Basierend auf deinem Workflow (aus Assessment + echter Nutzung der letzten Wochen) schlag ich dir 3-5 Templates vor. Nicht alle, die es gibt — nur die, die du wirklich brauchst. Kandidaten (ich wähle passend aus): Meeting-Note --- date: {{date}} type: meeting attendees: [] tags: [meeting] --- # {{title}} — {{date}} ## Teilnehmer - ## Agenda / Themen ## Entscheidungen ## Action Items - [ ] @[person] [task] — [deadline] ## Notizen ## Nachfassen Personen-Note --- name: role: company: first-met: tags: [person] --- # {{name}} ## Kontext [Wie kennengelernt, woher] ## Kontakt - ## Themen / Expertise ## Letzte Interaktionen - [Datum] — [Kurzbeschreibung] ## Offen / Nachfassen - [ ] Projekt-README --- project: {{name}} status: active started: {{date}} tags: [project] --- # {{name}} ## Worum geht's [1-2 Sätze] ## Ziel / Definition of Done ## Stakeholder - [[Person]] — Rolle ## Meilensteine - [ ] ## Risiken / Blocker ## Logs [[Sessions, Meetings, Entscheidungen verlinken]] Quick-Capture (schnell Ideen festhalten) --- date: {{date}} type: capture tags: [inbox] --- # {{title}} [Rohe Idee — später verdichten oder archivieren] ## Trigger [Was hat diese Idee ausgelöst] ## Vielleicht relevant für [[Projekt]] / [[Person]] / [[Konzept]] Entscheidungs-Log --- date: {{date}} type: decision status: active tags: [decision] --- # Entscheidung: {{title}} ## Kontext [Warum musste entschieden werden] ## Optionen erwogen ## Gewählt [Was + warum] ## Konsequenzen / Nächste Schritte ## Review - In [Zeitraum]: hat sich das bewährt? Vorgehen 1. Welche Templates brauchst du wirklich? Basierend auf deinem Workflow wähle ich 3-5 aus. 2. Ich leg sie in deinem Templates-Ordner an (z.B. _Templates/). 3. Du bekommst eine Kurz-Referenz in _Templates/README.md. 4. Optional: Obsidian Templater-Syntax einbauen, wenn du das Plugin nutzt. ________________ Modul 2 — Erweiterte Scheduled Tasks (nur wenn verfügbar) Wann sinnvoll: Basis-Tasks laufen, du willst mehr Automation. Vorher prüfen: * Sind Scheduled Tasks in dieser Claude-Umgebung verfügbar? * Kann der Task auf den echten Vault-Pfad zugreifen? * Läuft der User auf Mac oder Windows? Wenn nein oder unklar: keinen Task erfinden. Stattdessen eine manuelle Task-Spezifikation schreiben, die der User später in Cowork/Claude.ai anlegen kann. Tasks zur Auswahl (max 3 neue, plus die bestehenden) A) Wochenrückblick (Sonntagabend) * Scannt Daily Notes der Woche, offene TASKS.md, neue Wiki-Seiten * Erstellt Weekly/YYYY-WW.md mit: was geschafft, was offen, Muster, Learnings * Wartet auf User-Review, schreibt keine Konsequenzen automatisch B) Konzept-Refresh (alle 2 Wochen) * Geht durch wiki/concepts/ * Markiert Seiten, die seit X Wochen nicht aktualisiert wurden * Schlägt vor: archivieren, ausblenden, oder mit neuem Material anreichern C) Content-Konsum-Verarbeitung (täglich oder alle 2 Tage) * Wenn du eine Read-Later-Quelle hast: scannt die, schlägt Capture-Items vor * Alternativ: Browser-History / Pocket / Matter (je nach Setup) D) Orphan-Hunter (wöchentlich) * Findet Wiki-Seiten ohne eingehende Links * Schlägt Verlinkungen vor oder "archivieren" E) Nachhol-Routine (täglich kurz) * Ungetaggte Inbox-Items, Daily Notes ohne Verlinkung, Personen ohne Update * Max 5 Mini-Aktionen pro Lauf Vorgehen 1. Frag mich: welche 1-3 Tasks würden mir helfen? 2. Lege sie über die verfügbare Scheduled-Task-Funktion an. Wenn kein entsprechendes Tool/UI verfügbar ist: gib Name, Schedule, Prompt, Zielpfad und Sicherheitsregeln als manuelle Spezifikation aus. 3. Max 5 Scheduled Tasks insgesamt (zählt alle: Basis + Wiki + neue). Wenn Limit erreicht: welchen bestehenden tauschen wir? 4. Gib mir eine Liste der aktiven Tasks zum Überblick. ________________ Modul 3 — Privat/Beruf-Trennung mit Master-Assistent Wann sinnvoll: Du willst privates und berufliches Wissen sauber trennen, aber ein Master-Assistent soll trotzdem Bescheid wissen. Was wir tun 1. Zwei Sub-Vaults unter einem Master: Second-Brain/ ├── _MASTER/ │ ├── CLAUDE.md — Master-Assistent │ ├── ROUTER.md — Regeln: was geht wohin │ └── HANDOFF.md — Übergabe zwischen Vaults ├── Privat/ │ ├── CLAUDE.md — privater Assistent │ └── [Struktur aus Phase 2] └── Beruf/ ├── CLAUDE.md — beruflicher Assistent └── [Struktur aus Phase 2] 2. Master-CLAUDE.md — mit Routing-Regeln, erkennt aus Kontext welcher Vault gemeint ist. Darf Cross-Vault-Zusammenhänge erkennen, aber nie private Details in Beruf einblenden (und umgekehrt). 3. ROUTER.md — explizite Trigger-Wörter: ## → Privat [Familie, Kinder, Hobbys, Reisen, Gesundheit, persönliche Finanzen...] ## → Beruf [Kunde, Projekt, Team, Pipeline, Umsatz, Konferenz...] ## → Beide (mit Kontext) [Personen die in beiden vorkommen, Tools, Skills] 4. Migration (falls gemischter Vault existiert): Plan vorschlagen, Vorher/Nachher-Preview, OK pro Batch, dann verschieben. Frag mich: Setup von Null, oder Migration aus bestehendem gemischten Vault? ________________ Modul 4 — Cowork ↔ Claude Code Coexistence Wann sinnvoll: Du nutzt Cowork und Claude Code. Beide sollen dieselbe Konfiguration teilen. Was wir tun 1. Inventur: Wo liegen die .claude/-Ordner beider Welten? Konflikte identifizieren. 2. Symlink-Strategie: * Master-.claude/ im Vault-Root oder ~/.claude/ als Single Source of Truth * Symlinks aus anderen Orten * Eine Quelle, beide Welten greifen zu Wichtig: Symlinks nur auf Systemen verwenden, die sie zuverlässig unterstützen (Mac/Linux meistens ok, Windows abhängig von Rechten/Setup). Vorher Backup machen. Wenn Symlinks riskant sind: keine Symlinks, sondern klare Kopier-/Export-Anleitung. 3. Skill-Kompatibilität: * Skills die beide kennen müssen → Master * Cowork-only (z.B. Website-/Computer-Aktionen) → im Skill-Body klar als Cowork-only markieren * Code-only (z.B. Bash-Helper) → im Skill-Body klar als Claude-Code-only markieren * Frontmatter schlank halten: name + kurze description; zusätzliche Felder nur verwenden, wenn die Zielumgebung sie unterstützt. 4. Memory + Tasks teilen: MEMORY.md und TASKS.md an zentralem Ort, beide Welten lesen/schreiben. Schlag mir Inventur + Symlink-Setup vor (Vorher/Nachher), warte auf OK, dann ausführen. ________________ Modul 5 — Token-Spar-Strategien Wann sinnvoll: $20-Abo, du läufst ins Limit. Konkrete Massnahmen 1. CLAUDE.md schlank (max 200 Zeilen) * Verweise statt Inhalt: "Details in wiki/concepts/X.md" * Aktive Projekte: nur Top 3-5, Rest in _INDEX.md 2. Memory-Hygiene * MEMORY.md als reiner Index (1 Zeile pro Eintrag) * Memories in eigene Files, nie inline * Veraltete archivieren statt löschen (Scheduled Task nur vorschlagen, wenn verfügbar) 3. Phasen-Trennung fortsetzen * Grosse Aufgaben in eigene Sessions * Neue Session = frischer Counter * EIN Hauptthema pro Session 4. Skills statt Lang-Prompts * Wiederkehrende Workflows → Skills * Skill-Frontmatter triggert nur bei Bedarf 5. Daily Notes als Anker * Statt Chat-Rekonstruktion: Daily Note vom Vortag laden * /briefing nutzen Ich schreib dir eine personalisierte Token-Diät — konkrete Aktionen für DEINEN Vault. Kein generischer Tipp. ________________ Modul 6 — Skalierung für grosse Vaults (10K+ Dateien) Wann sinnvoll: Dein Vault ist gross und gewachsen. Claude kann nicht mehr alles scannen. Was wir tun 1. Hierarchischer Index Pro Top-Level-Ordner eine _INDEX.md: # Projekte/_INDEX.md - [Projekt A](Projekt-A/README.md) — Status: aktiv, [[Person]]... - [Projekt B](Projekt-B/README.md) — Status: pausiert... Claude liest Index, dann gezielt die relevante Datei. 2. CLAUDE.md verweist auf Indizes Statt Top-Listen → "siehe Projekte/_INDEX.md". 3. Tag-Strategie * YAML-Frontmatter: tags: [project, ai, klient-x] * Suchbar via Grep statt Volltext-Scan * Standardisierte Tag-Liste in _Kontext/Tags.md 4. Archiv * _Archiv/ für abgeschlossene Projekte * Nicht löschen, aber aus Standard-Scans ausschliessen * CLAUDE.md: "Archiv nur auf Anfrage scannen" 5. Scheduled Task: Index-Update Wöchentlich alle _INDEX.md aktualisieren. Schlag mir einen Startpunkt vor — Indizes anlegen, oder erst Tag-Strategie aufräumen? ________________ Modul 7 — Eigene Skills bauen Wann sinnvoll: Du hast wiederkehrende Workflows, die als Skill oder Trigger-Phrase Sinn machen. Was wir tun 1. Workflow-Audit Schau in Daily Notes und Sessions: was machst du regelmässig? * Wochenrückblick? → /weekly * Meeting-Nachbearbeitung? → /meeting-debrief * Inbox-Verarbeitung? → /inbox * Tagesplan? → /plan-day * Kundenzusammenfassung? → /client-brief 2. Skill-Template --- name: [skill-name] description: > [Kurz: Was macht der Skill und wann nutzen? Für Claude.ai möglichst unter 200 Zeichen.] --- # /[skill-name] — [Kurz-Beschreibung] [Trigger-Phrasen ausführlich hier aufführen, nicht in die Description stopfen.] [Schritte in klarer Nummerierung. Wiederholbar.] ## Idempotenz-Regel [Was bei mehrfachem Aufruf?] ## Schritte 1. ... ## Wichtig - [Anti-Patterns] 3. Installationspfad * Lokaler Skill-Ordner verfügbar: Mac häufig ~/.claude/skills/[name]/SKILL.md, Windows häufig %USERPROFILE%\\.claude\\skills\\[name]\\SKILL.md * Claude.ai Custom Skills: Skill-Ordner mit SKILL.md als ZIP/Upload vorbereiten und anschließend aktivieren * Projektspezifisch, falls unterstützt: [projekt]/.claude/skills/[name]/SKILL.md * Wenn Skills nicht unterstützt werden: Skill im Vault unter _Skills/[name]/SKILL.md speichern und manuell als Prompt-Baustein nutzen 4. Test in neuer Session — kurze Description + klare Trigger-Phrasen sind 80%. Frag mich: welchen Skill als ersten? Bau einen vollständig durch (Audit → Template → Install → Test). ________________ Modul 8 — MCP-/Connector-Integrationen Wann sinnvoll: Externe Datenquellen sollen ins Second Brain fliessen. Was wir tun 1. Integrations-Inventur — welche Integrationen sind bereits aktiv? Unterscheide: * Remote MCP / Claude Connectors (für Claude.ai/Cowork typischer Weg) * Lokale MCP-Server in Claude Desktop (nicht automatisch in Cowork verfügbar) * Browser-/Website-Zugriff * Manuelle Exporte (CSV, Markdown, PDF) 2. Lücken-Analyse nach Engpässen * "Content verschwindet" → Read-Later-Connector, Browser-Zugriff oder manueller Export * "Termine ungeplant" → Calendar-Connector/MCP oder Kalender-Export * "Mails verpasst" → Gmail-Connector/MCP oder manueller Mail-Export * "Meetings nicht dokumentiert" → Granola/Otter-Connector/MCP oder Transcript-Export 3. Workflow-Ideen pro Integration Pro Integration ein konkreter Workflow: * "Calendar: morgens Tagesübersicht in Daily Note ziehen" * "Granola/Otter: jedes Meeting → Notiz in Meetings/" * "Gmail: ungelesene Priority-Mails in Briefing" 4. Setup-Anleitung pro Integration: installieren/verbinden, Berechtigungen prüfen, testen, ins Second Brain integrieren. 5. Scheduled-Task-Kopplung — nur vorschlagen, wenn Scheduled Tasks in der Umgebung verfügbar sind; sonst manuelle Routine notieren. Frag mich: welche 1-2 Integrationen? Mehr nicht, sonst überfordert. ________________ Schritt N — Übergabe Nach jedem Bonus-Modul: ✅ Bonus-Modul "[Name]" abgeschlossen. Was ist neu: - [...] Was du jetzt tust: - [konkret] Was als nächstes Bonus-Modul Sinn macht: - [basierend auf Engpässen + aktuellem State] CLAUDE.md kurz additiv updaten. ________________ Regeln * Max 2 Module pro Session. Sonst Token-Explosion. * Kein Modul "auf Verdacht". Nur was User wählt. * Briefing-Ladung ist Pflicht. Wenn kein lokaler Dateizugriff besteht, den User bitten, Assessment/CLAUDE/README einzufügen. * Schutzprinzip gilt weiter: Vorher/Nachher + OK bei Eingriffen. * Token-Budget: pro Modul max 30% einer Session. * Nie alle Module hintereinander in einer Session — auch nicht wenn es "klein" aussieht.