引用チェック(Cite Check)
完成または進行中の記事草稿に対する検証パスです。すべての典拠が存在するか確認し、すべての引用文を実際の情報源と逐語照合し、すべてのURLが解決可能か確認し、情報源のページ番号が復元可能な場合はピンサイトの妥当性をチェックします。決定論的スクリプトが抽出と相互参照解決をほぼゼロトークンで実行し、モデルエージェントが一意の情報源ごとにファンアウトして引用文/ピンサイトの検証を行い、重大な問題には必ず2回目のチェックを実施して、チェッカーアーティファクトがレポートに到達しないようにします。
legal-researchスキルの仕組み(check_cite.py、fetch_page.py、CourtListenerトークン、予算劣化ラダー)とそのハウスルール(オープンウェブのみ、記憶から検証しない、取得できない情報源は「未検証」と報告——決して想定しない)を再利用します。
チェックする内容: 各引用が主張された情報源に解決されること、見出し/著者/タイトルのスペルが正しいこと、判例集/巻号/最初のページ/裁判所/年が正しいこと、引用文が逐語的または正直にマークされていること、supra/id. 相互参照が整合していること、URLが有効であること。
カバレッジ台帳(2026-09-06追加)——そしてまだチェックされていないもの。 引用文検証ユニットは引用文から構築されます。それ自体では、引用されていない二次情報源はすべて未対応のまま残ります。現在、scripts/citation_ledger.pyが各脚注内のすべての引用インスタンス(判例または二次情報源、引用文の有無、Id./supra/短縮形式の連鎖を解決したもの)をインベントリ化し、二次情報源の存在確認パスが引用されていない記事/書籍/法令/URLをカバーし、レポートのセクションHで各インスタンスに区分(verified、finding、existence-only、unverifiable、unchecked、xref、unresolved-xref)を割り当て、未チェックのものを脚注ごとにリストアップします。2つの制限が残り、レポートはそれを明記しなければなりません:(1) 命題の裏付け——引用されていない引用が、それが依存する文を実際に支持しているかどうかは評価されません(これがexistence-onlyの意味です)。(2) ピンサイトは引用文が固定している場合にのみチェックされます。existence-onlyは「実際の情報源、未読」として扱い、決して「合格」として扱ってはいけません。
さらに明白なFORM問題(スコープロックはユーザーによって解除されました、2026-08-10——「明白なものをチェックするのを妨げている限りロックを解除して」)。 Formフェーズは、草稿のみから判断可能で、情報源を参照しないものを報告します:
- 短縮形式——ブルーブックR.10.9の5脚注ウィンドウ内で完全引用が繰り返され、短縮形式が属する場合;判例の短縮形式がそのウィンドウを超えて孤立している、または前に完全引用がどこにもない場合;二次情報源がR.4.2が
Author, supra note Nを要求するときに完全に2回引用されている場合。 - タイプフェイス(
.docxのみ)——シグナル /Id./supra/quotingがローマン体のまま、イタリック体のsupraの後のnote Nが誤ってイタリック体になっている、引用の前のコンマにイタリック体がこぼれている、単語の途中でスモールキャップスが壊れている、およびR.2.1(a)の下でのケース名のイタリック化(引用句に立っている完全引用ではローマン体、テキスト文または短縮形式ではイタリック体——パターンでは区別できないため、エージェントが必要な唯一の呼び出し)。
これらは${CLAUDE_PLUGIN_ROOT}/skills/legal-research/citeform.pyから実行されます。これは**/proofreadが使用するのと同じモジュール**であり、2つのスキルが矛盾するアドバイスを与えることはありません。適用されるルールは${CLAUDE_PLUGIN_ROOT}/skills/legal-research/bluebook-typeface-and-short-forms.mdに明記されています。形式に関する発見事項はレポートの最後の近くに独自のセクションを持ち、「要注意」に入ることはありません——これらは整理整頓であり、実質的なものではありません。
まだそうではないもの: 完全なブルーブックリンター(シグナル順序、引用順序、引用が正しく構成されているかは対象外)、実質的な編集者、またはジャーナルの引用チェックの代わり。/proofreadとの分担は他のすべてで変わらず:proofreadは散文を読み、cite-checkは典拠を検証する——たまたま引用形式レイヤーを共有しているだけです。
実行方法
1. リクエストを解析する
- draftPath — 草稿へのパス(必須)。実際のWord脚付きの
.docxが標準です。.md/.txtでpandocスタイル[^n]の脚注がある場合はフォールバックとして機能します。 - footnotes — オプションの部分パス(例:「脚注45–80」またはリスト)。デフォルト:草稿全体。
- deep — オプション。より重い検証(中程度の労力の検証エージェント、高いソフトキャップ)。最終草稿に近い場合、またはユーザーが「深く」「徹底的に」と言った場合にオンにします。
- 草稿に変更履歴がある場合は、その旨を伝え、チェック前にすべて承諾するかどうかを尋ねます(パーサーは現在の/承諾されたテキストを読み、追跡された削除をスキップしますが、変更履歴が多くマークされた草稿は事前警告に値します)。
1b. どの程度深く行うかを尋ねる(著者の判断、2026-08-09 — /proofread ステップ1bを反映)
リクエストがすでに決めていない限り、事前に尋ねる — 1つの AskUserQuestion、ヘッダー Depth、プレフライトの前に。変更履歴の事前警告(ステップ1)を該当する場合に同じ呼び出しに組み込み、ユーザーが2回停止されるのではなく、1つのインタラクションですべてに回答できるようにします。
尋ねるのをスキップする 表現がすでに階層を選択している場合(「深く」「徹底的に」「最終草稿に近い」「提出前」「簡単」「標準」)、このセッションですでに選択された階層の部分再実行の場合、またはユーザーが狭い脚注範囲のみを要求した場合。
2つのオプション — cite-checkにはfableエスカレーションがないため、ラダーはproofreadよりも短いです:
| オプション | 引数 | 説明内容 |
|---|---|---|
| 標準 | deep:false | 低労力の検証エージェント、ソフトキャップ650k。進行中の草稿に適しています。 |
| 詳細 | deep:true | 中程度の労力の検証エージェント、ソフトキャップ900k。各引用文を情報源に対してより詳細に読みます——最終草稿に近いものに。 |
ここで/proofreadの論拠を再利用しないでください — 2つのdeepは異なるメカニズムです。
Proofreadのdeepは2回目のオフセット抽出パスを追加します(リコールプレイであり、約75〜80%の同一モデル重複発見に基づきます)。Cite-checkのdeepはパスを追加したり、何かを再取得したりしません:検証エージェントの労力をlowからmediumに引き上げ(ワークフロー行557)、ソフトキャップを引き上げます。引用文あたりの注意深さを購入し、より多くの引用文を購入するわけではありません。引用文のカバレッジはどちらの方法でも同じです — すべての引用文が両方の階層でチェックされるため、Standardが何かをスキップするとは暗示しないでください。
タイミングはproofreadほど重要ではありません(deepは抽出を変更しないため、後の再実行でresumeFromRunIdを介してキャッシュからセグメント/存在を再生できます)が、検証が実行の大部分を占めます — National Muffler草稿では33エージェント中26 — そのため階層の変更は依然として高価な段階の再実行を意味します。最初に尋ねてください。
2. プレフライト(これを起動前に行ってください — 実行中の許可プロンプトはエージェントを強制終了させる可能性があります)
~/.claude/settings.jsonを読み、permissions.allowに"WebFetch"と"WebSearch"が含まれていることを確認します(不足しているものをマージ — 配列を置き換えないでください)。ルーチン設定。プロンプトを表示しないでください。- CourtListenerトークンが機能することを確認します。テストしてください。ファイルを探しに行かないでください —
python3 ${CLAUDE_PLUGIN_ROOT}/skills/legal-research/check_cite.py "347 U.S. 483"を実行します。終了コード0で"found": trueなら、機能しており報告すべきことはありません。check_cite.pyはCOURTLISTENER_API_TOKEN、次にCOURTLISTENER_TOKEN、次にファイル~/.config/courtlistener/tokenからトークンを解決します — この順序で、環境変数ルート(通常は~/.claude/settings.jsonのenvブロックで設定される)が通常のインストール方法であるため、~/.config/courtlistener/ディレクトリがないことは何も証明しません。プローブが実際に失敗した場合でも実行は機能します(判例の存在確認はウェブにフォールバックします)が、配信時に一度だけ言及してください。トークンページ:https://www.courtlistener.com/profile/api-token/ - プロジェクトのZoteroライブラリを解決します(プロジェクトによって異なります — 共同執筆のグループライブラリもあれば、個人の個人ライブラリもあります):
a. プロジェクトフォルダの
CLAUDE.md(またはAGENTS.md)でZotero library:行を探します。存在する場合は、その名前のMCPサーバーを使用し、(c)にスキップします。 b. 存在しない場合は、ユーザーにこのプロジェクトがどのZoteroライブラリを使用するか尋ねます(個人ライブラリ、または名前付きグループライブラリ)、その後、回答をプロジェクトフォルダのCLAUDE.mdにZotero library: <名前> → MCPサーバー <サーバー>行として記録し、将来の実行で再尋ねしないようにします。 c. そのMCPサーバーが実際に存在することを確認します(個人 =zotero;グループライブラリは独自のサーバーを持ちます。例:zotero-group("5A general law")、グループIDは~/.claude.json内)。プロジェクトのライブラリにまだサーバーがない場合、これが追加を申し出る瞬間です:~/.claude.jsonのzoteroエントリをzotero-<スラッグ>の下にZOTERO_LIBRARY_TYPE=groupとグループのZOTERO_LIBRARY_ID(zotero.orgのグループURLまたは草稿のフィールドコードから見つけます)で複製します。Claude Codeの再起動が必要なことに注意してください。そのため、エージェントは今回の実行ではウェブにフォールバックします。 d. サーバー名をzoteroServerとして渡します(今回の実行で使用可能なZoteroサーバーがない場合はzotero:false)。
2b. 草稿のスナップショットを取る(常に)
ライブのOneDrive/Word共同編集ファイルは、抽出と配信の間で変更される可能性があり、その場合レポートはチェックされなかったバイトを説明することになります。草稿を一度コピーし、コピーを書き込み禁止にし、ハッシュし、スナップショットから下流のすべてを実行します。元のパスはここでのみ使用され、他の場所では使用されません — ワークフロー引数やエージェントプロンプトでは決して使用しません。
cp "<draftPath>" "<scratch>/snapshot.docx" && chmod a-w "<scratch>/snapshot.docx"
shasum -a 256 "<scratch>/snapshot.docx" # これを記録。レポートフッターに入ります。
3. 抽出と準備(決定論的スクリプト — これらを自分で実行。ほぼゼロトークン)
中間JSONをワークフローのエージェントが読み取れる場所(セッションスクラッチパッドで問題ありません)に配置します。インストールされたスクリプトパスを使用して、任意のフォルダから機能するようにします(draftNameは元のファイル名のまま。「snapshot」ではありません):
python3 ${CLAUDE_PLUGIN_ROOT}/skills/cite-check/scripts/extract_cites.py "<scratch>/snapshot.docx" "<scratch>/extract.json"
python3 ${CLAUDE_PLUGIN_ROOT}/skills/cite-check/scripts/prepare_units.py "<scratch>/extract.json" "<scratch>/units.json"
python3 ${CLAUDE_PLUGIN_ROOT}/skills/cite-check/scripts/citation_ledger.py "<scratch>/extract.json" "<scratch>/ledger.json"
python3 ${CLAUDE_PLUGIN_ROOT}/skills/cite-check/scripts/citation_ledger.py "<scratch>/extract.json" --compact > "<scratch>/ledger_args.json"
citation_ledger.pyは instance_count / by_kind / unique_secondary_cites / unresolved_xrefs を出力します。by_kindをざっと見ます:otherまたはtextのカウントが大きい場合、脚注がスプリッターが認識しない引用形式を使用していることを意味します — それらのインスタンスは依然として台帳に出荷されます(unchecked/not-a-citationとして)。そのためレポートは正直なままですが、配信時にその旨を伝えます。--compactファイルはワークフローが受け取る2つの配列(instances、secondary)を保持します。
extract_cites.pyは要約を出力します(footnote_count、本文/脚注の引用文カウント、unique_case_cite_count、supra_problem_candidates、さらに形式レイヤーからのform_findings/form_short_form/form_typeface/formatting_available/case_name_candidates)。prepare_units.pyはunit_count / case_cites / supra_problemsを出力します。extract.jsonを読み取り、ワークフローが必要な配列を取得します:unique_case_cites、supra_problem_candidates、およびform_checksブロック全体。
formatting_available: falseはマークダウン/プレーンテキストの草稿を意味します — 短縮形式は依然として実行されますが、タイプフェイスは実行されません。配信時にその旨を伝えます。formatting_unaligned_footnotesが表示される場合、その数の脚注はタイプフェイス分析を受けていません(フォーマットされたテキストが検証済みパーサーのテキストと一致しなかったため、レイヤーがミスアライメントオフセットのリスクを冒さずに辞退しました) — カウントが重要でない場合のみ言及します。
部分パスの場合、脚注範囲をユニットIDに解決します:
python3 ${CLAUDE_PLUGIN_ROOT}/skills/cite-check/scripts/prepare_units.py "<scratch>/extract.json" --footnotes 45-80
(unit_idsを出力します — それらをunitIdsとして渡します)。
4. ワークフローを起動する
Workflow({
scriptPath: "${CLAUDE_PLUGIN_ROOT}/skills/cite-check/cite-check.workflow.js",
args: {
skillsDir: "${CLAUDE_PLUGIN_ROOT}/skills", // バンドルされたヘルパースクリプトの場所
extractPath: "<scratch>/extract.json", // エージェントがユニット+完全なコンテキストをここから読み取る
draftName: "<拡張子なしの草稿ファイル名>",
footnoteCount: <extract.footnote_count>,
unitCount: <prepare.unit_count>,
caseCites: <extract.unique_case_cites>, // 配列
supraProblems: <extract.supra_problem_candidates>, // 配列
formChecks: <extract.form_checks>, // タイプフェイス + 短縮形式(ブロック全体)
ledger: <ledger_args.instances>, // すべての引用インスタンス(コンパクト形式)
secondaryCites:<ledger_args.secondary>, // 引用されていない一意の二次情報源
unitIds: <null | [--footnotesからのID]>、 // 部分パスのみ
deep: false,
zotero: true, // 今回の実行で使用可能なZoteroサーバーがない場合はfalse
zoteroServer: "<プレフライト2.3からの値>" // 例:「zotero-group」(5A)または「zotero」(個人)
}
})
パイプライン(すべてのモデル段階はSonnet。レポートのみがセッションモデルを継承します):
- セグメント化/解決 — チャンク化。各引用文は、それが依存する特定の情報源とペアリングされ、
Id.連鎖を実際の先行詞(2つ前の注にある判例の場合もある)まで辿り、supra note Nリダイレクトを追跡します。
...