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.
6.2 KiB
@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 gefnunden, z. B. 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.
Fetched 2 resources
Searched for regex stub|orphan|checkpoint|narrative|line count|150 lines|100 lines|bloat|tone|Wikipedia (**/AGENTS.md), 3 results
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 bestehendenentity_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.