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.
9.7 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.
Ich analysiere jetzt die bestehende AGENTS.md im Repo und vergleiche sie mit den verlinkten externen Wiki-Skill-Ideen, mit Fokus darauf, was trotz vorhandenem wikitool noch sinnvoll ergänzt werden kann. Danach gebe ich dir eine konkrete Potential-Liste mit priorisierten Empfehlungen für dein Test-Setup.
Ich hole jetzt parallel den aktuellen Wortlaut aus AGENTS.md und die beiden externen Referenzen, damit ich die Lücken und Überschneidungen sauber gegenüberstellen kann.
Fetched 2 resourcesthere are two solutions for what
Ich habe die Kerninhalte schon erkannt, hole jetzt noch die Raw-Versionen der beiden Dateien, damit die Analyse nicht durch GitHub-Navigationsrauschen verzerrt ist.
Fetched 2 resources
Zwischenstand: Die externen Vorlagen bringen viele Ideen, aber teils auch viel Meinung und Ballast; als Nächstes prüfe ich direkt den Umfang von wiki_tools, um nur realistische Potenziale relativ zu eurem eigenen CLI zu bewerten.
Searched for regex def cmd_|@click.command|subparsers|argparse|COMMAND|def main\( (**/tools/wiki_tools/**/*.py), 40 results
Ich lese jetzt die Kernkommandos von commands, um konkret zu sehen, was bereits automatisiert ist und wo zusätzliche Skills wirklich Mehrwert liefern würden.
Ich prüfe noch die Verlinkungs-, Index- und Publish-Kommandos, damit die Empfehlungen nicht an vorhandenen Features vorbeigehen.
Ich habe genug Kontext für die Richtung; ich ziehe jetzt noch präzise Stellen aus AGENTS.md, damit die Empfehlungen direkt auf konkrete Abschnitte gemappt sind.
Searched for regex Core Principle|Hard rule|No confident answer without a source|INGEST Workflow|QUERY Workflow|LINT Workflow|CREATE Workflow|UPDATE Workflow|Git Automation|wikitool|Provenance and Citation|Inline citation marker|confidence decay|sources coverage|publish (**/AGENTS.md), 79 results
Jetzt sammele ich noch punktuelle Code-Stellen aus dem CLI selbst, um Potenziale wie Gates, Drift-Checks und Automationslücken belastbar zu benennen.
Searched for regex fail_on_error|fail-on-error|uncovered_raw_files|citation_frontmatter_drift|Semantic Review|provenance|dry_run|--dry-run|source_url (**/tools/wiki_tools/commands/*.py), 52 results
Searched for regex publish_command|--push/--no-push|git add -A|git push|full_message|Nothing to commit (**/tools/wiki_tools/commands/git_publish.py), 6 results
Searched for regex def xref_link_source|--entities|sources.append|add_see_also_bullet|def xref_add (**/tools/wiki_tools/commands/xref.py), 8 results
Ich ziehe noch kurz die Konfiguration aus config.py, um zu sehen, welche Typen und Defaults heute hart kodiert sind und wo Standardisierungspotenzial liegt.
Abschließend prüfe ich noch log_append.py, um zu bestätigen, wie streng das Logging heute strukturiert ist.
Ich schaue kurz in README.md, damit die Potential-Einschätzung auch zur aktuellen Projekt-Intention passt und nicht nur zu den externen Vorlagen.
Mir ist bereits eine Inkonsistenz aufgefallen; ich prüfe noch README.md, um Doku-Drift zwischen Schema und CLI sauber zu erfassen.
Ich bin bei der finalen Auswertung; ich ziehe noch eine letzte konkrete Stelle zur internen Doku-Drift, damit die Empfehlung eindeutig ist.
No matches found. Your search pattern might be excluded completely by either the search.exclude settings or .*ignore files. If you believe that it should have results, you can check into the .ignore files and the exclude setting (here are some excluded patterns for reference:[/node_modules,/bower_components,**/.code-search]). Then if you want to include those files you can call the tool again by setting "includeIgnoredFiles" to true.
Ich habe die Drift schon gesehen, suche sie jetzt exakt in beiden Dateien separat, damit wir eine belastbare Referenz haben.
Searched for regex kebab-case|Use wikilinks (**/README.md), 2 results
Searched for regex human-readable titles with spaces|Wikilinks should match file names exactly|kebab-case (**/AGENTS.md), 2 results
Ich ergänze noch zwei Referenzen aus README.md, weil dort bereits sinnvolle nächste Ausbaustufen (CI/MCP) angedeutet sind.
Searched for regex Future considerations|MCP server wrapper|pre-commit/CI hook|lint --fail-on-error (**/tools/README.md), 3 results
Ja, hier ist klar Potential, aber nicht im Sinne von “noch ein Wiki-Skill drüberlegen”. Euer großer Vorteil ist schon da: ihr habt mit AGENTS.md plus wikitool eine deterministische Basis, die viele öffentliche Skills gar nicht haben.
Was bereits sehr stark ist
- Strikte Trennung zwischen mechanisch und semantisch ist sauber definiert in AGENTS.md und technisch umgesetzt in new_page.py, index_build.py, log_append.py, xref.py.
- Provenance-Regeln sind für ein Test-Repo schon ungewöhnlich reif: AGENTS.md, plus Coverage/Trace/Reverse-Index in provenance_cmd.py.
- Lint deckt viele harte Fehler bereits ab (inkl. citation/frontmatter drift, uncovered raw, provenance marker) in lint.py.
Höchstes Potential relativ zu Awesome + Farzaa, unter Berücksichtigung von wikitool
- Workflow-Orchestrierung als ein Kommando pro Operation.
- Heute sind in AGENTS.md lange Schrittketten dokumentiert, aber als einzelne CLI-Aufrufe verteilt.
- Potenzial: ingest run, lint run, update run als orchestrierte Kommandos mit Dry-Run-Plan vor Write.
- Mehrwert: weniger Agenten-Drift, weniger vergessene Zwischenschritte.
- Harte Sicherheits-Gates vor Massenänderungen.
- In externen Skills häufig: Confirm-Gates bei großen Writes.
- Bei euch sinnvoll für “>= N Dateien geändert” vor publish.
- Das passt gut zu Publish-Flow in git_publish.py.
- Session-Orientation als Pflicht vor Query/Update.
- Farzaa-ähnliche Orientierung (index + jüngste logs + scope check) würde gut zur QUERY-Qualität passen.
- Bei euch noch als Verhalten beschrieben, aber nicht erzwungen.
- Kandidat: preflight-Kommando, das Kontextbericht erzeugt.
- Semantik-Lint teilautomatisieren, ohne Determinismus zu verlieren.
- Ihr habt bereits “Semantic Review (LLM to complete)” in lint.py.
- Potenzial: zusätzlich maschinelle Heuristiken für stale claims, hohe Änderungsdichte, schwache Verlinkung als Priorisierungsliste.
- Split/Merge/Reclassify als dedizierte Kommandos.
- Externe Skills sind stark bei Anti-Cramming und Reorg.
- Bei euch ist das konzeptionell da, aber nicht als strukturierter CLI-Pfad.
- Potenzial: page split, page merge, reclassify mit automatischer Link/Frontmatter-Korrektur.
- CI-Absicherung jetzt schon einbauen.
- Ihr habt fail-on-error in lint.py.
- In README.md steht der richtige nächste Schritt bereits: Hook/CI vor publish.
- Für Testphase ideal, weil du sofort siehst, welche Regeln wirklich stabil sind.
- Optionales OKF-Kompatibilitätsprofil.
- In awesome-llm-wiki ist OKF ein großer Strang.
- Nicht als Ersatz, sondern als Export/Validate-Modus aus eurem Schema.
- Vorteil: spätere Interop mit anderen Tools, ohne internes Modell aufzugeben.
Was ich aus den externen Skills eher nicht übernehmen würde
- Personenzentrierte Taxonomien und Schreibstilregeln aus Farzaa (stark biografisch, weniger IT-operational).
- Sehr aggressive “always rewrite everything”-Loops im Daily-Betrieb.
- Große Multi-Agent-Orchestrierung zu früh, bevor eure lokalen Qualitätsmetriken stehen.
Konkreter Drift, den ich zeitnah korrigieren würde
- Namenskonvention widerspricht sich:
- README.md fordert kebab-case.
- AGENTS.md fordert menschenlesbare Dateinamen mit Leerzeichen.
- Für Test-Content ist das besonders wichtig, sonst verfälscht es jede Auswertung zu Konsistenz/Drift.
Kurzfazit Ihr seid konzeptionell bereits weiter als viele öffentliche “LLM Wiki Skills”, weil ihr Determinismus ernst nehmt. Das größte Potential liegt jetzt nicht in mehr Prompt-Text, sondern in 3 Dingen: orchestrierte End-to-End-Kommandos, harte Änderungs-Gates, und CI-gestützte Qualitätskontrolle auf Basis eures bestehenden wikitool.
- Wenn du willst, kann ich dir als Nächstes eine priorisierte Roadmap (2 Wochen / 6 Wochen) speziell für dieses Test-Repo ausarbeiten.
- Alternativ kann ich eine Soll-Ist-Matrix AGENTS vs wikitool-Kommandos erstellen, damit sofort sichtbar wird, was nur dokumentiert und was wirklich automatisiert ist.