mcpField
A
audit-reference-originality

audit-reference-originality

github.com/akillnessテスト・品質5357 回インストール1 日前に更新
リポジトリ

audit-reference-originality について

Audit Reference Originality は、提供された参照資料と公開済みのサイトや体験を証拠に基づいて照合するスキルです。コンテンツ、ビジュアル、素材、動き、リポジトリ履歴に関する独自性のリスクを記録し、修正自体は自動で行いません。

主な機能

  1. 01参照資料の一覧作成
  2. 02サイト出力と履歴の調査
  3. 03テキスト、画像、素材の比較
  4. 04証拠による指摘の照合
  5. 05リスク評価と具体的な修正案
  6. 06アクセス不足と未確認範囲の報告

活用シーン

  1. 01提供された参照資料に照らした公開候補の監査
  2. 02改名・削除された素材が履歴に残るかの確認
  3. 03画像やコピーの重複を示す証拠の記録
  4. 04監査を妨げる参照資料の不足の特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/akillness/jeo-skills --skill audit-reference-originality

インストール後、Claude Code で/audit-reference-originalityを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

SKILL.toon
agents/
openai.yaml
references/
audit-rubric.md
scripts/
build_evidence_inventory.py

詳細

参照元の独自性を監査する

公開済みのエクスペリエンスと、参照コーパス全体を比較します。監査は印象ではなく、証拠に基づいて行います。

このスキルを使う場面

  • 提供された参照コーパス(マニフェスト、プロンプトパック、キャプチャパック、静止画、MP4、参照 URL、IMAGE_CREDITS.md)があり、公開済みのサイトやエクスペリエンスについて、独自性や盗用のリスクを確認する必要がある場合。
  • テキスト、ブランド、数値、画像、アセット、動画、レイアウト、モーション、コードを対象に、現在または過去のサイト出力を参照資料と比較する必要がある場合。
  • 主観的な「印象」ではなく、各項目に現行サイトと参照サイトの正確な位置、深刻度、修正案を示し、証拠に裏付けられた形で危険信号を報告する必要がある場合。
  • 一般的なビジュアル表現(黒い背景、大きなサンセリフ体、標準的なフェードイン)と、明確な証拠に基づき複製されたと判断できる特徴的な要素を区別する必要がある場合。
  • 複製された素材が名前の変更、色の変更、切り抜き、削除を経ている可能性があり、現行ファイルの確認に加えて git log/git show/git log -S による履歴確認が必要な場合。
  • 実際の差し替え作業を行う場合には使いません(ユーザーが修正も依頼している場合を除きます。このスキルでは監査と修正案の提示のみを行い、黙って変更を適用することはありません)。また、独自性と無関係な一般的なコードレビューやセキュリティ監査にも使いません。その場合は標準のレビュー/修正ワークフローに回してください。

監査の範囲を守る

  • ユーザーから修正も依頼されている場合を除き、監査のみを行います。
  • 所見は「独自性のリスク」「重複」「危険信号」と呼びます。ビジュアルの類似性だけを根拠に、法的な盗用と断定してはいけません。
  • 各危険信号に、現行サイトの正確な証拠と参照資料の正確な証拠を併記します。
  • 事実、推論、アクセスできなかった情報を分けて記載します。
  • ホームページのスクリーンショットだけを確認して、問題なしと判断してはいけません。

1. 参照元の一覧を作成する

まず、タスクで明示的に提供された資料、またはプロジェクトに記録された資料を確認します。

  • マニフェスト、プロンプトパック、独自性マトリックス
  • 代表的な静止画、全ページのキャプチャ、セクションの切り抜き
  • MP4 と、そこから抽出したモーションフレーム
  • 参照 URL と、名前が挙げられた制作者
  • 元のブランドアセット、コピー、数値、スクリーンショット、ダウンロードファイル
  • プロジェクト概要、IMAGE_CREDITS.md、ライセンス、クレジット表記ファイル

ブリーフ作成時に取得したローカルの証拠を優先します。実際に不足している情報を補う場合に限り、変更されている可能性のあるライブ参照を使用します。各参照について、パスまたは URL、役割、判明している場合は日付、証明できるカテゴリを記録します。

約束されていた参照資料が見つからない場合は、アクセス上の不足を報告して作業を止めます。全ページやモーションの監査を、表紙画像1枚だけの確認にひそかに縮小してはいけません。

2. 現行サイトとその履歴を調べる

次の項目を確認します。

  • レンダリングされたテキスト、メタデータ、ナビゲーション、行動喚起、法的文言、非表示のアクセシブルラベル
  • ブランド名、ワードマーク、ロゴ、アイコン、人、企業、URL、製品/インターフェースのデータ
  • 価格、指標、日付、件数、割合、パッケージ名、繰り返し使われる実績の主張
  • レンダリングされるすべての画像、背景、テクスチャ、スクリーンショット、フォント、ロゴ、アイコン、音声ファイル、ダウンロード可能なアセット
  • すべての動画、ポスター画像、フレームシーケンス、ショットの順序、トランジション、再生時間、再生処理
  • レイアウトの階層、セクションの順序、特徴的な構成、タイポグラフィの挙動、モーションの表現方法、シェーダー、カーソルエフェクト、インタラクションの流れ
  • 現行のソース、利用可能な場合はビルド済み出力、アセットの来歴、リポジトリの履歴

ファイル名だけを独自性の証拠とみなしてはいけません。ファイルのバイト列、目に見える結果、履歴を確認します。git log、git show、git log -S、git log --all --name-status を使い、名前が変更、削除、置換されたファイルも検索します。

ローカルファイルが利用できる場合は、決定論的なインベントリヘルパーを実行します。

python <skill-dir>/scripts/build_evidence_inventory.py \
  --site <site-root> \
  --reference <reference-file-or-directory> \
  --reference <another-reference> \
  --output <temporary-output.json>

このヘルパーは、現在および過去の完全一致ファイル、疑わしいベース名の再利用、正規化されたテキストの重複、繰り返し使われる数値トークンを検出します。出力は人による確認の手がかりとして扱い、自動判定の結論として扱ってはいけません。

3. カテゴリごとに比較する

調査結果を評価する前に、references/audit-rubric.md をお読みください。

少なくとも以下のカテゴリを監査してください。

  1. テキスト — 見出し、本文、ラベル、CTA、キャプション、法的表記、代替テキスト、メタデータ、装飾的な文言。
  2. ブランド — 名称、マーク、ロゴタイプ、独自のアイコン、人物、企業、パートナーシップ、URL、特徴的な言葉遣いによるアイデンティティ。
  3. 数値 — 指標、パーセンテージ、価格、日付、件数、プラン構成、期間、インターフェース上の数値。
  4. 画像 — 正確なファイル、トリミング、生成された派生画像、スクリーンショット、人物、ポーズ、物体、特徴的な構図、色の処理。
  5. アセット — フォント、アイコン、ロゴ、テクスチャ、モックアップ、ダウンロードファイル、コードバンドル、出所が不明確なサードパーティのメディア。
  6. 動画 — 正確なファイル、フレーム、ショット、タイミング、カメラワーク、編集のリズム、トランジション、オーバーレイ、ポスター、音声。
  7. 構成とモーション — セクションの順序、特徴的なレイアウト手法、固定表示のシーケンス、カーソル操作、シェーダー、特徴的な要素の組み合わせ。
  8. 履歴 — 後から名前変更、色変更、トリミング、非表示化、削除、置き換えが行われたコピー素材。

黒い背景、大きなサンセリフ体、一般的な料金表、標準的なフェードイン、ありふれたフッターなど、よくあるパターンだけでは危険信号になりません。特徴的な要素が組み合わさっている場合や、直接的な証拠がある場合は、問題として取り上げてください。

4. すべての危険信号を照合する

候補ごとに、以下を行ってください。

  1. 現行サイトの対象物とその位置を特定します。
  2. 参照元の正確な対象物とその位置を特定します。
  3. 意図を推測せず、確認できる重複点を述べます。
  4. 相違点を述べます。
  5. 基準に従って重大度を判定します。
  6. サイトの目的を保ちながら重複を解消できる、最小限の修正を提案します。

ファイルが完全一致する場合はハッシュ値を、コピー文の場合は正規化した抜粋を、画像の場合は並べたトリミング画像を、動画の場合は一致するタイムスタンプまたはフレームを使用してください。ソースブランドの文字列が、その使用を明示的に禁じているテスト内にのみ見つかった場合、公開コピーの違反には当たりません。その文脈を説明してください。

5. 修正を提案する

具体的な置き換えを優先してください。

  • 新しいブランドの対象者、提供内容、語彙に合わせて、ソースに似たコピーを書き換える
  • 名称、URL、ロゴ、人物、指標、日付、プラン名、法的表記を置き換える
  • 主題、構図、モチーフの配置が実質的に異なる新しい画像を生成するか、ライセンスを取得する
  • コピーされたアセットを置き換え、出所を記録する
  • 新しいショット、タイミング、トランジション、オーバーレイ、音声を使って動画を再編集する
  • 特徴的なセクションやモーションのシーケンスの順序を変更するか、再設計する
  • 必要に応じて、現行の出力から古いソース素材を削除し、リポジトリの履歴や公開済みの成果物からも削除する

コピーされたアイデンティティ、コピー文、メディア、構図への修正として、表面的な色変更を推奨しないでください。

6. 結果を報告する

次のいずれかの判定を冒頭に記載してください。

  • 確認した範囲では問題なし
  • リスクの低い類似点があるが問題なし
  • 変更を推奨
  • リリースをブロック
  • 証拠不足により判定不能

次に、以下を提示してください。

  1. 確認したソースの一覧
  2. 重大度の高い順に並べた危険信号の表
  3. カテゴリごとの確認結果
  4. 履歴に関する調査結果
  5. アクセス上の制約と、立証できていない領域
  6. 優先順位を付けた修正計画

重大なリスクがあるカテゴリを確認できなかった場合も、必ずその行を含めてください。証拠がないことを、問題なしと判定してはいけません。

完了チェック

  • 提供された参照形式をすべて確認した。
  • レンダリングされた出力とソースの両方を確認した。
  • テキスト、ブランド、数値、画像、アセット、動画、構成とモーション、履歴を確認した。
  • すべての危険信号に、2つの証拠の場所を記載した。
  • 完全一致とスタイル上の類似性を区別した。
  • 提案した修正では、コピーされた要素を隠すのではなく置き換える。
  • 未検証の項目を報告書に明記した。

References

コメント