DiscourseSkill.md

Dev
1

Transfert du travail depuis Require LLM-generated themes & plugins to be tagged as such

Nous avons effectué une première version de la création de DiscourseSkill.md

lecture : DiscourseSkill.md

utilisation : DiscourseSkill.json

4

Quelle était votre base pour la création de cela ? Dès le début, il est indiqué que c’est destiné aux plugins, aux thèmes et aux composants de thème.

Mais mon impression est que le périmètre de la revue ne correspond pas à la structure des thèmes. Pourquoi le dossier javascripts/ n’est-il inclus que s’il se trouve dans un dossier assets ? Pourquoi restreindre settings.yml au dossier config ? Les thèmes n’ont généralement pas ces dossiers.

Il est ironique que nous discutions du fait que les contenus générés par IA peuvent ne pas répondre aux exigences de qualité, alors que la solution proposée ne semble pas plus fiable en soi.

5

Sur ce sujet très controversé — et étant donné qu’il est raisonnable de supposer que l’IA pose des risques importants pour nos capacités cognitives, notre vie privée et notre sécurité…

Je tiens simplement à dire que je suis reconnaissant pour cet outil, car il a mis en lumière des erreurs dans des plugins que j’avais créés avec l’aide de LLMs et que je n’aurais pas été capable de trouver par moi-même.

C’est exactement ce que j’avais commenté dans le sujet qui a donné lieu à celui-ci. Je ne disposais pas des connaissances techniques pour remettre en question les résultats eux-mêmes, mais plutôt leur application pratique.

Malheureusement, l’humanité dans son ensemble n’utilise pas toujours ses facultés de pensée critique lors de l’analyse des actions ou des réponses, et agit sous le coup des émotions — sans s’en rendre compte, de manière totalement inconsciente.

Cela nous mène à des préjugés inexacts quant à la validité ou la valeur de quelque chose qui, lorsqu’on l’examine de manière neutre, améliore en réalité une situation donnée. Je comprends qu’il s’agit d’un phénomène naturel qui est en train d’évoluer, et non d’une attaque personnelle.

Juste pour montrer mon humble soutien à l’auteur de la question pour cet outil.

6

Je suis d’accord. Comme je l’ai indiqué, il s’agissait d’une première version, qui a été améliorée grâce à vos retours. Nous avons jeté un autre regard et vous aviez raison.

Ajouté à la méthode de revue

  • Classification des candidats avant l’inspection des fichiers :

    • Plugin
    • Thème
    • Composant de thème
    • Extension hybride
    • Dépôt d’intégration
    • Artefact de publication

  • Inventaire séparé du dépôt partagé / de la publication :

    • README, licence, journal des modifications (changelog)
    • Fichiers de paquet et fichiers de verrouillage (lockfiles)
    • Flux de travail CI
    • Scripts d’installation / Docker
    • Intégrations de services externes
    • Assets de publication générés
    • Publication avec étiquette / archivée
    • Fichiers non suivis et ignorés pertinents

  • Inventaire des plugins étendu :

    • Chaque fichier chargé, enregistré ou exposé par plugin.rb
    • config/routes.rb
    • db/post_migrate/
    • Vues, moteurs, validateurs et middleware
    • Code frontend d’administration et public
    • Connecteurs, composants, routes, services, modèles et tests frontend
    • Styles communs, bureau, mobile, administration et intégrés
    • Fixtures, fichiers de support et tests navigateur / système
    • Dépendances Ruby, JavaScript, système et services externes
    • .discourse-compatibility
    • Branches et flux de travail d-compat/*
    • Bornes de version Discourse déclarées

  • Nouvel inventaire de thème / composant de thème :

    • about.json à la racine
    • Classification component
    • Métadonnées de licence, auteur, version et compatibilité
    • Assets, schémas de couleurs, captures d’écran et réglages thémables déclarés
    • settings.yml à la racine
    • locales/ à la racine
    • common/, desktop/ et mobile/
    • Fichiers SCSS et fichiers d’injection HTML pris en charge
    • javascripts/ à la racine
    • api-initializers/
    • Tous les fichiers .js, .gjs et .hbs
    • stylesheets/ à la racine et feuilles de style importées
    • assets/ à la racine et toutes les références à ceux-ci
    • Aperçus / captures d’écran
    • Tests et configuration de lint / build
    • Métadonnées et branches de compatibilité
    • Octets du thème empaqueté / exporté

  • Nouvelles vérifications structurelles :

    • Le type d’extension déclaré doit correspondre à about.json et au comportement d’installation.
    • component: true signifie composant de thème.
    • component: false ou omis signifie thème complet.
    • Les dépôts hybrides reçoivent tous les inventaires applicables.
    • Les fichiers mal placés ou inattendus sont investigués plutôt qu’ignorés silencieusement.
    • L’absence de dossiers optionnels n’est pas automatiquement un défaut.
    • L’arborescence de travail, l’archive de publication, l’extension installée, les assets générés et le candidat public sont des surfaces de preuve distinctes.

  • Nouvelle liste de contrôle pour thème complet :

    • Identité des métadonnées
    • Rendu du thème complet
    • Couverture des pages principales
    • Réglages, localisations et assets
    • Initialisateurs JavaScript / API pris en charge
    • Comportement responsive, accessibilité et RTL
    • Comportement Foundation, Horizon et intégré
    • Interactions avec les composants de thème
    • Vérifications d’installation, de mise à jour, de retour arrière et de compatibilité

Mon espoir est que les retours de la communauté améliorent la compétence (Skill) et que cette compétence aide les autres à évaluer leur propre travail ou, franchement, le travail des autres avant l’installation, en cas de doute quant à la qualité.

Jusqu’à présent, nous sommes à 2 sur 2. Vos retours ont permis d’améliorer la compétence et @satonotdead l’a trouvée utile. Merci pour vos mots gentils et votre soutien @satonotdead