Portable Markdown Knowledge
SkillSafeWerkstatt verwandelt Quellen in einen nachvollziehbaren Wissensraum: lokal pflegbar, als Markdown portabel und bis zur konkreten Fundstelle zitierbar.
Eine klare Grenze
Pflege darf verändern. Lesen darf nur verifizieren, suchen und antworten. Diese Trennung schützt den Wissensraum vor versehentlichen Änderungen.
Initialisiert und kuratiert den Wissensraum unter einem eigenen Maintainer-Claim, mit Vorschauen, Snapshots, Qualitätsprüfungen und einem echten Release-Protokoll.
Liest ausschließlich einen veröffentlichten, hashverifizierten Stand und beantwortet Fragen mit nachvollziehbaren Claims, Quellen und Qualitätsstatus.
Vom Material zur Antwort
Originale bleiben außerhalb. Im Wiki liegen nur treue Markdown-Quellen, kuratierte Aussagen und die für Prüfung und Navigation notwendigen Metadaten.
Material außerhalb des Wikis lesen und treu nach Markdown übertragen.
Quelle mit stabiler ID, Sprache, Herkunft und Hash nachvollziehbar machen.
Claims, Beziehungen, Cluster und Begriffswelten kontrolliert pflegen.
Graph bauen, linten, versionieren und das Manifest zuletzt schreiben.
Nur den verifizierten Release lesen und jede Aussage zurückverfolgen.
Sicher durch Konstruktion
Deterministische Werkzeuge sichern die Struktur. Fachliche Entscheidungen bleiben sichtbar, diskutierbar und bestätigungspflichtig.
Materielle Aussagen verweisen auf registrierte Quellen und konkrete Seiten-, Abschnitts- oder Zeitmarken.
Jeder Maintainer hält einen eigenen Claim; wirksam ist immer nur einer. Zwei Claims stoppen alle, statt einen zu verdrängen. Der private Besitznachweis bleibt außerhalb des Wikis.
Semantische Version, unveränderliches Protokoll und Dateihashes bilden eine eindeutige Lesegrenze.
Cluster, Links und statische Leseansichten funktionieren lokal, relativ und ohne Webserver.
Ersetzte und widersprüchliche Claims bleiben nachvollziehbar, statt still überschrieben zu werden.
Die vollständigen Agent Skills laufen mit relativen Pfaden in Claude Code, Claude Cowork und Codex.
Erzeugte Gruppenübersichten halten den Einstieg klein, während das Wiki wächst. Gelesen wird Wurzel, dann Zweig, dann Seite.
Jede Seite hält fest, wer sie erzeugt und wer sie geprüft hat. Ein Agent kann eigene Arbeit nicht als menschlich geprüft ausweisen.
Konfliktkopien, Systemartefakte, Pfadgrenzen und verspätete Synchronisation werden erkannt und getrennt von echter Beschädigung gemeldet.
Eine Seite darf ihr eigenes Enddatum nennen. Ein überschrittenes Datum wird offengelegt, nie zum Filter: Abgelaufenes bleibt auffindbar.
Wissen aus einer Besprechung wird zur regulären Quelle: mit benanntem Akteur und Anlass, sonst gar nicht.
Ein bestehender Vault wird als Evidenz übernommen, nicht als Wissen: registrierte Quellen, keine Seite ohne Beleg.
Kein Server, kein Dienst, kein Hintergrundprozess. Ein Verzeichnis aus Markdown bleibt lesbar, auch wenn nichts läuft.
Lokal geschrieben heißt nicht hochgeladen. Der Skill sagt, was er weiß, und benennt, was er nicht wissen kann.
Aus der Messung
Wer ein Wiki fragt, benutzt selten dessen Wörter. Wir wollten wissen, was dagegen hilft, und haben es an einem Test-Wiki mit 114 Fragen gemessen. Sieben davon fragen nach Themen, die gar nicht drinstehen. Unser Ergebnis: Mit Bedeutung, die beim Pflegen ins Wiki geschrieben wird, findest du mehr und behältst ein ehrliches „nicht gefunden“. Die getestete Embedding-Tabelle verliert genau das.
Allein durch Seiten-Aliase in Nutzersprache
+17 Fragen
57 → 74 von 107 gefunden. Das Feld gibt es schon, gefüllt wird es bei der Pflege.
Englische Fragen an ein deutsches Wiki
1 → 7 von 8
gefunden, weil englische Begriffe in denselben Aliasen stehen.
Zusatznutzen einer Embedding-Tabelle
+0
auf kuratierten Begriffen und Wortformen: 93 gefundene Fragen bleiben 93.
Fragen, deren Fundstellen alle unter den ersten 12 Treffern stehen, von 107 beantwortbaren. Mehr ist besser.
Am billigsten sind Aliase: 17 Fragen mehr, ohne eine Zeile Code. Die Embedding-Tabelle findet mehr als die Wortsuche allein. Gegen Aliase plus Wortformen verliert sie, und obendrauf gesetzt bringt sie keine einzige Frage dazu.
Treffer für die 7 Fragen, auf die das Wiki keine Antwort hat, höchstens 12 je Frage. Weniger ist besser.
Aliase kosten zwei Fehltreffer, mehr nicht. Die Embedding-Tabelle gibt immer die nächsten Nachbarn zurück, auch wenn keiner passt. „Nicht gefunden“ kommt bei ihr nie vor. Wortformen helfen viel und kosten Präzision. Deshalb bauen wir sie erst ein, wenn eine eigene Präzisionsprüfung steht.
| Variante | Top 3 | Top 12 | Top 100 | Fehltreffer |
|---|---|---|---|---|
| Wortsuche heute | 47 | 57 | 62 | 16 |
| + Seiten-Aliase in Nutzersprache | 64 | 74 | 79 | 18 |
| Statische Embedding-Tabelle | 68 | 81 | 99 | 84 |
| Aliase + Wortformen (Selbstversuch) | 82 | 93 | 97 | 50 |
Top 3, 12 und 100 zählen die Fragen von 107, deren Fundstellen alle unter den ersten 3, 12 oder 100 Treffern stehen. Fehltreffer zählen die Treffer für 7 Fragen ohne Antwort im Wiki, höchstens 12 je Frage. Bei 100 Plätzen liefert die Embedding-Tabelle fast jede der 52 durchsuchten Dateien. Ihr Wert in dieser Spalte sagt deshalb wenig.
Identität vor Inhalt
Vor der ersten Datei klärt der Pflege-Skill Zweck, Zielgruppe, Sprache, Tonalität, Grenzen und den Umgang mit Historie. Erst ein bestätigter Vorschlag wird Teil des Wissensraums.
SOUL.mdDefiniert Antwortsprache, Anrede, Ton, Ausführlichkeit, Quellenanzeige, Unsicherheit sowie Grenzen und Tabus.
schema/CONTENT_POLICY.mdTrennt aktuellen Stand, historisches Journal und Hybridmodell, ohne automatische Löschung.
Kein Datensilo
Ein Wissensraum, aus dem man sein Wissen nicht herausbekommt, ist eine Falle. Jeder verifizierte Release lässt sich als Bündel im Open Knowledge Format v0.2 ausgeben, dem herstellerneutralen Markdown-Standard von Google Cloud.
Das Bündel nimmt die registrierten Quellenextraktionen mit. Ein Export, dessen Konzepte auf Quellen verweisen, die er nicht enthält, hat seine Belegkette in dem Moment verloren, in dem er den Rechner verlässt.
log.md und WurzelindexDer Export ist konstruktionsbedingt ärmer als das Wiki. Statt das zu verschweigen, führt jedes Bündel in seiner eigenen README.md auf, was nicht mitkam.
SOUL.md bleiben im WikiNach dem Schreiben validiert der Export das Bündel gegen die Konformitätsregeln. Was die Prüfung nicht besteht, wird entfernt statt ausgeliefert.
Exportiert wird nur ein verifizierter Stand. Läuft gerade eine Pflege, entsteht kein Bündel. Ein halbfertiger Stand darf das Haus nicht verlassen.
Der Export schreibt ausschließlich in das gewählte Zielverzeichnis. Das Wiki bleibt unverändert, und das Bündel ist eine Kopie, keine zweite Wahrheit.
Startklar als Agent Skill
Lade beide Skills herunter: einer für die kontrollierte Pflege, einer für das sichere Konsumieren veröffentlichter Wissensstände. Der Weg nach draußen ins Open Knowledge Format ist eingebaut.