mcpField
L
light-citation

light-citation

github.com/light0305ドキュメント81457 回インストール16 週間前に更新
リポジトリ

light-citation について

light-citation は Light 研究ワークフロー第 10 段階の引用検証スキルです。論文の著者向けに、文献の実在性、同定、出版状況、個別の主張を支える根拠を確認し、追跡可能なレジストリと納品用ファイルを作成します。

主な機能

  1. 01本文・図表・補足資料の引用を一覧化
  2. 02独立した情報源で文献の同定とメタデータを検証
  3. 03撤回や訂正など出版後の更新を確認
  4. 04原文とロケーターに基づき主張の裏付けを審査
  5. 05引用レジストリ、BibTeX、CSL JSON、監査結果を生成

活用シーン

  1. 01投稿前に引用と主張の裏付けを確認
  2. 02欠落・誤記・混成の疑いがある文献を調査
  3. 03参考文献ファイルを整え LaTeX の citekey を監査

インストール

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

$npx skills add https://github.com/light0305/light-skills --skill light-citation

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

同梱ファイル

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

citation-resource-map.md
references.md
assets/
citation_checklist.md
references/
locator_audit.md
registry_contract.md
scripts/
citation_four_gate.py
citation_registry.py
citation_verify_gate.py
citekey_audit.py
doi_to_any.py
verify_citation_edge.py
verify_refs.py
templates/
citation_input.json
citation-four-gate.example.json
claim_citation_review.json

詳細

引用 — ステージ 10

著者が使用したすべての参考文献について、追跡可能で、実在し、正しく特定され、裏付けるはずの主張と誠実に結び付いていることを確認してください。書式、メタデータの存在、出版物のインテグリティに関する事実、意味上の裏付けは、別々の問題として扱ってください。

原稿全体を監査する前に、citation-resource-map.md を読んでください。正規レジストリを作成または使用する前に、references/registry_contract.md を読んでください。主張の裏付けを評価する前に、references/locator_audit.md を読んでください。

ステージの契約

  • paper-writing の light.paper_claims.v1、正確な主張/出典ロケーター、現在の主張テキストのハッシュ、査読者に紐付けられた引用裏付けのハッシュ、原稿、図表、補足資料、参考文献候補を受け取ります。
  • 文献検索の来歴を入力証拠として再利用し、著者が実際に採用した参考文献を独自に検証します。
  • light.citation_registry.v1、BibTeX、CSL JSON、出典レベルの証拠、失敗記録、主張と引用の関連性レビュー、citekey 監査、light.findings.v1(producer=citation) を出力します。
  • ステージ 10 で唯一のクリティカルゲートである citation_verify は、存在しないことが確認された文献とキメラ引用を対象とします。メタデータの不一致、出典の入手不可、主張との関連性、書式、出版後の更新に関するアラートは、警告またはスキップとして扱います。
  • 引用の問題はステージ 10 内で修正します。ROUTES にキー 10 はありません。逆方向のルートを作り出してはいけません。
  • references.bib、citekey-audit.json、レジストリ、delivery.json を組版工程に渡します。組版工程ではキーをコンパイルして確認しますが、真正性の判断をやり直すことはありません。delivery.json には status と、納品物ごとの sha256: ハッシュを記載し、組版工程で古い、または編集された引き渡し物を拒否できるようにしてください。

絶対に守るべきルール

  1. 参考文献、DOI、著者名、年、掲載先、citekey、ロケーター、裏付け判定を決して捏造しないでください。
  2. ネットワーク障害、レート制限、5xx、認証失敗、インデックス検索漏れを「この文献は存在しない」と決して判断しないでください。
  3. DOI 登録機関が不存在を明示し、Crossref と DataCite の両方が 404/410 を返した場合に限り、CONFIRMED-MISSING を割り当ててください。
  4. 登録メタデータと少なくとも 1 つの独立したフィールド情報源がその文献の存在を確認した場合に限り、CONFIRMED を割り当ててください。それ以外の場合は UNAVAILABLE または UNRESOLVED のままにしてください。
  5. 各情報源のタイトル、著者、年、掲載先、識別子の値をすべて保持してください。正規フィールドは登録機関から選択し、ファジーマッチングで元の引用を上書きしないでください。
  6. 実在する DOI に、異なるタイトル、著者、年が組み合わされている場合は、キメラ引用の可能性があるものとして扱ってください。主要フィールドが複数一致しない場合はクリティカルとし、1 つのフィールドに曖昧な不一致がある場合は、手動レビュー対象の警告としてください。
  7. 出版物の更新は、正しい方向で記録してください。影響を受けた元の文献には Crossref の updated-by が付き、通知には逆方向の update-to が付きます。
  8. 撤回、訂正、懸念表明に関する事実とアラートを記録したうえで、インテグリティの判断と文言は research-ethics に引き継いでください。その倫理ゲートを再構築しないでください。
  9. メタデータの確認や「A が B を引用している」という事実を、「B が主張 C を裏付ける」と同一視しないでください。SUPPORTS には、ロケーターに基づく意味上のレビューが必要です。
  10. 中核となる処理経路はローカル/無料、または公開/キー不要にしてください。OpenAlex とキーを使用する Semantic Scholar は、カバレッジを高めるための任意の手段です。有料の文献管理ツール、機関データベース、ブラウザープラグインは必須にしてはいけません。

著者のワークフローを実行する

1. すべての参考文献の出現箇所を一覧化する

主張マップ、原稿、図表、補足資料をまとめて使用してください。

python scripts/citation_registry.py \
  --claim-map claim_plan.json \
  --draft paper.tex \
  --figure figure_notes.md \
  --supplement supplement.md \
  --refs-spec citation_input.json \
  --out-dir citation-delivery

claim_id、正確な主張、主張ロケーター、成果物のパス、出現箇所のロケーター、citekey、未加工の識別子を保持してください。プロジェクトに参考文献の仕様がない場合は、templates/citation_input.json を使用してください。

2. バージョンを消去せずに正規化する

DOI、arXiv、PMID、ISBN、URLを正規化します。完全に一致する著作物は重複排除します。入力から関連性を確認できる場合に限り、arXiv、受理済み原稿、バージョン付きデータセット、出版済み DOI を、1つの著作物の明示的なバージョンとして保持します。関連性を確認できない場合は別々に保持し、関連性未解決と記録します。

3. 独立したソースで検証する
python scripts/verify_refs.py \
  --spec citation_input.json \
  --self-author Smith \
  --out verify.json

登録ソースとして Crossref または DataCite を使用します。独立した分野別ソースとして PubMed、Semantic Scholar、または設定済みの OpenAlex を使用します。各エンドポイント、HTTP ステータス、結果、タイムスタンプ、返されたフィールドをsource_evidenceに保持し、判定に実際に使用した正規化フィールドの SHA-256 も保存します。Crossref polite-pool のメールアドレス、OpenAlex/Semantic Scholar のキーはリクエストにのみ使用し、エンドポイント、レジストリ、ログには絶対に書き込みません。

ステータスは次のとおり正確に解釈します。

ステータス意味対応
CONFIRMED登録ソースと独立した分野別ソースの両方で確認済み正式な BibTeX/CSL に使用可能
CONFIRMED-MISSINGDOI RA が明示的に不存在を示し、Crossref/DataCite が 404重大。置き換えるか削除
UNAVAILABLE通信、レート制限、認証、5xx により検索できない再試行するか、別の無料ソースを使用
UNRESOLVED証拠が不完全、または2つ目のソースが不完全調査する。検証済みとは呼ばない
4. フィールドの競合とキメラを解決する

著者が引用したタイトル、著者、年を登録メタデータと比較します。field_conflictsをソースごとに確認します。人間が競合を解決するまで、ユーザーの生の引用は変更せずに保持します。

次の場合は、重大なキメラとして扱います。

  • 実在する識別子があり、タイトル、著者、年のうち少なくとも2つに競合がある。
  • タイトルは一致するものの、引用された著者リストに登録された著作物には存在しない著者が追加されている。

単一のタイトル翻訳、副題、オンライン公開年と印刷版公開年の違い、著者の省略、または著者順の問題は、裏付けとなる証拠によってキメラであることが確認されない限り、メタデータ警告として扱います。

5. 出版物の更新を記録する

publication_updatesを確認します。アラートが重要な場合は、該当する著作物と通知の DOI の両方で関連の方向を確認します。種類、通知 DOI、ソース、方向を記録します。これらの情報を研究倫理部門に伝えます。update-toがあることを理由に、訂正通知自体を撤回済みと判断してはいけません。

6. 主張↔引用の裏付けを監査する

以下を使用します。 templates/claim_citation_review.json および原文全文:

  • supports:引用された箇所が、記載どおりの主張を裏付けています。
  • partial:より限定的な記述のみが裏付けられています。
  • related_only:同じトピックですが、この命題の根拠ではありません。
  • unsupported:情報源が主張と矛盾するか、裏付けていません。
  • review_required:全文、箇所、またはレビュー担当者が不足しています。

各レビューには、access、実在するプレースホルダーではないsource_locator、 source_evidence_sha256、reviewer、すでに経過した日時を示すISO形式のreviewed_at、 およびレビュー対象となった正確な主張テキストのreviewed_claim_sha256を記録する必要があります。レジストリは現在のclaim_text_sha256も出力します。この2つのハッシュが一致しない場合、レビューは古くなっているため、REVIEW_REQUIREDに格下げされます。これらのフィールドがない場合、reviewed_atが未来の場合、テンプレート形式、絶対パス、またはルート外へ抜けるロケーターの場合、あるいは主張のハッシュが一致しない場合、SUPPORTSはレジストリ/ゲートによってREVIEW_REQUIREDに格下げされます。メタデータのみへのアクセスで主張を裏付けることはできません。アクセスがABSTRACT_ONLYのみの場合、SUPPORTSにはsupport_scope=ABSTRACT_EXPLICITまたはabstract_claim_explicit=trueも必要です。そうでない場合、レジストリ/ゲートによってREVIEW_REQUIREDに格下げされます。方向、母集団、介入、比較対象、指標、時間、モダリティ、因果関係の強さ、範囲を確認してください。関連のみ、または裏付けなしの場合は、主張または引用を変更してください。抄録レベルのヒューリスティックを最終的な裏付けとして扱わないでください。

納品前に、4つのゲートを明示的に正規化します。

python scripts/citation_four_gate.py \
  --registry citation-delivery/citation-registry.json --as-of 2026-07-05
# 或仅调试模板合约:
python scripts/citation_four_gate.py \
  --input templates/citation-four-gate.example.json --as-of 2026-07-05

公開テンプレートは意図的にUNKNOWNとなっており、終了コード1で終了する必要があります。後続のゲートが先行する失敗を修復することはできません。順序は、存在確認 → 同一性確認 → 公表状況の方向性確認 → ロケーターに基づく主張の裏付けです。手動でコピーしたテンプレートではなく、正規レジストリから4ゲートの記録を生成するため、--registryを優先してください。ABSTRACT_ONLYの場合、申告された主張が抄録に明示的に記載されている場合に限り、直接的な裏付けとできます。メタデータのみでは主張を裏付けられません。撤回された研究は過去の記録を示す資料にはできますが、現在の結論を暗黙に裏付けることはできません。

7. 納品物を生成して監査する

入力が揃ったら、オンラインでレジストリを実行します。

python scripts/citation_registry.py \
  --claim-map claim_plan.json --draft paper.tex \
  --refs-spec citation_input.json --online \
  --out-dir citation-delivery

python scripts/citekey_audit.py \
  --tex paper.tex --bib citation-delivery/references.bib --json

確認済みで、キメラではない研究のみが、生成されたBibTeX/CSLに含まれます。すべての失敗と未解決のレビューは、別のアーティファクトに保持してください。生成されたdelivery.jsonは、citation-failures.jsonとclaim-citation-review.jsonが空で、citekey監査がOKの場合にのみDELIVEREDになります。それ以外の場合は、ERRORまたはREVIEW_REQUIREDを示します。doi_to_any.pyは、単発のDOIコンテンツネゴシエーションとフォーマット出力に使用し、意味的な裏付けの証明には使用しないでください。

8. ゲートを実行してチェックポイントを確定する
python scripts/citation_verify_gate.py \
  --registry citation-delivery/citation-registry.json \
  --tex paper.tex --bib citation-delivery/references.bib \
  --report citation_findings.json

python ../light-orchestrator/scripts/run_checkpoint.py \
  --file .light/passport.yaml --stage 10 \
  --findings citation_findings.json --write --ts <ISO-8601>

重大な問題が見つかった場合、citation_verify_gate.pyは終了コード1を返します。レジストリの根本原因を修正し、すべての派生アーティファクトを再構築してから、ゲートを再実行し、同じステージ10チェックポイントを再実行してください。チェックポイントに合格し、passportにdeliveredが記録された後にのみ納品してください。

スクリプト一覧

スクリプト役割
citation_registry.pyインベントリ、正規化、バージョンのグループ化、検証のオーケストレーション、主張エッジ、レジストリ/BibTeX/CSL/証拠/失敗/納品
verify_refs.py複数ソースに基づく正式なフィールド、誠実なステータスマシン、ソース証拠、矛盾、キメラ、Crossrefの更新方向
citation_verify_gate.pyステージ10の検出結果を生成。確認済みの欠落/キメラがある場合は終了コード1
citekey_audit.py原稿↔.bibのキー監査。組版でも再利用
doi_to_any.pyDOIコンテンツネゴシエーションと引用形式での出力
verify_citation_edge.py論文A→Bのオープンインデックス上の関係。主張の裏付けには使用しない
citation_four_gate.py撤回に関する目的別の処理を含む、存在/同一性/更新/裏付けの順序付き契約。light.citation_registry.v1から直接レコードを導出可能

リソースの境界

  • citation-resource-map.md:実行順序とリソースの階層。
  • references/registry_contract.md:機械可読成果物のセマンティクス。
  • references/locator_audit.md:人間による意味的裏付けの確認プロトコル。
  • references.md:API/スタイル/文献管理ツールの詳細。該当するセクションのみ読み込んでください。
  • templates/*:作成者の入力内容とレビューの契約。
  • assets/citation_checklist.md:人間が使用する最終チェックリスト。
  • docs/competitors/citation.md:R1 のエビデンスと比較に関する主張。実行ガイドではありません。

完了確認

  • インベントリに、存在する場合は主張マップ、原稿、図表、補足資料、参考文献仕様の出典情報が含まれています。
  • DOI/arXiv/PMID/ISBN/URL が正規化され、バージョンは確認できる状態になっています。
  • 確認済みの各文献に、登録情報と独立した出典エビデンスがあります。
  • 入手不能または未解決の各出典に、実態に即したラベルが付いています。
  • 確認済みの欠落文献や複数の文献が混在した文献は残っていません。
  • updated-by の方向は正しく、通知の向きも逆になっていません。
  • 中核となる主張の引用にはすべて、ロケーターに基づくレビューがあります。「関連のみ」を裏付けとして扱っていません。すべての SUPPORTS エッジに、出典エビデンスの SHA-256、レビュアー、未来の日付ではない reviewed_at、一致する claim_text_sha256/reviewed_claim_sha256、メタデータ以外のアクセスがあり、テンプレート/絶対パス/エスケープされたロケーターはありません。
  • 4 ゲートの順序に合格し、抄録/全文へのアクセスと、歴史的/直接的な目的が明示されています。
  • 4 ゲートへの入力には --registry を使用しています。ただし、手書きのフィクスチャを使う文書化された理由がある場合を除きます。
  • レジストリ、BibTeX、CSL、エビデンス、失敗情報、主張レビュー、引用キー監査は、1 つの正規状態から生成されています。
  • delivery.json に、組版で使用するすべての納品物のステータスと sha256: ハッシュが記録されています。
  • 引用ゲートとステージ 10 のチェックポイントに合格しています。
  • 組版では、納品された BibTeX/引用キーを使用しています。

コメント