verification-methodology

検証方法

事前に定義された基準に照らして合否を評価します。

検証プロトコル

1. 受領 — 検証対象の成果物、主張、または実装と、それによって下される判断を言い直します。
2. 基準の評価 — 要件を観察可能な合否条件に変換し、各主張を否定するものが何かを特定します。
3. 調査 — 依頼で指定されたソースから直接かつ再現可能な証拠を収集し、コマンド、ソースの場所、またはソース URL を記録します。ソースにアクセスできる場合は、自分で収集してください。自分で取得できる証拠をユーザーに伝えてもらうよう求めてはいけません。自分に本当にないアクセス権が必要な場合に限り、アクセスを求めます。
4. 判定 — 各基準を合格、不合格、ブロック、または該当なしとします。証拠がないことを合格にしてはいけません。
   • 検証が複数のレーンに分かれている場合、どのレーンの PASS もゲート全体の判定にはなりません。すべての必須レーンの結果を待ち、統合する前に矛盾を調整します。
   • 後から得られたソース忠実性の BLOCK は、同じ成果物ハッシュに対する、それ以前の文章、レンダリング、またはチェックリストの PASS に優先します。それ以前の PASS パケットには、後続の作業者が現在の判定と誤認しないよう、直ちに superseded のラベルを付けます。
   • パターンスキャンや内部整合性の確認で、指定された一次ソースまたはソース資料に照らした事実の変換確認を代替することはできません。
5. 報告 — 判定テンプレートを使い、検証済みの事実、前提、残作業を区別します。判定には、候補のコミット／コンテンツハッシュ、受け入れ契約のバージョン／ハッシュ、レビュー対象範囲、実施したチェック、環境／フィクスチャ、結果、証拠参照を紐付けます。関連する変更があれば、該当する承認と証拠は無効になります。以前のパケットに superseded のラベルを付け、納品前に再検証してください。ブランチ、PR、またはコミットが変更されていなくても、ダーティなコンテンツが変わっていれば、同じ候補ではありません。

すべての基準に直接的な証拠、または明示的なブロック／該当なしの判定が得られた時点で終了します。基準が曖昧な場合、証拠が矛盾する場合、または必要なアクセスが得られない場合はエスカレーションします。

ソース忠実性

依頼または設定で指定されたローカルサービスは、交換可能なトピックラベルではなく、検証基準の一部として扱います。

1. 対応するスキルを読み込み、隣接するインテグレーション、汎用ウェブ検索、公開プロジェクトのソースより先に、そのスキルで文書化されている実行可能ファイルまたはサービスの経路を使用します。
2. スキル自体が解決した経路を使用します。グローバルな PATH に項目がないからといって、同梱された実行可能ファイルが利用できない証拠にはなりません。
3. 直接のソースで失敗した場合は、試したコマンドまたはエンドポイントと、正確な失敗内容を報告します。別のソースからの証拠で黙って代用してはいけません。
4. ユーザーがより広い文脈を求めるか、代替手段を明示的に認めた場合に限り、代替ソースを使用します。代替ソースの証拠は二次情報として明記し、依頼されたソースの状態として提示してはいけません。

例：「Jellyfin の新機能は？」という質問に対し、Jellyfin スキルと同梱 CLI が設定されている環境では、まず同梱 CLI を通じてそのサーバーに問い合わせます。Home Assistant のエンティティと公開されている Jellyfin プロジェクトの活動は、それぞれ別の質問に答えるものです。

使用しない場合

成果物、主張、判断、または観察可能な完了基準のない、自由形式の探索にはこのスキルを使用しないでください。まずリサーチまたは発見スキルを使用し、反証可能な検証対象ができた段階でここに戻ります。

関連スキル

• playwright — 検証手段としてのブラウザベースの E2E チェック：実際の UI 境界に対する仕様の作成と実行。
• documents — PDF／Word／Excel／PowerPoint の成果物として、検証レポートや証拠パケットを作成します。

参照ファイル

参照先	読み込むタイミング
references/criteria-assessment.md	作業が完了基準を満たしているか評価する必要がある場合
references/evidence-standards.md	証拠が主張を裏付けているか判断する必要がある場合
references/magnus919-refine-to-ship-gate.md	Magnus919 Refine-to-Ship 検証ゲート（12 項目、編集変更の検証、出力構造）を実行する場合
references/verdict-template.md	合格／不合格／保留の判定を構造化して出力する必要がある場合

Magnus919 Refine-to-Ship ゲートの基準

検証者プロファイルの12項目です。各項目は、観察可能で再現可能なチェックに対応しています。

12項目すべて

#	基準	確認方法
1	ダッシュのスキャン — em dash（U+2014）、en dash（U+2013）、horizontal bar（U+2015）、または本文中で見える二重ハイフンがゼロ	search_files で [\u2014\u2013\u2015] と \-\- を検索します。YAML フロントマターの区切りに使われる二重ハイフンは問題ありません。
2	ファクトチェック — 方法論に関する主張がすべて出典に対応し、捏造された数値、時系列、普遍的な主張がない	記事中の主張を出典ドキュメントの各セクションと照合します。\d+%、percent、average of、illustrative を検索します。research proves、studies demonstrate も検索します。
3	文体チェック — Magnus 独自の特徴：会話調の一人称、短縮形、「But」を使った転換（形式的な接続表現ではない）、セミコロンよりコロンを使う、コンサルタント調を避ける	Furthermore、Moreover、Nevertheless、Consequently、Therefore、not only.*but also、三項並列を検索します。コロンとセミコロンの数を数えます（大幅にコロンが多いこと）。
4	オックスフォードコンマ、スペル、文法 — アメリカ英語、列挙ではオックスフォードコンマを使用し、スペルミスがない	列挙を手動で読み、書式が一貫しているか確認します。
5	定型的なAIの締めくくりがない — 「In conclusion」「To summarize」「In this article」、一般的な激励の言葉がゼロ	search_files で In conclusion、Ultimately,、To summarize、In this article、In this post を検索します。
6	方法論を優先 — 個人的な導入は記事全体の約10％以下、残りは方法論	導入部分と本文部分の段落数を数えます。
7	人間への影響を組み込む — 認知的負担、専門性の形成、作業の移転、監視への反対、責任を負う権限	専用のセクションがあるか、または各側面が記事全体にわたって扱われているか確認します。
8	プライバシー／匿名化 — 企業識別情報、役職名、実名、出典ファイル名、独自ドメインの例がゼロ	search_files で企業名、製品名、出典固有の用語を検索します。
9	フロントマター — タイトル、スラッグ、日付、署名が正しく、仕様と値が一致している	read_file で1～11行目を確認します。
10	リンクの有効性 — URLごとに、最初に意味のある形で言及される箇所で1回だけ登場し、すべてが200を返す	URLごとに curl -s -o /dev/null -w "%{http_code}" を実行します。リンクテキストが最初に意味のある形で言及される箇所にあるか確認します。
11	Hugo ビルドとルート — ビルドの終了コードが0、新しいルートが200を返し、以前の take-home-title ルートが404を返す	hugo --quiet && echo EXIT:$? を実行します。両方のルートに curl を実行します。
12	出典バンドルの重複がない — ディレクトリは1つ、index.md は1つ、古い *take-home* ディレクトリがない	ページバンドルのディレクトリで ls を実行します。content/posts で重複するスラッグパターンを find で検索します。

親プロファイルが指定した編集変更

ゲート復旧中に親プロファイルが編集変更を指定した場合は、全基準のスキャンに進む前に、各変更が反映されていることを確認します。

変更の種類	確認方法
捏造された例示用の数値を削除	search_files で \d+%、percent、PRs? per、average of を検索し、ヒットがゼロであることを確認します
時制の修正	親プロファイルで指定された正確なフレーズを search_files で検索します
締めくくりの差し替え	親プロファイルで指定された締めくくりの最初と最後の文を search_files で検索します

判定ルール

• PASS： 12項目すべてを満たしています。00-index.md、01-summary/verdict.md、02-analysis/per-criteria-results.mdを作成します。
• BLOCK： いずれかの項目を満たしていません。具体的な修正手順を記載したgap-details.mdを作成します。修正パターンについてはverifier-gate-recoveryスキルを参照してください。

出力構成

/private/tmp/verifier-gate/<slug>-refine/
  00-index.md              — verdict, links to artifacts
  01-summary/verdict.md    — per-criterion pass/fail table
  02-analysis/
    per-criteria-results.md  — detailed evidence per criterion
    gap-details.md           — only if BLOCK, with remediation instructions

ポータビリティ

このスキルは、特定のホストに依存しないよう設計されています。ここに記載されている参照資料、テンプレート、スクリプトは、エージェントの通常の方法で読み込んでください。特定のプロファイルシステム、タスクオーケストレーター、メモリーサービス、応答引き継ぎ形式を前提としないでください。