Aki's Vibes

[akira]

Huhu zusammen,

Nein, hier geht es nicht um Musik, da wär ich wohl im falschen Forum ...

tl;dr Hier geht es um eine Beschreibung von Vibe Coding wie ich es sehe und was ich vor kurzem umgestellt habe, um den Region-Server zu optimieren. Observability, OpenTelemetry, Grafana Cloud sind Themen.


Vielleicht zuerst eine kleine Definition:

Vibe Coding ist ein relativ neuer Begriff in der Programmier-Community, der einen Programmierstil beschreibt, bei dem man sich mehr auf das "Gefühl" und den Flow verlässt als auf strenge Planung oder Best Practices.

Die Kernidee hinter Vibe Coding:

• Man schreibt Code intuitiv, ohne grosse Vorplanung oder Architektur-Überlegungen
• der Fokus liegt auf schnellem Experimentieren und "einfach mal machen"
• weniger Sorgen um perfekte Struktur, Dokumentation oder Tests
• Man lässt sich von der Stimmung und Kreativität des Moments leiten

Dann gibt es noch den Begriff Agentic Development auch hier:

Die Kernidee hinter Agentic Development:

• Fokus: KI-Agenten übernehmen ganze Entwicklungsaufgaben autonom
• Ansatz: "Ich delegiere komplexe Tasks an einen KI-Agenten"
• Kontrolle: Der Agent arbeitet selbstständiger - plant, implementiert, testet teilweise eigenständig
• Typisch: KI schreibt ganze Features, refactored Code, debuggt, nutzt Tools eigenständig
• Werkzeug: Spezialisierte KI-Agenten (wie Claude Code, Devin, Cursor mit Agent Mode)

Hauptunterschied:

Vibe Coding ist eine Arbeitsweise - ein lockerer, Flow-orientierter Stil, den man mit oder ohne KI praktizieren kann.

Agentic Development ist ein Delegationsmodell - man übergibt grössere Verantwortung an autonome KI-Systeme, die komplexere Aufgaben eigenständig lösen.

überschneidung

In der Praxis kombinieren viele Entwickler beides: Sie nutzen agentic tools (wie Claude Code), um sich auf den Vibe zu konzentrieren - also schnell Ideen umzusetzen, ohne sich in Details zu verlieren. Die KI übernimmt die "Denkarbeit" für Implementierungsdetails, während der Mensch im kreativen Flow bleibt.

Mein Vibe im OpenSim

Ich kenne die Architektur des Projekts mehr oder weniger. Ich weiss, was ich erzielen will (kleine Schritte). Dazu nutze ich eine Umgebung, welche mir viel Arbeit abnimmt.

Die beste Erfahrung habe ich mit Claude Code gemacht. Er will eine Änderung machen, zeigt mir dies an und ich entscheide, ob er loslegen soll. Nachteil von Claude Code. Kostet Geld. Aber ich kann den Pro-Plan von Claude nutzen. Kostet pro jahr etwa 160 Euro. Natürlich hab ich da nicht Tokens ohne Ende. Es ist mir schon oft passiert, dass ich eine Meldung kriege: Deine Token sind aufgebraucht, der Reset findet um 20:00 Uhr statt. Also Zwangspause bis 20:00 Uhr. Es existieren noch andere Modi die sind jedoch viiiiel teurer. Und Claude Code funktioniert nur mit Claude zusammen.

In letzter Zeit wird gerade OpenCode gehyped. Hat durchaus auch Vorteile. Es ist möglich beliebige Modelle zu nutzen auch kostenlose. OpenCode ist jedoch näher bei Agentic Development und ich werde da nicht warm damit, den Agent grössere Arbeiten machen zu lassen. Und um die Claude Modelle zu nutzen, brauch ich API Token. Mit OpenCode die Claude Pro Schnittstelle zu nutzen lief bis vor Kurzem, aber Anthropic hat dies nun unterbunden. Und API Token sind sehr teuer.

Vibe von Mistral existiert auch noch. Hat ebenfalls die Möglichkeit gratis Modelle zu nutzen. Ist vom Stil her näher an Claude Code. Und Mistral bietet einen gratis Zugang zu den eigenen Modellen. Begeisterung hält sich aber noch in Grenzen.

Let's do something

Eine Frage welche mich interessiert. Wann läuft ein OpenSim Region Server gut. Und wann nicht und wie sehe ich das. Observability ist das Zauberwort. Hier eine kleine Erklärung:

Observability ist die Fähigkeit, den internen Zustand eines Systems anhand seiner externen Ausgaben zu verstehen und zu analysieren. Der Begriff stammt ursprünglich aus der Kontrolltheorie, hat sich aber vor allem in der Software-Entwicklung und IT-Operations etabliert.

Die drei Säulen der Observability:

Logs – Detaillierte Ereignisaufzeichnungen, die beschreiben, was zu einem bestimmten Zeitpunkt passiert ist
Metrics – Numerische Messwerte über Zeit (z.B. CPU-Auslastung, Response Times, Fehlerraten)
Traces – Verfolgung von Requests durch verteilte Systeme hinweg

Logs habe ich. Kein Thema. Metrics fehlen mir. Klar kann ich mit einem Profiler rein, ist aber für den Betrieb zu heftig. Aber auch dazu gibt es eine Lösung:

OpenTelemetry (oft abgekürzt als OTel) ist ein Open-Source-Framework für Observability, das zum Standard für das Sammeln von Telemetriedaten aus Anwendungen geworden ist.

Was macht OpenTelemetry?

Es bietet eine einheitliche, herstellerneutrale Methode zum Instrumentieren, Generieren, Sammeln und Exportieren von Telemetriedaten (Traces, Metrics, Logs). Statt für jedes Observability-Tool eine eigene Integration zu bauen, verwendest du OpenTelemetry einmal und kannst dann flexibel zwischen verschiedenen Backend-Anbietern wechseln.

Backend-Anbieter also Systeme, welche die OpenTelemetry Daten sammeln und grafisch auswerten, gibt es einige. Kann man sich selber installieren. Jaeger und Zipkin kommen mir da in den Sinn. Die beiden sind spezialisiert auf Traces. Will ich aber im Moment noch nicht. Vorerst brauch ich Logs und Metrics.

Grafana resp. Grafana Cloud war dann die Lösung. Bei Grafana Labs kriegt man eine Grafana Cloud Instanz für Lau mit grosszügig bemessenem Storage. Schnell subscribed und nach 10 Minuten war dies eingerichtet.

Ok was brauche ich nun für OpenTelemetry in meinem Region-Server? Hab ich dann Claude Code gesagt, er solle mir doch bitte OpenTelemetry für Logs und Traces einbauen. Unter anderem kamen da diese Libraries neu in den Region-Server mit rein:

Code: Alles auswählen

dotnet add package OpenTelemetry
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol
dotnet add package OpenTelemetry.Instrumentation.Http

Im Monitoring und Logging Teil des Region-Servers mussten noch einige Anpassungen gemacht werden. Das war ein ziemliches Try-and-Error Spiel. Hatte dann zur Folge, dass noch wesentlich mehr Libraries notwendig wurden.

Einen Region-Server zu bauen ist per Standard runprebuild.sh und compile.sh. Die Abhängigkeiten der Packages werden im prebuild.xml beschrieben usw. Leider funktioniert nur OpenSim mit diesem Prebuild Gedöns. Der Rest der Welt nutzt den NuGet Package Manager. Dieser Prebuild Mechanismus war mir schon lange ein Dorn im Auge. Die Wahrheit liegt in den csproj files und nicht in einem Prebuild XML. Entwicklungsumgebungen sind auf NuGet optimiert und dort ist die Wahrheit halt in den *.csproj files ( wie in Java in den *.pom files ).

Zusammen mit Claude Code war der Build Prozess recht rasch umgebaut. Die Schwierigkeit: Die Package-Verwaltung in OpenSim ist gelinde gesagt ein Desaster oder schlichtweg nicht existent. Da liegen *.dll herum in einer Version, welche gefühlt Jahrzehnte alt sind. Zu einigen DLL gibt es kein NuGet Package und woher sie kommen ist auch unklar. Deshalb haben liegen im Git des OpenSim auch noch dll rum, was eigentlich nicht die feine Art ist.

Egal damit lebe ich erst mal und nach einigen Iterationen war auch dieses Problem gelöst. Und dann Tadaaa:



Vielleicht fällt auf: otel_heartbeat_seconds ist bei 56 Jahren und tendenz steigend. Da hat Claude Code noch was falsch gemacht. Er sendet nur die Timestamps ab Epoch (1.1.1970) und nicht die Differenz von zwei Timestamps. Muss ich ihm noch austreiben.



Find ich voll Cool. Logs und Metrics an einem Ort, zentral.

Fazit:

• Build System modernisiert (NuGet)
• OpenTelemetry Logs und Metrics eingebaut
• Zeilen codiert: 0

Nächstes mal mehr zu weiteren Vibes
Liebe Grüsse
Akira

[akira]

Huhu zusammen,

tl;dr Beobachtungen bei unserer Party zum 11 Jährigen Bestehen des Grid und Ersatz einer Grafikbibliothek.

Diese Woche, welche in unserer Geburtstagsparty endete, hab ich einiges hingekriegt. Aber lasst mich mit der Geburtstagsparty beginnen. Ich habe ja Ko Suai und Dereos Plaza mit OpenTelemetry ausgerüstet. Ein Event wie eine Party ist spannend zu beobachten und anschliessend zu analysieren. Hier mal ein Screnshot der gesamten Party:



Ich werde jetzt nicht jedes Feld einzeln erklären. Wen's interessiert, darf gerne fragen. Ansonsten die KI eurer Wahl kann dies auch selbst gut erklären. Das Bild sieht etwa so aus wie ich es erwartet habe. Ab 19:30 Uhr, da sind Ly, Samira und ich auf der Sim aufgeknallt. Nun Beginnen die Kurven stark zu oszillieren. Das dauerte an bis etwas nach 22 Uhr als andauernd neue Gäste eintrafen. Danach lief die Party und irgendwann wurde es spät für einige und am Schluss waren wir noch zu fünft auf der Sim und haben dann gegen 01:00 Uhr Schluss gemacht.



Ein paar mal EINE Aufgabe, welche in dem Thread Pool zur Abarbeitung in der "Warteschlange" standen. Schon mal sehr gut! Das heisst, die Aufgaben wurden alle zügig erledigt. Dass einiges zu tun war, zeigt diese Grafik:



Viel zu tun und rasch erledigt. So soll es sein! Natürlich gab es auch viele Warnungen und Fehler:



Aber nichts Aussergewöhnliches. Sieht man auf jeder Party:



Was mir mehr zu denken gibt, sind diese Warnungen:



Diese CSJ2K Library, mit der hab ich viel Zeit verdödelt. Bin ja dabei, alten Ramsch aus dem Sim zu entfernen. Eine der Libraries, die mich stört, ist die System.Drawing.Common Library. Diese wurde für Linux bis zur Version .NET 6 noch unterstützt. Ab Version .Net 7 gab's dann Fehlermeldungen, dass sie nicht mehr unterstützt ist. Natürlich kann ich die noch lange verwenden, auch in .NET 8+ muss einfach sicher sein, dass ich die alte Version immer im Paket behalte und wenn ihr in euer bin-verzeichnis des OpenSims schaut, dann seht ihr, dass es da zwei Dateien gibt. System.Drawing.Common.dll.linux und System.Drawing.Common.dll.win und je nach System muss dann die richtige eingebunden werden. Also ein Abstellgeleise. Will ich nicht.

Microsoft gibt dazu einige Empfehlungen ab. ImageSharp und SkiaSharp Ich habe mich schlussendlich für SkiaSharp entschieden, ist zwar komplexer im Library Handling aber schlussendlich voll offen unter einer MIT-Lizenz, wogegen die ImageSharp Library von SixLabors lizenziert wird. Ich hatte null Probleme eine freie Lizenz von ihnen zu kriegen, weil die kostenpflichtigen Features von mir nicht genutzt werden. Also als Plan B noch offen halten.

Die umstellung verlief dann relativ harzig. Insbesondere beim Generieren der Maptiles haben wir uns einen Wolf ab-debugged. Bis wir dann die CSJ2K als Bösewicht eingekreist haben. Nachdem ich die aus der Konfiguration entfernt hatte wurden auch die Maptiles korrekt generiert. Die Frage ist nun offen. Was mach ich mit der CSJ2K. In einem Repository von OpenSim gibt es Sourcecode dazu. Auf Github gibt es dieses Repo: https://github.com/cureos/csj2k und diese lib findet man auch im NuGet Repository. Ich gehe aber davon aus, dass Ubit etwas selbst gebrautes verwendet, die arbeiten ja nicht mit NuGet. Ist aber auch fraglich ob ich die verwenden soll. Wir haben ja noch die OpenJpeg Library zusätzlich im Repo. Muss mir da noch einen Task machen.

Wenn alles mit der CSJ2K Library funktioniert, warum nicht wechseln ... wenn ich aber schaue der letzte Commit am 26. September 2018 die ist ja fast so alt wie unser Grid, dann ... na ja, weiterforschen. Ziel für letzte Woche ist erreicht, SkiaSharp eingebaut und angetestet. Nein, nein, auf der PartySim ist die noch nicht eingebaut, erst bei mir lokal im Test.

Nächste Woche: Rausschmiss des SmartThreadPool... der ist in der heutigen Zeit völlig überflüssig. DotNet hat eigene Thread Pools und die Leute vom OpenSim-Tranquility Projekt haben den auch schon entfernt.

[akira]

Huhu zusammen,

tl;dr In diesem Vibe geht es ums Aufräumen. Gedanken zu Plugins, Dependency Injection und Factories.

Diese Woche hab ich nicht viel am Simulator rumgevibed. War anderweitig engagiert. Deshalb erzähle ich nun etwas zu der Idee, warum ich am Sim oder genauer gesagt dem Region-Server rumwerkle. Was mich eigentlich schon längere Zeit stört, der Region-Server ist überladen! Eigentlich beginnt das schon beim Namen. Neben dem Region-Server, gibt es ja noch den Grid-Server, der "Robust" genannt wird. Ausser der Region Server wird im Standalone Modus betrieben, dann ist die Funktionalität im Region Server eingebaut, besser gesagt zusammengesteckt.

Dieses zusammenstecken ist im Prinzip eine spannende Sache, so können die Module im Region-Server für Standalone und im Robust Server wiederverwendet werden. Auch wird die Möglichkeit geboten, Plugins für den Simulator zu entwickeln. So weit, so gut. Ein Plugin System wird dann richtig lustig, wenn es dann irgendeinen Marketplace gäbe, in welchem Plugins geholt werden können, mit denen der Simulator mit Funktionalität erweitert werden könnte. Leider hat sich diesbezüglich ausser einigen Money Plugins nicht sehr viel entwickelt. Schön wäre es, wenn die Trennung zwischen dem Grundgerüst und den Plungins sauberer getrennt wären, sodass ich, falls ich gerne die Ubode Physik hätte, beispielsweise ein bereits geliefertes Physik Plugin austauschen könnte. Aktuell sind all diese Module oder Plugins mehr oder weniger wild im Code verteilt. Es existiert ein Folder addon-modules. Aber im OpenSim Code Folder existieren ebenfalls zwei Projekte OpenSim.Addon.Groups und OpenSim.Addon.OfflineIM. Und das ganze noch in mehreren Ausprägungen.

Für meinen Geschmack zu viel Durcheinander. Und wir Schweizer mögen Durcheinander nicht. Wir lieben es aufgeräumt. Wir räumen gerne alles auf:

https://www.youtube.com/watch?v=nhPcsvlNcVc

Also hab ich mir ein paar Gedanken gemacht, was ich eigentlich gerne möchte.

• Brauche ich Robust? Nö ich habe den Php-Gridserver
• Brauche ich die Standalone Möglichkeit? Nö ich betreibe Sims nur im Hypergrid Modus.
• Brauche ich 10 Physik-Engines? Nö, Ubode und Bullet reichen eigentlich. Bullet brauch ich nur wegen der 3D Meshes die ich importiert hab, weil bei Ubode müsste ich nochmals importierten.
• Scripting Engines. Hat sich inzwischen auf eine reduziert. Glücklicherweise.
• Weitere Modules die ohne Sinn und Zweck rumliegen entfernen.
• Mono.Addins als Plugin System loswerden wird nicht mehr weiterentwickelt. Brauch ich wirklich Plugins?

Auch wenn die Konzeption der Mono.Addins ziemlich cool ist, die Tatsache, dass es nicht mehr weiterentwickelt wird und auch das Plugin Konzept nicht so prickelnd umgesetzt ist, sagte ich mir: Raus damit!

Um mit Modulen umzugehen, existieren mehrere Muster:

• Plugins
• Dependency Injection
• Factories

Die drei Muster im Vergleich

Plugin-System (Mono.Addins, System.Composition)

• Findet automatisch Implementierungen in Assemblies
• "Zeig mir alle Klassen, die ICommand implementieren"
• Für unbekannte, dynamische Erweiterungen

Dependency Injection (DI Container)

• Verwaltet Objektlebensdauer und injiziert Abhängigkeiten
• "Gib mir die registrierte Implementierung von ILogger"
• Für lose Kopplung innerhalb bekannter Komponenten

Factory

• Kapselt Objekterstellung mit Logik
• "Erstell mir ein Objekt basierend auf diesen Runtime-Parametern"
• Für komplexe oder parameterabhängige Instanziierung

Aktuell hab ich mich für eine Factory-Lösung entschieden. Aber könnte mir vorstellen, dass wenn ich das Testing überarbeite, ich vermehrt auf Dependency Injection umsteigen werde. Schon seit einiger Zeit erledigt:

• Mono.Addins rausfakturiert und durch Factories ersetzt
• Module die nur für den Standalone Betrieb notwendig sind entfernt
• Uralte Module die nicht mehr notwendig sind entfernt

Hab den Sim schon mal angetestet, aber es traten noch einige Seiteneffekte auf also wieder zurück ins Labor. Und genau deshalb überleg ich mir auch den Smart Thread Pool zu entfernen, um noch mehr Standardkomponenten zu verwenden, mit dem finalen Ziel keine .dll mehr im Github Repository und alles mit NuGet managen. Bin mal gespannt, wozu ich nächste Woche komme.

Ob das ganze jemals die Qualität hat um im Grid eingesetzt zu werden, weiss ich noch nicht. Die Vibes sind Sachen an welchen ich im Moment herumexperimentiere, immer mit einem konkreten Ziel welches ich habe.

[akira]

Huhu zusammen,

So, ich habe die Changes vom OpenSim in meinen Sim gemerged. War einiges an Arbeit, aber schlussendlich habe ich es auch geschafft. Was spannend ist, im OpenSim haben sie WebRtc beigefügt. Das WebRtc ist der Ersatz für Vivox oder Freeswitch Voice. Spannende Geschichte.

Das WebRtc besteht aus drei Teilen, ein Modul für den Region-Server, eines für den Robust-Server und ein Drittes (Siehe Hierarchie-Abbildung unten). So weit, so gut. Was macht man nun, wenn man keinen Robust hat? Umschreiben nach PHP (unser Grid läuft ja auf dem PHP Grid Server)?

Nein PHP tue ich mir nicht an! Aber das WebRtc ist ja mehr oder weniger autonom, hat mit dem andern Gedöns des Grid eigentlich nichts zu tun. Das Teil auf dem Robust ist eigentlich nur eine Schnittstelle zum janus-gateway. Okay da braucht es noch einiges mehr. Die Kommunikation sieht wie folgt aus:

Code: Alles auswählen

Viewer (WebRTC)
     │  HTTP Caps (LLSD/XML)
     ▼
WebRtcVoiceRegionModule          ← Region-Server
  (ISharedRegionModule)
  Caps: ProvisionVoiceAccountRequest
        VoiceSignalingRequest
        ChatSessionRequest
     │  JSON-RPC über HTTP
     ▼
WebRtcVoiceServerConnector       ← Robust-Server
  (IServiceConnector)
  Endpunkte: provision_voice_account_request
             voice_signaling_request
     │  ServerUtils.LoadPlugin
     ▼
WebRtcVoiceServiceModule         ← Robust-Server (Service-Modul)
  (ISharedRegionModule + IWebRtcVoiceService)
  Verteilt auf spatial / non-spatial Voice-Service
     │  ServerUtils.LoadPlugin
     ▼
WebRtcJanusService               ← Janus-Implementierung
  (IWebRtcVoiceService)
  Kommuniziert mit Janus WebRTC Gateway
     │  WebSocket / HTTP
     ▼
Janus WebRTC Gateway

Okay, mal wieder die tyische OpenSim Struktur. Ein Region Modul, welches mit dem Grid Server kommuniziert. Ein Connector Modul, welches die die RPC Anfragen vom Region Server entgegen nimmt, dann ein Service Modul das sonstige Logik enthält und als drittes der WebRtcJanusService welcher mit dem Janus-WebRtc-Gateway quasselt. Der WebRtc-Gateway ist eine externe Software die auch noch bereitgestellt werden muss, gibt es aber glücklicherweise als Docker Container in den verschiedensten Ausprägungen. Also muss ich nur noch etwas mit dem Robust Gedöns anstellen.

Also eine Architektur Entscheidung treffen. Ich hab ja noch einiges vor mit dem Grid-Server. Und das was ich vor habe ist am besten unterstützt in der Sprache "Go". Diese Sprache wurde von Google entwickelt https://de.wikipedia.org/wiki/Go_(Programmiersprache). Die Sprache wurde zwar von Google entwickelt, ist aber OpenSource, den Source Code findet man hier: https://github.com/golang/go. Go ist eigentlich die Sprache für die Cloud. Viele Cloud Services sind in Go geschrieben. Also perfekt für einen Grid Server.

Ich habe dann Claude mal gebeten mir den csharp code nach Go zu übersetzen, was er auch ohne Meckern gemacht hat. Und siehe, das ganze kann man sogar schon fehlerfrei compilieren. Ob es etwas Sinnvolles tut hab ich noch nicht getestet. Aber der Ansatz ist schon mal spannend. Und schon hatte ich ein neues Repository.

Hmm... ein weiteres Repository auf einem amerikanischen Server. Irgendwie möchte ich das nicht mehr. Habe mich auf die Suche gemacht und "Codeberg" gefunden. Das schöne ist, Codeberg ist in Deutschland und es ist ein Community-Projekt mit offener Software entwickelt und bietet all das, was ich brauche. Was fehlt sind die Vulnerability Scanner und ein Renovate-System, welches automatisch Pull Requests generiert, wenn eine abhängige NuGet die Version wechselt. Aber das ist Deluxe und im Enterprise Umfeld durchaus sinnvoll und ich gehe davon aus, dass ich so was auch mit irgendwelchen externen Services erreiche. Also rasch die Url bei den Repos geändert und voilà Aki ist auf Codeberg: https://codeberg.org/AkiraSonoda

Nächste Schritte: Dieses WebRtc zum Laufen zu kriegen.

Liebe Grüsse
Akira

[akira]

Mein Vault hat ein Gehirn bekommen – KI-Skills in Obsidian und was sie für die Softwareentwicklung bedeuten
Ein Erfahrungsbericht aus drei Tagen experimentieren, schrauben und staunen.

Was ist Obsidian überhaupt?

Bevor ich anfange: Falls du Obsidian noch nicht kennst, hier die Kurzfassung.

Obsidian ist eine Note-Taking-App, die auf einem simplen Prinzip basiert: Deine Notizen sind ganz normale Markdown-Dateien auf deiner Festplatte. Keine Cloud, kein proprietäres Format, keine Vendor-Lock-in. Du besitzt deine Daten wirklich.

Das Besondere ist die Art, wie Obsidian Notizen miteinander verknüpft. Mit sogenannten Wikilinks ([[Notizname]]) verlinkst du Gedanken miteinander – ähnlich wie Wikipedia, nur für deinen eigenen Kopf. Das Ergebnis ist ein sogenanntes zweites Gehirn: Eine persönliche Wissensdatenbank, die mit dir wächst und sich an deine Art zu denken anpasst.

Ich nutze Obsidian als zentrale Schaltstelle für alles: Projekte, Ressourcen, Daily Notes, Reisenotizen, Musikrecherche für meine Radio-Sendung, Fotografie-Know-how, Literatur über KI-Entwicklung und natürlich technische Dokumentation für meine Open-Source-Projekte. Ein Vault, der echte Breite hat.

Das Problem mit grossen Vaults: Sie können schnell unübersichtlich werden. Karten ohne Verbindungen, veraltete Strukturen, verwaiste Verzeichnisse, halbfertige Gedanken. Das ist der Punkt wo KI ins Spiel kommt.


Claude Code als Vault-Assistent

Claude Code ist ein KI-Coding-Assistent von Anthropic, der direkt im Terminal läuft. Anders als ein reiner Chat-Bot hat er Zugriff auf Dateien, kann Verzeichnisse lesen, Dateien erstellen, bearbeiten und umbenennen – und das alles im Dialog mit dir. Denk an einen Assistenten, der nicht nur antwortet, sondern wirklich zupackt.

Was Claude Code besonders macht: Er kann mit deinem Obsidian-Vault als Arbeitsverzeichnis laufen. Das bedeutet, er liest und schreibt direkt deine Markdown-Notizen. Keine Umwege, kein Copy-Paste zwischen Tools.

In den letzten drei Tagen habe ich genau das getan – Claude Code in meinen Vault gesetzt und ihn systematisch verbessert. Aber der eigentlich interessante Teil ist ein Ökosystem, das ich dabei entdeckt habe: npx skills.


Das Skills-Ökosystem: Modulare KI-Superkräfte

Code: Alles auswählen

npx skills

ist ein Paketmanager für KI-Agenten. Die Idee ist bestechend einfach: Ein Skill ist eine Markdown-Datei (SKILL.md) mit Anweisungen darin. Claude Code liest diese Datei beim Start und weiss dann plötzlich, wie er eine bestimmte Aufgabe erledigen soll – Schritt für Schritt, nach einem definierten Workflow.

Skills installierst du mit einem einzigen Befehl:

Code: Alles auswählen

npx skills add vercel-labs/agent-skills@grill-me -g -y

Sie landen in

Code: Alles auswählen

~/.agents/skills/

/grill-me 
/write-a-prd
/prd-to-issues
/tdd 

per Slash (/) command direkt im Terminal aufrufbar, kein Plugin, keine Konfiguration.

Das Verzeichnis ~/.agents habe ich als Symlink auf meinen Vault gelegt. Dadurch sind alle Skills direkt im Vault bearbeitbar, per pCloud auf alle Geräte synchronisiert, und ich kann sie anpassen – genau wie jede andere Notiz. Das Gleiche gilt für ~/.claude, das ebenfalls auf den Vault zeigt. Settings, Hooks, eigene Skills: alles versionierbar, alles überall verfügbar.

Was sich im Vault verändert hat

Ich hatte klassische Altlasten: MOC-Dateien (Maps of Content) die halb gefüllt waren, Karten ohne Verknüpfungen, Verzeichnisse ohne Home-Card, doppelte Einträge für denselben Inhalt. Mit Claude Code als Partner haben wir in systematischer Arbeit:

• Alle Bereiche bekommen saubere Home-Karten mit vollständigen Verlinkungen
• Analoge Fotografie als neues Unterverzeichnis aufgebaut
• Software-Verzeichnis für Fotografie-Tools angelegt (Digikam, Luminar Neo, Affinity Photo, ON1, Nikon Capture)
• Kunst als neuen Bereich erstellt – 39 Künstlerinnen und Künstler aus Museumsbesuchen in Málaga dokumentiert
• Blender von einer MOC-Datei in eine echte Home-Card umgewandelt
• Alle Ressourcen-Verzeichnisse vollständig mit allen enthaltenen Karten verlinkt

Das Endergebnis: Von der globalen Home.md aus ist jetzt wirklich alles erreichbar. Keine Sackgassen mehr.

Obsidian-spezifische Skills:

• obsidian-markdown – kennt Obsidian Flavored Markdown: Callouts, Wikilinks, Frontmatter, Embeds. Claude erstellt damit valide Dateien die Obsidian korrekt rendert.
• obsidian-cli – erlaubt es, den Vault via CLI zu steuern: Notizen öffnen, suchen, Tags setzen.
• obsidian-bases – für die neue Bases-Funktion in Obsidian (Datenbankansichten).
• json-canvas – für Canvas-Dateien, Obsidians visuelles Board-Format.
• defuddle – extrahiert sauberes Markdown aus Webseiten. Statt einer Website manuell abzutippen, sagst du Claude «lies diese URL» und bekommst direkt aufbereitetes Markdown zurück.

Der Software-Entwicklungs-Workflow: Vom Gedanken zum Code

Ich entwickle mehrere Open-Source-Projekte auf Codeberg – hauptsächlich akisim (OpenSim Region Server in .NET) und akigrid (OpenSim Grid Server in Go). Bisher: Idee im Kopf, irgendwie anfangen, Issues nach Gefühl erstellen.

Jetzt gibt es einen durchgehenden Workflow, der nichts dem Zufall überlässt.

Schritt 1: grill-me – Den Plan stress-testen

Bevor eine einzige Zeile Code geschrieben wird, kommt

Code: Alles auswählen

/grill-me

zum Einsatz.

Du beschreibst deinen Plan und sagst: «Grill me on this plan.»

Was dann passiert ist verblüffend: Claude stellt eine Frage. Eine einzige. Wartet auf deine Antwort. Gibt eine Empfehlung. Fragt dann weiter. Immer eine Frage nach der anderen, immer mit einer eigenen Einschätzung. Er arbeitet sich durch jeden Ast des Entscheidungsbaums: Architektur, Abhängigkeiten, Schnittstellen, Testbarkeit, Edge Cases.

Die meisten Bugs entstehen nicht beim Coden – sie entstehen beim Planen. Unklare Anforderungen, übersehene Abhängigkeiten, Annahmen die niemand hinterfragt hat. grill-me macht diese Fehler sichtbar bevor sie teuer werden.

Schritt 2: write-a-prd – Das PRD erstellen

Ein PRD (Product Requirements Document) ist das Pflichtenheft der modernen Softwareentwicklung.

Code: Alles auswählen

/write-a-prd

führt ein strukturiertes Interview, schaut sich die bestehende Codebase an und erstellt dann ein PRD nach einem bewährten Template:

• Problem Statement – Was ist das Problem aus Nutzerperspektive?
• Solution – Was ist die Lösung, konkret und verständlich?
• User Stories – Exhaustive Liste aller Szenarien
• Implementation Decisions – Architektur, Module, Interfaces
• Testing Decisions – Was wird getestet, wie, warum?
• Out of Scope – Was explizit nicht gemacht wird

Das Ergebnis wird direkt als Codeberg Issue angelegt. Kein Copy-Paste, kein manuelles Formatieren.

Schritt 3: prd-to-issues – Zerlegen in vertikale Slices

Code: Alles auswählen

/prd-to-issues

übersetzt das grosse PRD in handhabbare Arbeitspakete.

Das Konzept dahinter heisst tracer bullet: Statt horizontale Schichten zu bauen (erst alle Datenbank-Änderungen, dann alle API-Änderungen, dann alle Tests), baut man dünne vertikale Scheiben, die durch alle Schichten gehen. Jeder Slice ist demobar, jeder Slice ist ein abgeschlossener Wert.

Der Skill schlägt die Zerlegung vor, du gibst Feedback, er iteriert. Dann erstellt er alle Issues in Dependency-Reihenfolge auf Codeberg – mit korrekten Blocker-Referenzen, mit den User Stories die jeder Slice abdeckt, mit klarer Acceptance Criteria.

Schritt 4: tdd – Red Green Refactor

Pro Issue:

Code: Alles auswählen

/tdd

aufrufen, Issue-Nummer angeben, loslegen.

1. Red: Schreib einen Test der das gewünschte Verhalten beschreibt – und der fehlschlägt, weil der Code noch nicht existiert.
2. Green: Schreib den minimalen Code um den Test grün zu machen. Nicht mehr, nicht weniger.
3. Refactor: Jetzt den Code aufräumen. Tests dürfen nicht brechen.

Was der Skill dabei besonders gut macht: Er testet Verhalten durch öffentliche Interfaces, nicht Implementierungsdetails. Ein guter Test bricht nicht wenn du eine Funktion intern umbenennst – er bricht nur wenn sich das sichtbare Verhalten ändert.

Nach grünen Unit Tests kommen Acceptance Tests mit Godog – Cucumbers Go-Implementation. Gherkin-Syntax, lesbar wie Prosa:

Code: Alles auswählen

Feature: Voice connection
  Scenario: Client connects via WebRTC
    Given a running grid server
    When a client initiates a WebRTC handshake
    Then the connection is established

Das grosse Bild:

Code: Alles auswählen

Idee
  ↓
grill-me       → Plan durchdenken, Fehler finden bevor sie entstehen
  ↓
write-a-prd    → PRD erstellen → Codeberg Issue
  ↓
prd-to-issues  → In vertikale Slices zerlegen → Issues erstellen
  ↓
tdd            → Issue für Issue implementieren (Red → Green → Refactor)
  ↓
Godog          → Acceptance Tests fürs Feature
  ↓
Commit + Close → Nächster Slice

Dieser Workflow klingt aufwändig. Er ist es nicht – er ist schneller als das Chaos, das er ersetzt. Claude übernimmt die strukturellen Schritte, du triffst die inhaltlichen Entscheidungen.


Ein Wort zu Token-Effizienz

Skills sind mächtig, aber sie haben einen Preis: Jede

Code: Alles auswählen

SKILL.md

wird bei jeder Claude-Anfrage in den Kontext geladen. Fünf grosse Skills gleichzeitig aktiv? Das sind Tausende von Tokens Overhead, bevor du überhaupt eine Frage gestellt hast.

Die Lösung ist simpel – Skills umbenennen:

Code: Alles auswählen

# Deaktivieren
mv SKILL.md disabled_SKILL.md

# Reaktivieren  
mv disabled_SKILL.md SKILL.md

Claude Code liest nur exakt SKILL.md. Alles andere ignoriert es. Ich halte aktuell nur git-guardrails und tdd permanent aktiv. Die grossen Skills aktiviere ich nur wenn ich sie wirklich brauche.


Was sich wirklich verändert hat

Drei Tage, zwei Dimensionen:

Im Vault: Was vorher ein wachsendes Chaos war, ist jetzt eine navigierbare Struktur. Jedes Verzeichnis hat eine Home-Karte. Jede Home-Karte verlinkt alle Inhalte. Die globale Home.md ist wirklich ein Einstiegspunkt, kein dekorativer Index.

In der Entwicklung: Was vorher vom Bauchgefühl abhing, hat jetzt einen Prozess. Nicht als Bürokratie, sondern als Sicherheitsnetz. Der Plan wird hinterfragt, bevor er umgesetzt wird. Issues sind klein genug, um abgeschlossen zu werden. Tests beschreiben Verhalten, nicht Implementierung.

Das Beste daran: Alles ist portabel. Die Skills, die Vault-Struktur, die Settings, die Hooks – alles liegt in Markdown-Dateien, versioniert, synchronisiert, auf jedem Gerät sofort verfügbar.

Ein zweites Gehirn mit KI-Muskelkraft dahinter. Das fühlt sich gut an.

– Aki, OpenSim-Betreiber / Radio-DJ / Vault-Archäologe

[akira]

akigrid – Wochenend-Update (18./19. April 2026)

Dieses Wochenende war richtig produktiv. Ich arbeite gerade an akigrid – einem selbst geschriebenen Ersatz für den Server-Kern, der hinter einer OpenSimulator-Grid-Instanz läuft (vergleichbar mit dem, was Robust.exe bei klassischen OpenSim-Setups macht). Das Ziel: moderner, stabiler, besser wartbar – und speziell auf meine eigene Grid-Infrastruktur zugeschnitten.

Samstag

Aufräumen & Grundlagen
Bevor man ein Haus baut, muss das Fundament stimmen. Ich bin dabei ein paar alte Überbleibsel aus früheren Projekt-Experimenten bereinigt und die Projektbeschreibungen für akigrid und seinen Schwesterserver akisim (der den Regions-Server ersetzt) massiv umzubauen – klarer, ehrlicher, mit realistischen Zielen.

Datenbank-Struktur angelegt
Der Server muss irgendwo seine Daten speichern – Grid-Einstellungen, Benutzerinfos, Regionen usw. Ich habe damit angefangen, die nötige Datenbankstruktur aufzubauen. Der erste Schritt war eine Tabelle für grundlegende Grid-Parameter. Klingt unspektakulär, ist aber die Basis für alles andere. Das Ganze wurde mit automatisierten Tests abgesichert, die beim Start des Servers prüfen ob alles korrekt angelegt wurde.

Architekturentscheidung: Lesen und Schreiben sauber trennen
Eine wichtige Design-Entscheidung für den Code: Abfragen (z.B. "was steht in der Datenbank?") und Änderungen (z.B. "schreib das in die Datenbank") werden im Code klar voneinander getrennt. Das macht den Server langfristig einfacher zu warten und zu testen – und ist eine bewusste Verbesserung gegenüber dem bisherigen PHP-System, das beides munter durcheinander mischt.

Sonntag

Grid-Info-Endpunkt fertiggestellt
Wenn ein Viewer (z.B. Firestorm) sich mit einem Grid verbindet, fragt er als erstes: "Wer bist du eigentlich? Wie heißt das Grid, wie lautet deine Adresse, welche Funktionen bietest du?" – Das ist der sogenannte Grid-Info-Endpunkt. Der ist jetzt vollständig implementiert, getestet und läuft. Ein wichtiger erster Meilenstein: akigrid kann sich gegenüber Viewern korrekt vorstellen.

Automatische Bereitstellung (CI/CD)
Bisher musste ich nach jeder Änderung den Server manuell auf dem Hetzner-Server aktualisieren. Das ist jetzt automatisiert: Sobald ich neuen Code hochlade, wird automatisch ein fertiges Server-Paket gebaut und bereitgestellt. Ich musste dabei ein kleines Netzwerkproblem auf dem Server lösen (ein Systemdienst hatte sich selbst in einen inkonsistenten Zustand manövriert), aber danach lief alles reibungslos durch.

Übergangsphase: Alter und neuer Server laufen parallel
Das bisherige Grid läuft noch auf dem alten PHP-basierten Server. Damit ich nicht von heute auf morgen alles umstellen muss, habe ich eine Brücke gebaut: Der alte Server leitet bestimmte Anfragen transparent an akigrid weiter. Für Viewer und Nutzer ändert sich nichts – im Hintergrund übernimmt akigrid aber schon einen Teil der Arbeit.

Eingebaute Überwachung
Ein Server, der im Stillen vor sich hin läuft und niemanden informiert wenn etwas nicht stimmt, ist schwer zu betreiben. Ich habe deshalb Schritt für Schritt ein vollständiges Überwachungssystem eingebaut:

• Tracing: Jede Anfrage hinterlässt eine Spur durch den Server – wie ein Röntgenbild das zeigt wo Zeit verbraucht wird und wo Fehler auftreten. Das hilft enorm bei der Fehlersuche.
• Metriken: Zahlen die kontinuierlich gesammelt werden – wie viele Anfragen pro Minute kommen rein, wie lange braucht die Datenbank im Schnitt, gibt es Ausreißer? Diese Daten können in einem Dashboard visualisiert werden.
• Automatische Tests für die Überwachung selbst: Auch das Überwachungssystem hat Tests – es wird geprüft ob die Metriken und Spuren tatsächlich ankommen und die richtigen Informationen enthalten.

Das alles klingt nach viel Overhead – aber ein Server ohne Überwachung ist wie ein Auto ohne Armaturenbrett. Man merkt erst dass etwas nicht stimmt wenn es zu spät ist.


Wo stehen wir jetzt?

akigrid kann sich gegenüber Viewern korrekt vorstellen, läuft in einem Docker-Container, wird automatisch gebaut und deployed, hat eine Datenbankanbindung mit sauberer Migrationshistorie, und ist mit einem vollständigen Überwachungsstack ausgestattet. Das Fundament steht.

Als nächstes geht es an die eigentlichen Grid-Dienste: Zuerst mal einen Dienst den wir noch nicht haben XBakes

Codeberg: codeberg.org/AkiraSonoda/akigrid