build-evidence-map

根拠マップの作成

議論の分かれる問いを、現在の立場を裏付けるもの、反対するもの、そして不明なままのものを示す、持ち運び可能な意思決定資料に変換します。 出典を確認していない回答に、飾りとしてグラフを使わないでください。

単純な事実に関する主張や一般的なファクトチェックの依頼には、代わりに doublecheck などの検証ワークフローを使用してください。 証拠、中間的な主張、トレードオフ、不足している事実の関係が重要な場合に、このスキルを使用してください。

ワークフロー

1. 意思決定の対象を1つに定めます。 反証可能な問いを1つと、暫定的な立場を1つ記述します。読者が、マップで検証する行動や信念を特定できるまで、問いを絞り込みます。

2. 範囲を限定して出典を収集します。 直接観察と一次資料を優先します。URL またはローカルの絶対パス、発行元、公開日、取得日、セクション／ページ／行／タイムスタンプの位置情報、そして短く検証可能な抜粋を記録します。出典の質に異論がある場合は、references/evidence-ladder.md を読んでください。

3. 推論を要素に分解します。 次の4種類のノードのみを作成します。

   • position：現在の単一の判定。
   • claim：中間的な命題。
   • evidence：1つの出典範囲を忠実に記述したもの。
   • unknown：判定を変えうる、具体的に不足している事実。

4. すべてのエッジに種類を指定します。 supports、contradicts、qualifies、missing のいずれかを使用します。出典ノードが対象ノードに関係する理由を、平易な言葉で注記します。話題が似ているだけでは、裏付けになりません。範囲、日付、対象集団が異なるだけで、自動的に矛盾するわけではありません。

5. 反証となる証拠を残します。 暫定的な判定に影響しないからといって、反対する証拠を削除しないでください。範囲の違いは qualifies エッジで表現します。

6. 不確実性を構造で表現します。 確信度をパーセンテージで捏造しないでください。unknown を追加するか、立場の範囲を狭めるか、主張に条件を付けます。

7. UTF-8 の JSON を .doubt.json の拡張子で作成します。references/map-schema.md に従ってください。ID は短く、安定していて、意味が分かるものにします。

8. フェイルクローズで検証します。 SKILL.md を基準に scripts/validate.mjs の場所を解決し、Node.js 18 以降で実行します。

   node <skill-directory>/scripts/validate.mjs decision.doubt.json
   

   同梱のバリデーターは Node.js の組み込み機能のみを使用し、npm やネットワークアクセスを必要としません。成功を報告する前に、すべての指摘を修正してください。コマンドが 0 で終了し、64文字のレシートに続いて VALID と出力された場合に限り、マップが有効だと伝えてください。ファイルハッシュ、ノード数、JSON の解析、手動でのスキーマ確認は、Doubt のレシートではありません。決定論的な検証を実行できない場合は、成功を捏造せず、その障害を報告してください。

   ユーザーが [email protected] をすでにインストールしている場合に限り、検証済みのマップをレンダリングします。リモートパッケージを暗黙にインストールまたは実行しないでください。

   doubt map decision.doubt.json --out decision.html
   

9. 明示的なネットワーク許可がある場合に限り、出典のスナップショットを検証します。 次のコマンドは、記録された各 HTTP(S) 出典を取得し、抜粋が一致しない場合はフェイルクローズします。

   doubt verify decision.doubt.json \
     --out decision.verified.doubt.json
   

   このコマンドを暗黙に実行しないでください。ローカルファイルの検証にネットワークは使用しません。verification オブジェクトを手書きで作成したり、一致しない状態を隠したりしないでください。

10. 成果物を確認します。 問い、判定、反証となる証拠、不明点、エッジの注記、正確な出典範囲が読みやすい状態で保たれていることを確認します。JSON は編集可能な正本として扱い、HTML は共有用の表示として扱います。

品質ゲート

完成したマップは、以下のすべてを満たす必要があります。

• incoming reasoning を持つ position はちょうど 1 つです。
• すべてのエビデンスノードに 1 つのソースが記載され、エッジに参加しています。
• すべてのソースが使用され、日付、範囲が限定されたロケーター、実質的な抜粋を含んでいます。
• position 以外のすべてのノードから position へ、有向パスがあります。
• 推論グラフに重複するエッジや有向サイクルがありません。
• ソース群に反証または限定的なエビデンスが含まれる場合、それが記載されています。
• 判断を変え得る各ギャップが、明示的な unknown ノードになっています。
• すべてのエッジノートで、支持、矛盾、限定、または欠如のいずれを示すかが説明されています。
• 結論の範囲がエビデンスを超えていません。

結果の提示

以下を報告してください。

• 現在の立場を 1 文で示すこと。
• 最も強い反証、または限定的なエビデンス。
• 最も重要な未解決の不明点。
• 正規の JSON と、レンダリング済み HTML がある場合はそのパス。
• 決定論的な検証と、明示的なソース検証を実施したかどうか。

構造的に有効なマップを、真実が証明されたものとして説明してはいけません。検証によって確認されるのは、追跡可能性とグラフの整合性です。ソースの質と推論の質については、引き続き人間によるレビューが必要です。