DiscourseSkill.md

Entwickler
1

Verschiebung der Arbeit aus Require LLM-generated themes & plugins to be tagged as such

Wir haben einen ersten Entwurf für die Erstellung von DiscourseSkill.md erstellt

lesen: DiscourseSkill.md

verwenden: DiscourseSkill.json

4

Was war die Grundlage für die Erstellung dieses Dokuments? Ganz am Anfang steht, dass es für Plugins, Themes und Theme-Komponenten gedacht ist.

Mein Eindruck ist jedoch, dass der Überprüfungsbereich nicht zur Struktur von Themes passt. Warum wird javascripts/ nur einbezogen, wenn es sich in einem assets-Ordner befindet? Warum wird settings.yml auf den config-Ordner beschränkt? Themes haben normalerweise nicht diese Struktur.

Es ist ironisch, dass wir darüber diskutieren, dass KI-generierte Inhalte möglicherweise nicht den Qualitätsanforderungen entsprechen, und die vorgeschlagene Lösung selbst nicht zuverlässiger wirkt.

5

Zu diesem hochkontroversen Thema – und angesichts der Tatsache, dass es vernünftig ist, anzunehmen, dass KI erhebliche Risiken für unsere kognitiven Fähigkeiten, unsere Privatsphäre und unsere Sicherheit birgt…

Ich möchte lediglich sagen, dass ich für dieses Werkzeug dankbar bin, denn es hat Fehler in Plugins, die ich mit Hilfe von LLMs erstellt habe, aufgezeigt, die ich allein nicht hätte finden können.

Genau das habe ich im Thema kommentiert, das zu diesem hier geführt hat. Ich hatte nicht das technische Wissen, um die Ergebnisse selbst in Frage zu stellen, sondern eher deren praktische Anwendung.

Leider nutzt die Menschheit als Ganzes derzeit nicht immer ihre kritischen Denkfähigkeiten, wenn sie Handlungen oder Reaktionen analysiert, und handelt aus Emotionen heraus – ohne es zu bemerken, auf völlig unbewusste Weise.

Das führt uns zu ungenauen Vorurteilen über die Gültigkeit oder den Wert von etwas, das, wenn man es neutral betrachtet, tatsächlich eine bestimmte Situation verbessert. Ich verstehe, dass dies ein natürliches Phänomen ist, das sich verändert, und nichts Persönliches ist.

Nur um meine bescheidene Unterstützung für den Ersteller dieses Themas für dieses Werkzeug zu zeigen.

6

Einverstanden. Wie bereits erwähnt, handelte es sich dabei um einen ersten Entwurf, der aufgrund eures Feedbacks verbessert wurde. Wir haben uns das noch einmal angesehen, und ihr hattet recht.

Hinzugefügt zur Prüfungs-Methode

  • Kandidaten-Klassifizierung vor der Dateiprüfung:

    • Plugin
    • Theme
    • Theme-Komponente
    • Hybrid-Erweiterung
    • Integrations-Repository
    • Release-Artefakt

  • Getrennte Inventarisierung des gemeinsamen Repositories/Releases:

    • README, Lizenz, Änderungsprotokoll
    • Paketdateien und Lockfiles
    • CI-Workflows
    • Installations-/Docker-Skripte
    • Integrationen externer Dienste
    • Erzeugte Release-Assets
    • Getaggtes/archiviertes Release
    • Relevante nicht verfolgte und ignorierte Dateien

  • Erweiterte Plugin-Inventarisierung:

    • Jede Datei, die von plugin.rb geladen, registriert oder offengelegt wird
    • config/routes.rb
    • db/post_migrate/
    • Views, Engines, Validatoren und Middleware
    • Admin- und Public-Frontend-Code
    • Connectors, Komponenten, Routen, Dienste, Vorlagen und Frontend-Tests
    • Gemeinsame, Desktop-, Mobile-, Admin- und eingebettete Stile
    • Fixtures, Support-Dateien und Browser-/Systemtests
    • Ruby-, JavaScript-, System- und externe Dienstabhängigkeiten
    • .discourse-compatibility
    • d-compat/*-Branches und Workflows
    • Deklarierte Discourse-Versionsgrenzen

  • Neue Theme/Theme-Komponenten-Inventarisierung:

    • about.json im Stammverzeichnis
    • component-Klassifizierung
    • Lizenz-, Autoren-, Versions- und Kompatibilitätsmetadaten
    • Deklarierte Assets, Farbschemata, Screenshots und thematisierbare Einstellungen
    • settings.yml im Stammverzeichnis
    • locales/ im Stammverzeichnis
    • common/, desktop/ und mobile/
    • SCSS- und unterstützte HTML-Injectionsdateien
    • javascripts/ im Stammverzeichnis
    • api-initializers/
    • Alle .js, .gjs und .hbs-Dateien
    • stylesheets/ im Stammverzeichnis und importierte Stylesheets
    • assets/ im Stammverzeichnis und alle Verweise darauf
    • Vorschau/Screenshots
    • Tests und Lint-/Build-Konfiguration
    • Kompatibilitätsmetadaten und Branches
    • Verpackte/exportierte Theme-Bytes

  • Neue Strukturprüfungen:

    • Der deklarierte Erweiterungstyp muss zu about.json und dem Installationsverhalten passen.
    • component: true bedeutet Theme-Komponente.
    • component: false oder weggelassen bedeutet vollständiges Theme.
    • Hybrid-Repositories erhalten alle anwendbaren Inventarisierungen.
    • Falsch platzierte oder unerwartete Dateien werden untersucht und nicht stillschweigend ignoriert.
    • Fehlende optionale Verzeichnisse sind nicht automatisch Mängel.
    • Arbeitsbaum, Release-Archiv, installierte Erweiterung, erzeugte Assets und öffentlicher Kandidat sind separate Beweisebenen.

  • Neue Checkliste für vollständige Themes:

    • Metadaten-Identität
    • Rendering des vollständigen Themes
    • Abdeckung der Kernseiten
    • Einstellungen, Lokalisierungen und Assets
    • Unterstützte JavaScript-/API-Initialisierer
    • Responsives Verhalten, Barrierefreiheit und RTL
    • Verhalten von Foundation, Horizon und Embeds
    • Interaktionen mit Theme-Komponenten
    • Installations-, Update-, Rollback- und Kompatibilitätsprüfungen

Meine Hoffnung ist, dass die Gemeinschaftsmitwirkung die Skill verbessert und die Skill anderen hilft, ihre eigene Arbeit oder, ganz offen, die Arbeit anderer vor der Installation zu bewerten, falls Zweifel an der Qualität bestehen.

Bisher stehen wir bei 2 zu 2. Euer Input hat zu Verbesserungen der Skill geführt und @satonotdead fand sie hilfreich. Danke für die freundlichen Worte und die Unterstützung, @satonotdead