Aki's Vibes - Druckversion

Aki's Vibes - Druckversion

+- GridTalk.de (https://www.gridtalk.de)
+-- Forum: Projekt Foren (https://www.gridtalk.de/forumdisplay.php?fid=48)
+--- Forum: Sonstiges (https://www.gridtalk.de/forumdisplay.php?fid=64)
+--- Thema: Aki's Vibes (/showthread.php?tid=5342)

Seiten: 1 2 3

RE: Aki's Vibes - Bogus Curry - 09.03.2026

Das mit webrtc hat manni mal vor monaten hier gepostet

RE: Aki's Vibes - Akira - 10.03.2026

(09.03.2026, 23:00)Bogus Curry schrieb: Das mit webrtc hat manni mal vor monaten hier gepostet

Ich weiss, aber damals war es noch nicht auf meinem Radar.

Aki's Vibes - Akira - 06.04.2026

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:
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:
npx skills add vercel-labs/agent-skills@grill-me -g -y

Sie landen in

Code:
~/.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:
/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:
/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:
/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:
/tdd

aufrufen, Issue-Nummer angeben, loslegen.

Red: Schreib einen Test der das gewünschte Verhalten beschreibt – und der fehlschlägt, weil der Code noch nicht existiert.
Green: Schreib den minimalen Code um den Test grün zu machen. Nicht mehr, nicht weniger.
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:
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:
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 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:
# Deaktivieren

mv SKILL.md disabled_SKILL.md

# Reaktivieren  

mv disabled_SKILL.md SKILL.md

Claude Code liest nur exakt

Code:
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