In meinem Beitrag „Ein Ordner voller Textdateien, der meinen Arbeitsalltag trägt“ habe ich beschrieben, wie Obsidian zum Mittelpunkt meiner Arbeit geworden ist: Projektdokumentation, Website-Inhalte und KI-Agenten, die direkt auf denselben Markdown-Dateien arbeiten.
Je mehr ich dort erledige, desto deutlicher fallen mir die Stellen auf, an denen ich trotzdem noch aus Obsidian heraus muss oder mühsam von Hand arbeite. Genau dort sind meine eigenen Plugins entstanden.
Ich wollte kein Plugin-Portfolio aufbauen. Ich wollte meinen Arbeitsalltag leichter machen.
Dass mich am Ende weniger die Funktionen beschäftigen würden als die Frage, wann man einer Erweiterung eigentlich vertrauen kann, hatte ich dabei nicht erwartet.
Drei Ärgernisse, drei Werkzeuge
Wenn ich (oder ein KI-Agent) einen Text überarbeite, will ich sehen, was sich ändert, bevor ich es übernehme. Nicht blind übernehmen, nicht mühsam im Terminal diffen. Side-by-Side Diff stellt deshalb zwei Textdateien nebeneinander dar und lässt mich jede Änderung einzeln annehmen oder verwerfen. Ein Vorschlag bleibt ein Vorschlag, bis ich ihn bewusst übernehme.
Nach einer Woche hatte das Plugin über 100 Downloads, inzwischen sind es über 3.000 (Stand November 2026). Offenbar bin ich nicht der Einzige, der Änderungsvorschläge lieber prüft, statt sie einfach zu übernehmen.
Dasselbe Prinzip gilt in meinen Kundenprojekten. Wenn dort KI-Agenten Code oder Konzepte überarbeiten, landet nichts ungeprüft im Projekt. Gerade bei Anwendungen, die über Jahre gewachsen sind, zählt nicht, wie schnell eine Änderung entsteht, sondern ob man ihre Auswirkungen versteht, bevor man sie übernimmt.
Als das erste Plugin lief, fielen mir weitere Stellen auf, an denen ich Obsidian unnötig verlassen musste. Dev Runner startet Entwicklungsbefehle direkt in Obsidian, statt dafür ins Terminal zu wechseln. Textile Export kopiert eine Notiz als Textile-Markup, damit ich Tickets in Obsidian schreiben und direkt in ein externes Ticketsystem (z. B. Redmine) einfügen kann. Beide sind deutlich spezieller und entsprechend kleiner – sie lösen eben vor allem mein Problem.
Mit der Veröffentlichung kam allerdings eine Frage dazu, die ich bisher nur oberflächlich gestellt hatte: wie viel Vertrauen ein Plugin eigentlich verdient, wenn es mit weitreichenden Rechten im eigenen Vault läuft.
Wann kann ich einer Erweiterung vertrauen – einer fremden genauso wie meiner eigenen?
Automatisierten Reviews vertrauen?
Den neuen Plugin-Review-Prozess von Obsidian hatte ich im vorherigen Beitrag schon kurz beschrieben: Jede Version wird automatisiert geprüft, ein Mensch schaut nur noch gezielt drauf. Als Benutzer und Entwickler sieht man das Ergebnis als eine Scorecard im Online-Listing.
Für Dev Runner meldet die Prüfung zwei Warnungen: Das Plugin kann Shell-Befehle mit den Rechten von Obsidian ausführen und auf Dateien außerhalb des Vaults zugreifen. Beides stimmt – genau dafür ist es da. Eine Warnung beschreibt erst einmal Möglichkeiten, keinen Missbrauch. Entscheidend ist, ob die Rechte zur Aufgabe passen und sichtbar begrenzt werden. Für Dev Runner zeige ich deshalb vor jedem neuen Befehl an, was genau ausgeführt wird.
Umgekehrt ist ein gutes Ergebnis kein Gütesiegel. Ich habe selbst schon ein Plugin wegen der besseren Scorecard gegen ein anderes getauscht – und erst danach gesehen, dass hinter dem neuen ein erst wenige Monate alter Account steht. Am Ende bleibt es eine Abwägung, welche Plugins man installiert und ob man ihnen vertraut.
Ein bestandener Scan ersetzt keine gewachsene Reputation.
Was die Scorecard ebenfalls nicht zeigt: wie sorgfältig ein Plugin getestet wird. Bei meinem Dev-Runner-Plugin schlug einmal ein Test fehl, und die Version wurde – aufgrund eines Fehlers in meinen Abläufen – trotzdem veröffentlicht. Seitdem bricht die Veröffentlichung automatisch ab, sobald ein Test fehlschlägt.
Auch die Häufigkeit der Aktualisierungen bzw. ob es noch aktiv betreut wird, ist hier nicht ersichtlich. So habe ich für ein anderes Plugin eine Änderung bereitgestellt, die – wie auch andere Anfragen – seit Wochen nicht berücksichtigt wird.
Was bleibt: Verantwortung
Genau diesen Punkt sollte man vor einer Veröffentlichung auch bedenken:
Ein öffentliches Plugin bedeutet Verantwortung und Arbeit.
Das merke ich mit den steigenden Nutzungszahlen deutlich: Es kommen Feature-Anfragen und Pull Requests – vor kurzem zum Beispiel die Frage, ob man Markdown-Dateien von außerhalb des Vaults per Drag & Drop vergleichen kann. Natürlich freue ich mich, wenn meine Arbeit genutzt wird. Der Aufwand dahinter ist aber nicht zu vernachlässigen.
Schade ist nur, dass alle Rückmeldungen einen Umweg brauchen: Im Obsidian-Plugin-Browser gibt es weder Bewertungen noch Kommentare, und auch die Scorecard ist dort nicht zu sehen. Wer Feedback geben oder vor der Installation genauer hinschauen will, muss aktiv auf GitHub oder ins Online-Listing wechseln.
Angefangen hat alles mit dem Wunsch, ein paar Handgriffe im Alltag zu sparen. Das ist gelungen: Ich nutze alle drei Plugins täglich. Mitgenommen habe ich aber vor allem einen genaueren Blick darauf, was Vertrauen bei Community-Plugins bedeutet – gerade jetzt, wo mit KI-Unterstützung in kurzer Zeit neue Plugins entstehen, die oft niemand mehr Zeile für Zeile gelesen hat. Es ist mehr als „kein schädlicher Code“. Ich will nachvollziehen können, was ein Plugin tut, dass es gepflegt wird und dass erkannte Fehler Konsequenzen haben. Das gilt für die Plugins, die ich installiere – und erst recht für die, die ich selbst veröffentliche.
Quellen:
- Meine persönlichen Erfahrungen beim Entwickeln und Veröffentlichen der drei Plugins
- Ein Ordner voller Textdateien, der meinen Arbeitsalltag trägt
- Meine Plugins auf der Obsidian-Community-Seite
- Side-by-Side Diff auf GitHub
- Dev Runner auf GitHub
- The Future of Plugins – Obsidian-Blog, Mai 2026
