Ein KI-Assistent kann schon ohne Erweiterungen erstaunlich viel. Für ein konkretes Projekt reicht „erstaunlich viel" aber selten als Arbeitsweise. Beim Aufbau des Second Brain kamen zuletzt drei sehr unterschiedliche, eigenständige Projekte zusammen: der Website-Relaunch, die Auswertung des Second Brain selbst und Architekturfragen im Homelab. Dieselbe allgemeine Unterhaltung dafür jedes Mal neu zu briefen, wäre möglich gewesen, aber ineffizient. Sinnvoller war es, gezielt nach Skills zu suchen: kleinen, wiederverwendbaren Fähigkeiten, die einen bestimmten Arbeitskontext mitbringen und sich automatisch je nach Aufgabe dazuschalten. Die schwierigste Frage dabei war nicht, ob es solche Erweiterungen gibt, sondern welche davon tatsächlich zum jeweiligen Problem passen und vertrauenswürdig genug sind.
Ein Skill ist kein Allzweck-Upgrade
Der Begriff klingt zunächst nach einem App-Store für die KI. Praktisch ist ein Skill eher eine konzentrierte Arbeitsanweisung samt Werkzeugen und Fachwissen für eine wiederkehrende Aufgabe – nicht dafür gedacht, den Assistenten grundsätzlich „besser" zu machen, sondern ein bestimmtes Problem verlässlicher abzudecken. Genau deshalb war die Zuordnung wichtiger als die Anzahl der Installationen: Ein Skill für Datenauswertung hilft nicht bei einer Architekturentscheidung, ein Paket für UI-Animation ist kein Ersatz für sauberes Systemdesign.
Drei laufende Projekte haben die eigentliche Auswahl strukturiert. Für den Website-Relaunch wurden Hilfen für Frontend-Gestaltung, Design-Kontext, UX-Referenzen und Animation gesucht. Das Second Brain brauchte Werkzeuge für Tabellen, Abfragen und Visualisierungen. Im Homelab ging es um Architektur, Fehlersuche, Dokumentation und Tests. Ergänzend, aber deutlich kleiner im Umfang, lief die laufende Blog-Redaktion mit – dafür reichte ein einzelner, unterstützender Skill gegen typische Textmuster im Deutschen, kein eigenes Paket.
Der Name allein reicht nicht
Die Recherche war der eigentliche Arbeitsaufwand. In Skill-Verzeichnissen tauchen oft ähnliche oder identische Namen auf, aber mit unterschiedlichen Autor:innen, Reifegraden und Zielen. Besonders deutlich wurde das bei einem bestimmten Stil-Korrektiv gegen zu generisch wirkende Designs: gleich vier verschiedene Repositories trugen praktisch denselben Namen. Erst der Blick in README, Verbreitung und Aktualität zeigte, welches davon das Original mit deutlichem Abstand war.
Auch exakte Bezeichnungen können täuschen. Ein gesuchter Daten-Skill hieß nicht create-wiz, sondern create-viz – ein einzelnes Zeichen Unterschied. Deutlich lehrreicher war ein zweiter Fehler: Zwei weitere Skills für Architektur und Fehlersuche schienen nach einer ersten, oberflächlichen Suche zu fehlen, waren im Quell-Repository bei genauerer Prüfung aber real vorhanden. Die Konsequenz: Bei Skill-Namen zählt nur die Prüfung direkt an der Quelle, nicht der erste schnelle Treffer.
Ein Blockversuch: echte Suche im Wiki
Ein Ziel ließ sich auf diesem Weg nicht erreichen. Parallel zur Skill-Suche wurde versucht, echte Volltextsuche über den gesamten Vault zu bekommen – nicht als neuer Skill, sondern über einen MCP-Server, der die Embeddings des bereits installierten Obsidian-Plugins Smart Connections wiederverwenden sollte. Der Versuch scheiterte an einer schlichten Versions-Inkompatibilität: Das Vault-Plugin läuft inzwischen auf Version 4.7, der verfügbare MCP-Server unterstützt bislang nur das ältere 3.x-Datenformat – Ergebnis war kein halb funktionierender Zugriff, sondern gar keine geladene Verbindung. Statt an dieser Stelle weiter zu debuggen, wurde der Ansatz bewusst zurückgestellt, die kaputte Server-Konfiguration wieder entfernt und eine unabhängige Alternative für einen späteren Anlauf vorgemerkt. Das daraus ein ganz eigenes Projekt werden würde (echtes Retrieval für den Second-Brain-Redakteur), ahnte ich zu diesem Zeitpunkt noch nicht.
Ergebnis: sieben Pakete für drei Projekte plus eine Randaufgabe
Am Ende standen sieben Plugins über die offizielle Claude-Code-Plugin-Verwaltung sowie ein eigenständiges Zehner-Skill-Paket, das über einen unabhängigen Installationsweg eingebunden wurde, weil es kein eigenes Marktplatz-Format mitbringt. Zugeordnet wurden sie so:
- Website-Relaunch: mehrere komplementäre Design-Skills – ein offizielles Frontend-Grundgerüst, ein Design-Kontext-Zwang vor dem eigentlichen Bauen, eine große UX-Referenzbibliothek, das erwähnte Stil-Korrektiv sowie das zehnteilige Paket für Mikrointeraktionen und Animation.
- Second-Brain-Auswertung: ein Analyse-Paket für strukturierte, tabellarische Daten – Dashboards, Statistik, Abfragen. Bewusst keine direkte Vault-Volltextsuche, dafür bleibt die oben beschriebene Lücke bestehen.
- Homelab-Architektur: ein Engineering-Paket mit Architekturentscheidungen, Code-Review, Fehlersuche und Deployment-Checklisten.
- Blog-Redaktion (unterstützend): ein einzelner Skill als Nachbearbeitungsschritt für Blog- und LinkedIn-Entwürfe, kein eigenständiges Projektpaket.
Alle Skills triggern seither automatisch je nach Aufgabenkontext, ohne einzeln aufgerufen werden zu müssen – geschrieben wird weiterhin ganz normal, das passende Fachwissen wird im Hintergrund dazugeschaltet.
Fazit und Ausblick
Der wichtigste Gewinn ist nicht die Zahl installierter Erweiterungen, sondern die Zuordnung: Drei laufende Projekte reagieren jetzt mit passenderem Kontext, ohne dass jede Aufgabe bei null anfängt, während die Blog-Redaktion bewusst nur eine kleine, unterstützende Ergänzung bekommen hat statt eines eigenen Pakets. Offen bleibt eine einzelne, aber spürbare Lücke: eine echte semantische Suche über den gesamten Second-Brain-Bestand, die am Versionskonflikt mit dem bestehenden Vault-Plugin gescheitert ist. Sie ist dokumentiert und wartet auf einen zweiten Anlauf. Fähigkeiten gezielt ergänzen, ihre Herkunft prüfen und eine Lücke lieber offen lassen als sie hinter einer scheinbaren Lösung zu verstecken – das bleibt für ein wachsendes Second Brain die brauchbarere Haltung. Der nächste Teil der Serie bleibt auf dieser Second-Brain-Ebene, wendet sich aber wieder einem konkreten Ergebnis statt einer offenen Baustelle zu.