torben
18ae28f918
Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki: raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren Grenzen in Code durchgesetzt sind statt im Prompt. Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44 Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist. Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs. Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte. Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet - siehe NOTICE.
59 lines
6.2 KiB
Markdown
59 lines
6.2 KiB
Markdown
> @gitea-mcp getzt schau dir die AGENTS.md an, ob wir hier Potential haben. Diverse analoge Wiki Skills habe ich über [https://github.com/gavischneider/awesome-llm-wiki](https://github.com/gavischneider/awesome-llm-wiki) gefnunden, z. B. [https://gist.github.com/farzaa/c35ac0cfbeb957788650e36aabea836d](https://gist.github.com/farzaa/c35ac0cfbeb957788650e36aabea836d). berücksichtige dabei, dass wir unser wikitool haben. Analysere das mal und schau, ob wir da Potential haben. GEhe davon aus, dass der Content, der derzeit in diesem Repo liegt, reiner Test-Content ist, mit dem ich gerade das Konzept teste.
|
||
|
||
Read [](file:///home/torben/src/llm-wiki-test1/tools/wiki_tools/commands)
|
||
|
||
Fetched 2 resources
|
||
|
||
Read [](file:///home/torben/src/llm-wiki-test1/tools/README.md)
|
||
|
||
Read [](file:///home/torben/src/llm-wiki-test1/wiki/index.md#1-1), lines 1 to 60
|
||
|
||
Searched for regex `stub|orphan|checkpoint|narrative|line count|150 lines|100 lines|bloat|tone|Wikipedia` (`**/AGENTS.md`), 3 results
|
||
|
||
Read [](file:///home/torben/src/llm-wiki-test1/tools/wiki_tools/commands/lint.py#1-1), lines 1 to 60
|
||
|
||
## Kurzfassung
|
||
|
||
Ja, es gibt Potential – aber eher an den **Rändern** (Qualitäts-/Wachstumskontrolle, Stil-Guide, Skalierungs-Schwellen), nicht am Kernkonzept. Euer AGENTS.md mit `wikitool` ist bereits eine der saubereren Umsetzungen des "Karpathy LLM-Wiki"-Patterns, das die awesome-list katalogisiert – insbesondere bei Provenance/Zitaten und deterministischer Tool-Unterstützung seid ihr strenger als das, was Farzas Gist beschreibt.
|
||
|
||
Ein Hinweis vorab: Im Farza-Gist steckt am Ende ein **Community-Kommentar** von "pascalandy" mit einem komplett anderen, eingefügten Schema ("Wiki Schema (Global)"). Das ist nicht Teil von Farzas eigentlichem Skill, sondern fremder Kommentar-Content mit eigener Tag-Taxonomie (`area/kind/topic/status/pty`). Ich habe ihn trotzdem mit ausgewertet, weil er ein paar brauchbare Ideen enthält – aber als separate Quelle, nicht als "das Gist".
|
||
|
||
## Wo ihr schon führt
|
||
|
||
- **Provenance/Zitate** (`raw_files:`, `provenance: sourced|general|mixed`, `^[[Source - X]]`, provenance.md-Reverse-Index) – das hat keines der beiden Referenzbeispiele in dieser Tiefe.
|
||
- **Deterministisches CLI statt LLM-Freihand** für Frontmatter, Xref, Index, Log, Confidence-Decay, Publish – Farzas Skill delegiert das meiste an "schreib ein Python-Skript" ad hoc, ihr habt es schon als stabiles Tool (siehe commands).
|
||
- **Confidence Scoring mit Decay-Formel** – existiert bei euch, im Gist nicht.
|
||
|
||
## Konkrete Lücken mit echtem Nutzen
|
||
|
||
**1. Keine Seitenlängen-/Qualitätsschwellen**
|
||
Farzas Skill hat harte Regeln: Stub-Minimum (≥3 Sätze / 15 Zeilen), Split-Schwelle (>120–150 Zeilen), Längen-Zielwerte je Typ. Der Kommentar-Schema-Vorschlag nennt 200 Zeilen. Euer lint.py prüft Struktur (Broken Links, Orphans, Frontmatter), aber nicht Seitengröße/Dürftigkeit. Bei 201 Seiten und wachsendem index.md lohnt sich ein Lint-Check für "zu lang" / "zu dünn" als Hinweis für die Semantic-Review-Sektion.
|
||
|
||
**2. Kein Stil-/Ton-Leitfaden**
|
||
Farza definiert explizit "Wikipedia, nicht AI-Ton" (keine Gedankenstriche, keine Blähwörter wie "groundbreaking", keine Floskeln wie "it should be noted", max. 2 Zitate/Seite). Euer AGENTS.md sagt nur "concise summaries" – ein kurzer Style-Abschnitt würde die Konsistenz der LLM-Prosa über viele Sessions hinweg verbessern.
|
||
|
||
**3. Anti-Cramming/Anti-Thinning-Heuristik fehlt**
|
||
Farzas Regel "wenn du den 3. Absatz zu einem Unterthema in eine bestehende Seite anhängst, verdient das Unterthema eine eigene Seite" ist eine konkrete, überprüfbare Entscheidungsregel für CREATE vs. UPDATE, die bei euch aktuell reines Judgment ist.
|
||
|
||
**4. Kein Checkpoint-/Qualitäts-Audit-Rhythmus**
|
||
Farza: alle 15 Einträge Index+Backlinks neu bauen, prüfen ob 0 neue Artikel entstanden sind ("cramming"-Alarm), 3 meistgeänderte Artikel als Ganzes neu lesen. Euer "Maintenance Schedule" hat nur "Full lint every 10 sources" – ergänzbar um einen echten Qualitäts-Audit-Schritt, nicht nur Struktur-Lint.
|
||
|
||
**5. Index-Skalierungsschwellen**
|
||
Der Kommentar-Schema schlägt vor: Tabellen-Sektion splitten, wenn >50 Einträge; eine `_meta/topic-map.md` anlegen, wenn Gesamtseiten >200. Euer index.md hat jetzt 201 Seiten in teils langen Tabellen (z.B. "Systems" mit 20 Zeilen) – das ist der erste konkrete Punkt, wo ihr in absehbarer Zeit tatsächlich an eine Grenze stoßt.
|
||
|
||
**6. Mass-Update-Bestätigungsgate**
|
||
"Wenn eine Operation ≥10 Seiten anlegt/ändert, anhalten und Bestätigung einholen" – eine sinnvolle Sicherheitsschranke, die z.B. bei `xref link-source --entities A,B,C,...` mit vielen Entities relevant werden könnte.
|
||
|
||
**7. Session-Orientierungsprotokoll**
|
||
Explizit: vor jeder Operation Schema + Index + letzte N Log-Einträge lesen, um Drift zu erkennen. Bei euch ist das im QUERY/LINT-Workflow implizit vorhanden, aber nicht als fester erster Schritt für *jede* Session formuliert.
|
||
|
||
## Was ich **nicht** übernehmen würde
|
||
|
||
- Die personenbezogene Verzeichnis-Taxonomie aus Farzas Skill (`people/`, `eras/`, `philosophies/`, `tensions/` …) – passt zu einem persönlichen Lebens-Wiki, nicht zu eurem IT-Domain-Schema.
|
||
- Die Subagent-Parallelisierung (Batches von 5 Subagenten pro Cleanup-Phase) – setzt eine Multi-Agent-Fähigkeit voraus, die hier (Ask-Mode/Copilot ohne Subagent-Orchestrierung) nicht direkt nachbildbar ist. Höchstens als "future consideration" vermerken.
|
||
- Die alternative Tag-Achsen-Taxonomie aus dem Kommentar-Schema (`area/kind/topic/status/pty`) – überschneidet sich mit eurem bestehenden `entity_type`/`concept_type`/`tags`-Modell und würde nur Verwirrung stiften.
|
||
- Das OKF (Open Knowledge Format, Google Cloud) aus der awesome-list – interessant als aufkommender Standard, aber für einen bewussten Test-Repo aktuell kein Mehrwert, den es zu jagen lohnt.
|
||
|
||
## Vorschlag für nächste Schritte
|
||
|
||
Da hier laut dir reiner Testcontent liegt, wäre mein Vorschlag, das AGENTS.md um einen kompakten neuen Abschnitt "Content Quality & Style" zu ergänzen (Stil-Regeln + Split-/Stub-Schwellen + Checkpoint-Kadenz) und lint.py um zwei neue mechanische Checks zu erweitern (Zeilenzahl-Ausreißer, Index-Sektionsgröße). Sag Bescheid, wenn ich das konkret ausformulieren soll – dazu müsste ich in den Edit-Modus wechseln, da ich hier im Ask-Modus nur analysieren, nicht schreiben darf. |