tk-blind-comparison

ブラインド比較

既存の候補を人間が比較するためのものです。候補の生成や、エージェントによる品質判定は行いません。ユーザーがブラインド比較を依頼した場合は、比較を作成します。主観的な選択肢を提示されたにすぎない場合は、ブラインドギャラリーを提案し、候補を選んだりファイルを作成したりせず、承諾を待ちます。単一の変更の確認には tk-qa-sheet、開示されたトレードオフに関する質問には tk-grill、候補の作成には tk-prototype、tk-tts、または該当する生成ツールを使用します。

1. 利用可能な証拠から、比較する共通の問い、候補、項目、および同等の入力ソースを確認します。候補は少なくとも2つ必要です。失敗した出力も保持します。マニフェストとコマンドを読みます。元データは変更せず、コンテンツのリビジョンを記録します。出力が変更された場合は新しい評価が必要ですが、変更されていない出力の評価は維持します。
2. 書き込む前に、Artifact Paths を適用します。HTML、表示用コピー、および分離した解答キーには .tigerkit/tmp/tk-blind-comparison/<run-id>/ を使用します。返された評価と要約には .tigerkit/evidence/tk-blind-comparison/<run-id>/ を使用します。明示された保存先がある場合はそれに従います。HTML 出力を読み、パッケージのテーマアセットをインライン化します。ドキュメントのナビゲーションを追加せず、ギャラリーのインターフェースを維持します。
3. 候補の識別情報を含まない表示用コピーを用意します。該当する音声、画像と UI キャプチャ、テキスト、または動画の参照だけを読みます。比較対象の観点を損なわずに、表面的な識別情報とメタデータを除去します。変換内容と、残った手がかりを見える形で記録します。正規化に失敗した場合も、中立的な理由を付した失敗カードとして残します。診断の詳細は解答キー内に非公開で保持します。
4. 準備したマニフェストを使って、同梱のビルダーを実行します。候補の追加・削除・並べ替えでは、同じ study ID と以前の解答キーを再利用し、新しい出力ディレクトリを作成します。外部から意味を推測できない安定した候補 ID、項目 ID、コンテンツフィンガープリントを維持します。項目ごとのシャッフルにはシードを使用し、候補名と重複しない中立的なラベルを付けます。候補の識別情報を、ファイル名、DOM ID、アクセシビリティ名、デフォルトのテキスト、並べ替えに含めてはいけません。解答キーは分離して保持し、明示的な表示切り替えを設けます。オフラインでのブラインド化は気軽な手がかりを防ぐものであり、ソースの検査を防ぐものではありません。暗号学的な安全性や試験としての安全性を主張してはいけません。比較のトピック、項目タイトル、共通のスクリプト、評価ガイドは、選択中の項目の固定表示コンテキスト内に表示し続けます。評価にアクセスしやすいよう、長いコンテキストの高さを制限します。
5. 保存したローカル HTML を tk-browser-verify で検証します。デスクトップとモバイル、両方のテーマ、メディアのデコード、すべての失敗カード、キーボード操作、ネイティブの1～5のスコア選択、メモ、任意のお気に入り設定、再読み込み、候補の追加、JSON のインポート／エクスポート、評価のコピーとクリップボード利用拒否、部分表示の確認／キャンセル、表示後のみの平均値、ストレージ利用拒否を確認します。コピーにはエクスポートと同じブラインドキーのペイロードを使用します。クリップボードへのアクセスに失敗した場合も評価を保持し、ファイルへのエクスポートを提示します。ビルダーはメディアを埋め込みます。ホスティングせずに file:// から開きます。ローカルファイルでのブラウザーの localStorage の動作は一定ではありません。保存に失敗した場合はそれを表示し、JSON によるバックアップ／インポートを提示します。ファイルの移動や別のブラウザーの使用時には、以前のエクスポートのインポートが必要になる場合があります。未実施の確認項目は正直に報告します。
6. ローカル HTML と解答キーのパス、リビジョン／件数、変換内容、実施した確認項目、残る人間による評価を返します。明示的な依頼がある場合に限り公開します。実際の評価が届くまで待ち、スコアを捏造してはいけません。コピーされた JSON または JSON エクスポートが届いたら結果を読み、対応する解答キーと照合して検証し、件数／平均値と項目別の表を集計します。評価者数、未入力のスコア、失敗、サンプル上の制約を明記します。利用可能な客観的指標はスコアの低い項目と比較しますが、主観的な平均値を統計的な証明として扱ってはいけません。 サーバー、共有データベース、複数評価者によるライブデータ収集、統計検定、自動的な勝者判定、ソースの変更、モデルのインストール、合成は行いません。既存の音声／動画の比較を、新たな TTS の実施許可とみなすことはできません。ユーザーが別途新しいナレーションを依頼し、その選択が未確定の場合に限り、TTS について質問してください。

成果物のパス

成果物を扱うにはタスクの許可が必要です。書き込み、チェックアウト、転送、除外設定を行う前に、Git の除外設定、パス、所有権を確認するため、成果物のパスを読んでください。コンテキスト内に同一の内容があれば再利用し、不確かな場合はハッシュを確認して、変更や消失があれば読み直し、安全性を必ず再確認してください。保存先が明示されていない場合は .tigerkit/ を使用してください。チャットのみの場合は、ファイル／除外設定とこの参照を省略してください。これによって、無関係な変更や公開の許可が与えられるわけではありません。許可された機密情報を含まないファイルのクリーンアップには、新しいディレクトリと、サポートされているゴミ箱を優先してください。対象には、記録済みのリテラルな解決済み絶対パスのうち、実行によって作成されたものだけを指定してください。cd と glob／相対パスによる削除は行わないでください。

ユーザーへの質問

事実を調査し、既存の許可を再利用してください。ユーザーが所有する判断については 質問ラウンドを読み、それ以外はそのまま進めてください。 通常のチャットでは、承認が1件だけの場合でも、単独の --- に続けて、 項目ごとに ❓ **Q<n> · <タイトル>**: <質問> と ➡️ <推奨事項> を記載してください。 確定済みの前提条件についてのみ質問し、承認は別に求めてください。 質問は最後にまとめ、ステータス、リスク、計画をその前に記載してください。

スキルへのフィードバック

再利用可能なインシデントについては、機密情報を含まない最小限の根拠を現在の会話内に保持し、tk-retro を提案してください。ユーザーから求められない限り、永続メモリには書き込まないでください。 実行、フィードバック成果物、インストール済みスキルの編集、公開には、所有するワークフローを通じた個別の許可が必要です。この案内によって許可が与えられるわけではありません。

読者向けの結果概要

結果、実際に行った検証、重要な制約、成果物への直接リンクを含む簡潔な概要を返してください。計画や未実施の確認と、実行済みの作業を区別し、未解決の手動確認、実際のクリーンアップ、阻害要因、人による対応の詳細を残してください。未検証の完了やクリーンアップを主張しないでください。所有者が求める成果物、公開プレビュー、承認境界、機械可読な返却内容、正確なステータス／フッター、最後の質問ブロックを維持してください。入れ子になった返却内容は簡潔にし、空のセクションは省略してください。

出力表記

囲み数字／キーキャップ数字ではなく、ASCII の番号付け（1. 項目、(1) 項目）と - 項目 を使用してください。省略記号を使わず、完全なクリック可能な絶対ファイルパスを例も含めて示してください。編集が許可されていない限り、コード、コマンド、識別子、URL、引用、検証済みの UI ラベルは正確に維持してください。

チャットで複数の共通属性を比較する場合は、狭い GFM パイプテーブル（列は約4列、ヘッダーあり、セルの内容は簡潔）を使用してください。それ以外の場合はリストを使用してください。罫線文字、コードフェンス付きのテーブル、空のテーブルは使用しないでください。所有者固有のプレビューを優先し、公開用の本文とファイル成果物は、それぞれ独自のテーブル形式を維持してください。

レンダリングされる Markdown の文章では、範囲にハイフンを使用し、リテラルのチルダは \~ とエスケープしてください。正確なコード、引用、識別子はそのまま維持してください。

許可された一時入力ファイルを作成して使用する場合は、作成と使用の前に「成果物のパス」に従ってください。事前入力済みのテンプレートは、入力済みの成果物ではありません。これによって書き込み権限が与えられるわけではありません。