DiscourseSkill.md

Require LLM-generated themes & plugins to be tagged as such の作業を移動します

DiscourseSkill.md の作成について最初の試みを行いました

読む: DiscourseSkill.md

使う: DiscourseSkill.json

この作成の根拠は何ですか?冒頭で、これはプラグイン、テーマ、およびテーマコンポーネント用であると記載されています。

しかし、私の印象では、レビューの範囲がテーマの構造と一致していません。なぜ javascripts/assets フォルダ内にある場合のみ含まれるのですか?なぜ settings.ymlconfig フォルダ内に限定されているのですか?通常、テーマにはそれらは存在しません。

AI生成のコンテンツが品質要件を満たさない可能性があるという議論をしているのに、提案された解決策自体が信頼できると感じられないという点は皮肉なものです。

この非常に物議を醸しているトピック — AIが私たちの認知能力、プライバシー、セキュリティに対して重大なリスクを posed していることは合理的に想定できることから…

私はただ、このツールに感謝していると言いたいだけです。なぜなら、LLMの助けを借りて私が構築したプラグイン内のエラーを、私自身では発見できなかったものを指摘してくれたからです。

これはまさに、このトピックにつながる元のトピックで私がコメントした内容そのものです。私は結果自体に疑問を呈する技術的な知識はありませんでしたが、むしろその実用的な適用について言及したかったのです。

残念ながら、人間社会全体として、現在、行動や反応を分析する際に批判的思考を常に行使しているわけではなく、感情に流されて行動しています — 自覚なく、完全に無意識の状態で。

これにより、中立な視点で見れば実際には特定の状況を改善しているにもかかわらず、何かの妥当性や価値に対して不正確な偏見を抱くことにつながります。これは変化している自然な現象であり、個人的な問題ではないことは理解しています。

ただ、このツールに対してOPへの控えめな支持を示すために書きました。

同意します。先ほど述べたように、これは最初の試みでしたが、あなたのフィードバックを反映して改善されました。もう一度確認したところ、あなたは正しかったです。

レビューメソッドに追加された内容
  • ファイル検査前の候補分類:

    • プラグイン
    • テーマ
    • テーマコンポーネント
    • ハイブリッド拡張
    • インテグレーションリポジトリ
    • リリース成果物
  • 共有リポジトリ/リリースインベントリの分離:

    • README、ライセンス、変更履歴
    • パッケージファイルとロックファイル
    • CI ワークフロー
    • インストール/Docker スクリプト
    • 外部サービスとの統合
    • 生成されたリリースアセット
    • タグ付け/アーカイブされたリリース
    • 関連する未追跡ファイルおよび無視対象ファイル
  • 拡張されたプラグインインベントリ:

    • plugin.rb によって読み込まれ、登録され、または公開されるすべてのファイル
    • config/routes.rb
    • db/post_migrate/
    • ビュー、エンジン、バリデーター、ミドルウェア
    • 管理画面およびパブリックフロントエンドコード
    • コネクタ、コンポーネント、ルート、サービス、テンプレート、フロントエンドテスト
    • common、desktop、mobile、admin、埋め込み用スタイル
    • フィクスチャ、サポートファイル、ブラウザ/システムテスト
    • Ruby、JavaScript、システム、外部サービスの依存関係
    • .discourse-compatibility
    • d-compat/* ブランチおよびワークフロー
    • 宣言された Discourse バージョンの範囲
  • 新しいテーマ/テーマコンポーネントインベントリ:

    • ルートの about.json
    • component 分類
    • ライセンス、著者、バージョン、互換性メタデータ
    • 宣言されたアセット、カラーシーム、スクリーンショット、テーマ設定可能な設定
    • ルートの settings.yml
    • ルートの locales/
    • common/desktop/mobile/
    • SCSS およびサポートされる HTML 注入ファイル
    • ルートの javascripts/
    • api-initializers/
    • すべての .js.gjs.hbs ファイル
    • ルートの stylesheets/ およびインポートされたスタイルシート
    • ルートの assets/ およびそれらへのすべての参照
    • プレビュー/スクリーンショット
    • テストおよび lint/ビルド設定
    • 互換性メタデータおよびブランチ
    • パッケージ化/エクスポートされたテーマバイト
  • 新しい構造チェック:

    • 宣言された拡張タイプは about.json およびインストール動作と一致する必要があります。
    • component: true はテーマコンポーネントを意味します。
    • component: false または省略は完全なテーマを意味します。
    • ハイブリッドリポジトリには、適用可能なすべてのインベントリが適用されます。
    • 誤った配置や予期しないファイルは、無視されるのではなく調査されます。
    • オプションのディレクトリの欠如は、自動的に欠陥とはみなされません。
    • ワーキングツリー、リリースアーカイブ、インストールされた拡張、生成されたアセット、パブリック候補は、別々の証拠面です。
  • 新しい完全テーマチェックリスト:

    • メタデータアイデンティティ
    • 完全なテーマのレンダリング
    • コアページのカバレッジ
    • 設定、ロケール、アセット
    • サポートされる JavaScript/API イニシャライザー
    • レスポンシブ動作、アクセシビリティ、RTL
    • Foundation、Horizon、埋め込み動作
    • テーマコンポーネントとの相互作用
    • インストール、更新、ロールバック、互換性チェック

コミュニティからの意見を反映して Skill を改善し、その Skill が他の人がインストール前に品質に疑念がある場合、自分の作業や、率直に言えば他人の作業を評価するのに役立つことを願っています。

これまでに 2 回中 2 回成功しています。あなたの意見が Skill の改善につながり、@satonotdead さんも有用だと感じています。@satonotdead さん、温かい言葉とサポートをありがとうございます。