このスキルの機能
「Xのいくつかの選択肢を比較して」という依頼を、実際に機能するツールに変えます。研究に基づいた、真に異なる複数のバリアントを生成し、それぞれを1つの共有可能な比較ボード上の独立したパネルに表示し、人間が比較、勝者の選択、フィードバックを行えるようにします。選択結果はエージェントに戻され、勝者をさらに深掘りします。
これはあらゆるものに機能します: 代替ソリューションアプローチ、UI/コンポーネントデザイン、テスト/評価戦略、生成メディア（コード、画像、音声、テキスト）。ボードは依存関係のないスタンドアロンHTMLファイルなので、どんなプロジェクトにもそのまま配置できます。
$ARGUMENTS は比較対象です。もし内容が曖昧な場合（何を比較するのか、どの次元を変動させるのか、どの被験者に対してか）は、生成する前に1〜2つの明確化質問をしてください。
基本原則（根幹 — 省略不可）
- 真に異なるバリアント — パラメータ調整ではない。 各バリアントは実際の、名前の付いた手法です。2つのバリアントがパラメータ値だけで異なる場合、それらは1つのアプローチを2回サンプリングしたものです — 統合してください。確認方法: 2つのバリアントを同じ文で説明でき、数字だけを入れ替えればよい場合、それらは異なるものではありません。
- リサーチこそが較正ステップである。 ドメインに文献や確立された手法が存在する場合、バリアントをデザインする前に実際の名前の付いた手法をリサーチしてください — WebSearch / ドキュメント /
references/を使用してください。想像だけでメニューを推測すると、過大または過小評価になります。（ドメイン別のリサーチプロンプトについてはreference.md §1を参照） - 統制された比較。 すべての入力を固定し、テスト中の1つの次元のみを変動させてください。同じ行のすべてのカードで、同じシード/シナリオ/プロンプト/コピーを使用します。固定された入力をその行の目標に明記してください。1行 = 1つの変動次元です。
- 客観的バッジ。 測定可能なものには、パネルごとに色分けされたメトリックバッジを付けてください（目標からの距離、合格率、レイテンシ、バンドルサイズ、コントラスト比など）。これにより、選択が雰囲気ではなく証拠に基づいて行われます。
- 交絡の分離 — 1つの成果物に対する複数のビュー。 同じ出力の複数のビューを見る価値がある場合、カードに
content.viewsトグルを付けてください（例: 楽譜 / ピアノロール / オーディオ / 生データ / 差分）。典型的なケースはRAW vs PROCESSED — 生の成果物を加工済みのものと並べて表示し、翻訳/色変更/正規化/シリアライズ/圧縮パイプラインのどの段階で悪い結果が生じたかを人間が特定できるようにします。content.rawはそのための2ビューショートカットです。決して偽のトグルを作らないでください。 実際に異なる場合にのみビューを追加してください — 加工済みと生が同一になる場合（忠実な変換）、トグルは削除してください。何もしないトグルは存在しないより悪いです。ボードはバイト単位で同一のビューを自動的に折りたたみ、ビューが1以下の場合はトグルを自動的に非表示にします。 - メトリックと成果物の正直さ。 実際の成果物をメトリックバッジの隣に表示し、矛盾があればそのまま見せてください。楽譜に明らかに低い3度があるのに「距離」バッジが0と表示されている場合、その矛盾こそが発見です — メトリックが何かを無視していることを意味します。それを表面化することが目的であり、成果物を数値の後ろに隠したり、数値を成果物に合わせて調整したりしないでください。
- 実コンテンツの原則。 すべてのパネルは実際の出力を表示します — スタブ、プレースホルダー、バイトサイズ確認は絶対に使用しません。実際のコンテンツがレンダリングされることを確認してください。オーディオの場合、コンテンツは実際に聞こえる必要があります — サンプルソースをブロックした状態で確認してください（
reference.md §9オフラインゲート）— 単にレンダリングされるだけでは不十分です。 - 1つの共有可能な面。 人間が開く単一のボード（ファイルまたはリンク）を出力し、散在する成果物にしないでください。
- チェックポイントの規律。 最初に最もリスクが高い/最も代表的なスライスを構築してください（1つの被験者、1つの行、実際のコンテンツ + 該当する場合はオーディオ/再生を含む）。スケールアップする前に人間に見せてフィードバックを得てください。
- ループを閉じる。 人間はボード上で勝者を選びフィードバックを残します。そのエクスポートがエージェントに戻り、洗練に使用されます。次に、勝者を深掘りします。
- 被験者ごとの勝者 + 融合。 テスト被験者ごとに最適なバリアントが異なる場合、被験者ごとの勝者を表面化し、勝者の特性を組み合わせた融合/合成ラウンドを追加してください。1つのグローバルな勝者を強制するのではなく、複数の被験者を用いる目的は、単一のアプローチがどこでも勝つことは稀であることを明らかにすることです — それを平均化して消し去るのではなく尊重してください。
ワークフロー
1. 比較内容を明確化する。 $ARGUMENTS から、何を比較するのか、行ごとに変動させる単一次元、統制する被験者/シード（2が適切なデフォルト）を確定します。本当に曖昧な場合にのみ質問してください。
2. 実際のバリアントをリサーチする。 ドメインに確立された手法がある場合、まずそれらを調べてください（reference.md §1 にリサーチプロンプトがあります）。行ごとに2〜6個の名前の付いた、真に異なるアプローチの短いリストを作成します。パラメータだけで異なる2つは拒否してください。
3. 各バリアントの実際のコンテンツを生成する。 各 (被験者, 行, バリアント) について、実際の成果物を生成し、そのコンテンツ種類を選択します: html（UI/テキスト）、code、image、iframe、audio（WebAudioシンセを含む）、または passfail（テスト/評価）。モダリティ表については reference.md §2 を参照してください。1つの出力の複数のビューを提供するには、content.views を名前付きビューのリストに設定します（最初のビューがデフォルト。同一ビューは折りたたまれ、1以下の場合はトグルが自動非表示になります） — または、パイプラインが真実を隠す可能性がある場合に content.raw 2ビューショートカットを使用します（原則5）。測定可能なものには客観的な badges を付け、実際の成果物の隣に表示して矛盾が表面化するようにします（原則4、6）。
実際のドメイン成果物（楽譜、チャート、図）のレンダリング: 信頼できる方法は、ヘッドレスページで <svg> にレンダリングし、svg.outerHTML を取得し、html コンテンツ種類で埋め込むことです（インラインSVG — <img> データURIは使用しないでください。SVG名前空間が失われ、壊れてレンダリングされます）。グリフレンダラー（例: VexFlow/Bravura）は、レンダリングページとボードの両方にフォントをbase64 @font-face としてインライン化し、レンダリング前およびスクリーンショット前に document.fonts.ready を待つ必要があります。template/render-artifacts.example.mjs はこれを正確に行うためのコピー＆アダプト用ハーネスです。完全なレシピと落とし穴については reference.md §6 を参照してください。
4. テンプレートからボードを構築する。 template/comparison-lab.html をプロジェクトにコピーします（サーブ可能な場所、または file:// 使用のためにどこでも）。template/README.md のスキーマを使用して、その隣に data.json にデータセットを書き込みます。新しいUIを手作りしないでください — テンプレートは既に付箋ボード、バッジ、トグル、ボタン、エクスポートを備えています。
- http(s)経由でサーブする場合:
data.jsonは自動的に取得されます。 - ダブルクリックで開く場合（
file://）: HTML内の<script id="inline-data">ブロックにデータセットを貼り付けてください（file://では兄弟ファイルの取得はブロックされます）。
5. 実際のコンテンツがレンダリングされることを確認する。 ボードを開き、すべてのパネルが実際の出力を表示していること（プレースホルダーではない）、バッジが色分けされていること、views/rawトグルが存在する場合は動作すること（実際の2つ目のビューがない場合は存在しないこと）、Pick/Feedback/Exportが動作することを確認します。ヘッドレスブラウザにアクセスできる場合は、スクリーンショットを撮ってください — 電話サイズでも（ボードはモバイルファーストです）。下書きのように読めるものがあれば修正してください。
6. チェックポイント — 最もリスクの高いスライスを共有する。 最初の被験者/行が完全に構築されたボード（リンクまたはファイル）を人間に渡します。残りをスケールアップする前にフィードバックを得てください。これは原則9です — 黙ってすべてを構築しないでください。
7. ピックを収集し、勝者を深掘りする。 人間が勝者を選び、メモを残し、ピックとフィードバックをエクスポート（MarkdownまたはJSON）をクリックします。その結果を受け取り、選択されたバリアントをさらに深掘りします — 洗練、強化、またはプロダクション化します。
ボードUI（テンプレートが提供するもの）
クリーンなホワイトボード上の付箋カード — 高コントラストの黒いテキスト、控えめな影、カードごとのパステルカラーヘッダーストリップ、まっすぐに整列しています。実際の付箋/かんばんボードに合わせて調整されています。
- ヘッダー: タイトル、固定されたイントロ、被験者/シード切り替えボタン（統制入力を切り替えるボタン）、バッジ凡例、リセット、ピックとフィードバックをエクスポート。
- 各カード（付箋）: バリアントラベル、1行の手法説明、汎用コンテンツスロット（インラインHTML/SVG、
<img>、サンドボックス化された<iframe>、<audio>/シンセ、<pre><code>、または合格/不合格チェックリストをレンダリング — データに基づく）、色分けされたメトリックバッジ、データがcontent.viewsまたはcontent.rawを提供する場合のオプションの名前付きビュートグル（ピル行）。 - カードごとのボタン: ★ ピック（勝者ハイライトを切り替え）、✎ フィードバック（インラインノート）、アクティブなビューに従うコンテンツアクション（▶ 再生、⤢ 開く、⧉ コピー）。
- エクスポート は人間のピックとメモをコピー可能なMarkdownまたはJSONとしてダンプします。ピックとメモは
localStorageに保存されます。 - 依存関係ゼロ、ネットワークゼロ — ファイルを開くだけで動作します。モバイルファースト: カードは電話で1列に折りたたまれ、タップターゲットは40px以上、被験者切り替えは固定ヘッダー内で操作可能、本文テキストは読みやすいままです。マウスとタッチの両方にフレンドリーで、
prefers-reduced-motionを尊重します。
ファイル
| ファイル | 目的 |
|---|---|
template/comparison-lab.html | ボード。自己完結型（インラインCSS + バニラJS）、モバイルファースト。そのままコピーしてください。再構築しないでください。 |
template/data.sample.json | 汎用性を証明する実動データセット（html, code, passfail, image+raw, Nビューの content.views トグル、2被験者にわたるaudio）。コピー → data.json、編集。 |
template/render-artifacts.example.mjs | 実際のドメイン成果物（楽譜/チャート/図）をボードにレンダリングするためのコピー＆アダプト用ハーネス — レンダラーをバンドルし、グリフフォントをインライン化し、ヘッドレスでインラインSVGを抽出し、注入 + スクリーンショット撮影。ADAPT THIS ブロックを編集してください。 |
template/README.md | data.json の入力方法。完全なスキーマ、フィールドごと（content.views を含む）。エクスポート形式。 |
reference.md | バリアントデザインの詳細 + ドメイン別リサーチプロンプト（§1）、モダリティレンダリングテーブル（§2）、バッジ（§3）、スキーマポインタ（§4）、実際の音楽の例（raw-vs-processedストーリーを含む）（§5）、実際の成果物のレンダリング + ヘッドレスハーネス（§6）、content.views スキーマ + メトリックvs成果物の教訓（§7）、モバイルファーストチェックリスト（§8）。 |
注意事項
- これは（ブレインストーミングのような）アプローチスキルです — スラッシュ呼び出し可能かつモデル呼び出し可能です。
disable-model-invocationを設定しないでください。 - HTMLテンプレートはそのままコピーしてください — すべてのUI作業は完了しています。あなたの仕事はデータです: 真のバリアント + 実際のコンテンツ + バッジ。
- ほぼ同一のバリアントのボードを出荷しないでください。各バリアントを明確な手法として名前付けできない場合、ステップ2を実行していません。
- コンテンツを偽装しないでください。プレースホルダーパネルは目的を無効にします（原則7）。
- 何もしないトグルを出荷しないでください。実際に異なる場合にのみ
views/rawビューを追加してください — 同一ビューは自動的に折りたたまれますが、実際の差分を想定してデザインしてください（原則5）。 - より大きなインタラクティブプレビューには、巨大な
html文字列よりも、srcdocを使用したiframeを推奨します。レンダリングされたSVGは、<img>データURIではなく、html種類で埋め込んでください（reference.md §6）。 - 生成されたメディアはインライン（
data:URI、WebAudioシンセ）に保ち、ボードが単一の共有可能なオフラインファイルのままになるようにしてください。