deeppapernote

DeepPaperNote

以下のような成果を1つ求められた場合は、このスキルを使用します。

• 論文を1本、丁寧に読む
• 質の高い Markdown ノートを生成する
• 解決済みの設定に基づいて選択されたワークスペースまたは Obsidian の保存先にノートを保存する

中国語のトリガー例：

• 给这篇论文生成深度笔记
• 写一篇高质量论文精读笔记
• 把这篇文章整理成 obsidian 笔记
• 读这篇论文并生成 md 笔记

英語のトリガー例：

• Generate a deep-reading note for this paper
• Turn this paper into an Obsidian research note

ユーザー設定

通常の論文処理を開始する前に、設定の受け入れ、移行、修復、実行時の上書き、設定の変更について、references/user-configuration.md を読みます。

実行時の上書きは、明示的な依頼、CLI、現在のプロセス環境から先に解決します。選択された保存モードに対して完全で有効な設定が揃っている場合は、ユーザー設定を読まなくても設定の準備が完了します。実行時の上書きにフォールバック値が必要な場合に限り、ユーザー設定を確認します。

言語整合性の契約

設定の準備が完了した後、この実行の output_language（zh-CN または en）を1つ決定します。source_manifest.language_hint はソーステキストについてのみ記述し、ノートのプロファイルは選択しません。

Save Target Admission → Figure Plan → Figure/Table Decisions → Synthesis Bundle → Note Plan → Grounding Lint → Final Note Lint → Final Quality Review → Final Readability Review → Formal Save の各段階を通じて、その値を厳密に維持します。

• この連鎖に含まれる各 JSON 成果物には、トップレベルの output_language を含めます。Synthesis Bundle には、同じ値を writing_contract.language にも含めます。
• 各段階では出力を生成する前に、すべての入力言語が解決済みの値と一致することを確認します。値がない場合、サポート対象外の場合、または一致しない場合は、処理を停止します。どの段階でも、成果物の言語を推測したり、既定値を適用したりしてはいけません。
• Final Quality Review と Final Readability Review には、解決済みの値をそれぞれ渡し、そのプロファイルだけを基準にノートを確認します。
• Final Note Lint では note_sha256 を記録します。レビューで編集が行われた場合、以前の Lint は無効になるため、同じ言語で Final Note Lint を再実行します。Formal Save では、Lint の言語と note_sha256 が最終ノートと一致することを必須とし、保存に影響する処理を行う前に Figure/Table Decisions の言語を検証します。

この契約が完全に成立するのは、指定されたすべての段階が解決済みの値に結び付けられ、Formal Save が最終バイト列を検証した場合に限ります。どちらの言語で下書きやデバッグを行う場合も、プロファイルの内容については references/output-language.md を読みます。

このスキルの対象範囲は意図的に限定されています。

• 正規の Skill は1つで、2つの出力プロファイルを持つパイプラインを1つ扱います
• 一度に処理する論文は1本です
• 日次の読書リストは更新しません
• 要旨を表面的に書き換えただけのものを、成果物の成功とはみなしません
• 公開エントリーポイントを、セットアップ、トラブルシューティング、開始用の個別コマンドに分割しません

基本基準

完成したノートは単なる要約にとどまらず、論文の論旨を再構成するものでなければなりません。

• どのような問題を解決するのか
• タスクをどのように定義しているのか
• どのようなデータや資料を使用しているのか
• 手法や分析が実際にどのように機能するのか
• 最も重要な結果は何か
• 論文が証明していないことは何か
• この論文を保存しておく価値がある理由は何か

既定の執筆者像：

• 一流の研究者またはアルゴリズムエンジニア
• 再現実験を重視するラボノートを執筆する
• 一般向けの科学解説は執筆しない
• 読者が Python、PyTorch、学習ループ、評価ロジックを理解できることを前提とする

論文の種類に応じてノートを調整します。基本構成は共通としつつ、AI 手法、ベンチマーク、臨床研究、人文科学または社会科学の論文に合わせて重点を変えます。

ワークフロー

次の順序に従ってください。

1. Configuration Readiness を完了します。まず Run Overrides を解決し、不完全な場合に限り User Configuration を確認します。解決済みの実行設定が完全かつ有効になってから次に進みます
2. 論文の識別情報を解決します
3. メタデータを収集します
4. 確定した識別情報と元のユーザー参照を使用して、利用可能な最良の PDF を取得します（fetch_pdf.py --reference）。Obsidian モードでは、ダウンロードする前に一致するローカルアーカイブがあるか確認し、再利用してください。バージョンとソースの選択については references/paper-archive.md に従います
5. 正規の未加工ソーステキストを抽出します：*_raw_sections.jsonl、*_source_manifest.json、および任意の派生ファイル *_full_text.md
6. 下書きの作成や分野の振り分けを行う前に、保存先の受け入れ確認を行います：
   • Obsidian モードでは、解決済みのタイトル、正確な output_language、Vault、および *_source_manifest.json を指定して scripts/write_obsidian_note.py --preflight を実行します。このプログラムの結果が正式な判定となるため、プロンプトだけによる重複確認で代用してはいけません
   • 再利用結果が返された場合は、そのディレクトリを使用し、分野の選択を省略します。PDF のみが確認済みのディレクトリでは、登録確認は不要です。preflight の asset_subdir を読み取り、ソースに紐づく図の埋め込みに使用します
   • same_language_note_exists が返された場合は、下書き作成の前に停止し、報告されたノートを上書きするかユーザーに確認します。ユーザーが承認した場合は、--overwrite-existing-note --expected-existing-note-sha256 <reported_sha256> を指定して preflight を再実行し、その確認内容を正確に Formal Save に引き継ぎます。ユーザーが拒否した場合は、書き込みを行わずに停止します
   • 複数のディレクトリまたはソースが一致する場合は、references/paper-archive.md に従います。現在使用するものをユーザーに確認し、その選択を preflight と Formal Save に引き継ぎます
   • それ以外の競合でブロックされた場合は、返された曖昧さを報告し、2 つ目のディレクトリを作成せずに停止します
   • workspace モードでは Obsidian Vault をスキャンせず、通常の分野振り分けを続けます
7. 構造インデックスと PDF アセットを抽出します
8. 図の配置を計画します
9. 図表の判断表を完成させます
10. マニフェスト統合バンドルを作成します
11. モデルにバンドルと未加工セクションを読み込ませ、正確な output_language を含む、生成されたバンドルの契約を満たす短い JSON note_plan を作成させます
12. グラウンディングゲートを通過してから、計画に基づいて下書きを作成します
13. モデルにノートを書かせます
14. 同じ note_plan に照らして最終ノートを lint します。lint 成果物が存在し、報告されたすべての passes_* ゲートが true になるまで、この段階は完了しません。そうでない場合は修正して lint を再実行します。lint 出力に passes_style_gate: false が含まれる場合は、ステップ 15、16、または 17 に進む前に Style Gate Enforcement ルールを適用します
15. lint 通過後に final_quality_review を実施します
16. 品質レビュー通過後に final_readability_review を実施します
17. 同じ Source Manifest とユーザーが承認した上書きハッシュを使用して、scripts/write_obsidian_note.py で受け入れ済みの保存先に Formal Save を実施します。スクリプトは最初の保存処理を行う前に受け入れ確認を再実行します

これは通常の単一論文ノート作成依頼に必要なワークフローであり、緩やかな提案ではありません。 このスキルで明示的に任意とされている段階を除き、必須段階を黙って省略したり、近道のために順序を入れ替えたり、部分的な成果物がすでに存在するというだけで完了扱いにしたりしてはいけません。

全体的なショートカット禁止ルール：

• 初期段階だけで停止し、ワークフローが完了したかのように提示してはいけません
• 時間がかかること、不便であること、一時的に不確かであることを、必須段階を省略する理由にしてはいけません
• 明示されたワークフローを独自の近道に置き換えてはいけません
• 必須段階が失敗した場合に取れる対応は、次のいずれか 1 つだけです：
  • その段階を再試行する
  • このスキルで明示的に許可されているフォールバックを利用する
  • どの段階がブロックされているか、また後続の必須段階のうち何が未完了かを報告して停止する
• 後続の必須段階が残っている間、タスク全体が完了したと説明してはいけません 完了表現に関するルール:
• 笔记已完成 と言うのは、必要なワークフローが実際に完了したときだけにしてください
• 已生成草稿 と言うのは、下書きが完了していても lint、最終可読性レビュー、または保存がまだ保留中のときです
• 已通过校验 と言うのは、lint が実際に実行されて合格したときだけにしてください
• 已保存到 Obsidian と言うのは、書き込みステップが実際に成功したときだけにしてください
• lint 已通过 を 整篇笔记已经润色完成 と同等に扱わないでください
• 最終可読性レビューがまだ保留中の場合、下書きがスクリプト lint に合格したものの最終的な言語レビューが完了していないことを明示してください
• ワークフローが途中で停止した場合は、完了表現を使わずに、現在の段階とまだ不足している必須段階を明示してください
• lint は下限であり、執筆の目的ではありません

最終ユーザーレポート:

• 上記で定義された完了表現を維持してください。Formal Save が成功した後、ユーザーの会話言語で報告してください。
• 最終ノートのリンクまたはパス、保存モード、および実際に保存されたドメインを先頭に記載してください。ドメインは、Obsidian モードでは設定された papers ルート配下、ワークスペースモードでは output ルート配下の最終ノートパスから読み取ってください。Save Target Admission が既存のディレクトリを再利用した場合は、そのディレクトリの既存ドメインを報告してください。
• 次に、以下の順序で報告してください:
  1. 論文タイトルと最も強力な検証済み識別子
  2. Grounding Lint、Final Note Lint、Final Quality Review、Final Readability Review の結果、および警告数
  3. 実体化された図表とプレースホルダーとして保持された図表の数
  4. 保存されたノートの SHA-256 が Final Note Lint の note_sha256 と一致するかどうか
• 上書き操作、設定変更、またはユーザーに関連する警告は、実際に発生した場合にのみ追加してください。
• レポートはこれらのフィールドに限定し、すべての主張を今回の実行の成果物から導き出してください。

コア実行契約

通常のノート生成を実行するには、SKILL.md と生成された synthesis_bundle.json があれば十分です。 references/ 配下のファイルは、ステージごとの詳細を確認するための任意資料であり、通常の参照リストではありません。

必須ルール：

• エビデンス優先：合成バンドル、source_manifest、raw セクション、カバレッジメタデータ、明示的な note_plan、および論文のエビデンスを確認したうえで下書きを作成します。タイトル／要旨／見出しだけを根拠に完成させてはいけません。
• raw ソースの優先：通常の PDF では、*_raw_sections.jsonl と *_source_manifest.json が正規の読解資料です。旧来の上位 N 件のエビデンスバケット、切り詰められた section_texts、candidate_chunks は、モデル向けの執筆入力ではありません。
• フェイルクローズ：対応している取得方法を試しても、利用可能な PDF または十分なエビデンスを得られない場合は、品質を落とした完成ノートを作成せず、より適切なソース資料を依頼して停止します。
• モデル優先：スクリプトはエビデンスを構造化しますが、強調点、貢献、仕組み、制約、および最終的な文章は、設定された言語でモデルが判断します。
• 必須の構成：writing_contract.must_include_sections で指定された順序で、ローカライズされた標準セクションを含めます。
• 要旨への忠実性：原文の要旨の意味を保ち、後から得たエビデンスやモデルの判断を加えてはいけません。zh-CN モードでは翻訳し、en モードでは英語で忠実に記述します。
• 仕組みの詳細：手法、フレームワーク、システムに関する論文では、ローカライズされた手法セクションの下に、ローカライズされた仕組みのフローを含めます。通常は、入力、処理、出力先を示す 3～4 ステップの番号付きフローにします。
• 図表はプレースホルダーを優先：まず主要な図表のプレースホルダーを計画します。識別の一致と視覚的な使用可能性の両方が十分に高い場合にのみ置き換え、それ以外の場合はプレースホルダーを残します。

参照資料の利用方針：

• すべての参照ファイルを最初から読み込まないでください。
• 論文が複雑な場合、または下書きの内容が浅すぎる場合に限り、references/evidence-first.md、references/deep-analysis.md、または references/final-writing.md を参照してください。
• 図表の配置や画像の置き換えについて判断が難しい場合に限り、references/figure-placement.md を参照してください。
• 既存の Obsidian ディレクトリ、ローカル PDF のバージョン選択、または Connector への引き継ぎについては、references/paper-archive.md を参照してください。
• Markdown、Vault、フロントマター、または参照リンクの書式の詳細を確認する場合に限り、references/obsidian-format.md を参照してください。
• 最終レビューまたは分野への適応を行う場合に限り、references/note-quality.md または references/paper-types.md を参照してください。
• メタデータが不完全な場合に限り、references/metadata-sources.md を参照してください。リポジトリの保守に関する判断に限り、references/architecture.md を参照してください。

ツールとソースの優先順位

利用可能なソースのうち、次の順で最も信頼性の高いものを優先します。

1. ユーザーが指定したローカル PDF パス
2. 利用可能な場合は、ローカルの Zotero アイテムとローカルの Zotero 添付ファイル
3. 承認済みの論文と要求されたバージョンに対応する、検証済みのローカル Obsidian PDF
4. DOI と出版社のメタデータ
5. arXiv またはオープンアクセスの PDF ソース
6. メタデータの補完には Semantic Scholar または OpenAlex

Web での解決を行う前に、同梱の scripts/resolve_paper.py の Zotero Local API パスを使用して、デスクトップライブラリを確認してください。デフォルトの --zotero-mode auto は、一意に一致するローカルの候補を優先し、Zotero が利用できない場合や一致する候補がない場合は既存のプロバイダーにフォールバックします。明示的に指定された Zotero キーには安全な Web フォールバックがないため、ローカルで検証する必要があります。Local API へのリクエストを行わない場合は off を使用し、参照先が Zotero 経由で解決される必要がある場合は required を使用してください。信頼できる JSON アーティファクトまたは明示的に指定されたローカル PDF がある場合は、これを正規の情報源として扱い、この検索を省略します。利用可能であれば、セッションの範囲内で互換性のある Zotero/MCP 統合から信頼できる入力アーティファクトを取得してもかまいませんが、組み込みのパスでは必須ではありません。

ローカルライブラリ優先のルール：

• 論文タイトル、DOI、arXiv ID、または Zotero アイテムの正確なキーを使用して、まずローカルの Zotero ライブラリを検索します。
• Zotero で論文が見つかった場合、その結果を正規の識別解決ステップとして扱います。
• 組み込みの Local API が返す、安全なローカル添付ファイルのパスを優先します。別の互換性のある統合から添付ファイルのキーとファイル名しか取得できない場合は、scripts/locate_zotero_attachment.py を使用して、ユーザーの Zotero ストレージ内で PDF を探します。
• ローカルの添付ファイルのパスを取得できた場合は、優先する PDF ソースとして引き継ぎます。
• ローカルの添付ファイルが見つからない場合でも、ライブラリで解決されたメタデータを使用してタイトルの曖昧さを避け、その後、ファイル自体の取得に限ってネットワーク上の PDF にフォールバックします。
• 複数のローカルアイテムが同程度に有力な候補である場合は、いずれかを恣意的に選ばず、DOI、arXiv ID、または Zotero アイテムの正確なキーを指定するよう求めます。
• タイトルだけが一致する信頼性の低いインターネット上の候補で、ローカルライブラリ内の確度の高い一致を上書きしてはいけません。

出力ルール

正式保存の状態：

保存先の状態	必須の操作
save_mode=obsidian で、設定済みの Vault が使用可能	その Vault に正式保存します。
save_mode=obsidian で、正式保存に失敗	現在の保存先を維持し、対象範囲内での復旧を試みます。それでも完了できない場合は blocked と報告し、workspace に切り替えてはいけません。
save_mode=workspace	現在のワークスペースの出力ルート内に正式保存します。

• 通常のノート生成リクエストは、ノート本文、図のプレースホルダー判断、確信がある場合の画像の実体化、最終保存までを一度に完了させる必要があります。
• テキストのみの下書きで止めて、図を挿入するかどうかをユーザーに尋ねるだけにしないでください。ユーザーが明示的にテキストのみを求めた場合を除き、同じタスク内で図の置換判断を完了させてください。
• ノートは実際の見出しレベル（#、##、###）を使用する必要があります。
• 最終的なノートはすべて、# タイトル見出しの上に Obsidian YAML プロパティブロックを置いて開始する必要があります。少なくとも papers/<domain> 値を含む tags フィールドと有用な aliases を含めてください。判明している場合は date、doi、arxiv_id を含め、利用できないフィールドはプレースホルダーをでっち上げるのではなく省略してください。
• ローカライズされた Core Information セクションは、固定されたメタデータブロックのみでなければなりません。writing_contract.core_info_fields で宣言されたフィールドと順序のみを使用し、利用できないフィールドは省略し、解説は後続の分析セクションに移動してください。
• 抄録メタデータが利用可能な場合、一文要約の前に、ローカライズされた Abstract セクションを冒頭付近に含めてください。
• Abstract セクションは、モデルが書いた要約で置き換えるのではなく、論文の元の抄録を設定された言語で忠実に表現する必要があります。
• Abstract セクションに、後からの判断、貢献の要約、後知恵の説明を混ぜ込まないでください。
• Abstract の直後かつ一文要約の前に、専用のローカライズされた Contributions セクションを含めてください。
• Contributions は、空疎な賛辞を述べるのではなく、論文の実際の革新性を列挙し、それぞれがなぜ重要かを説明する必要があります。
• 高品質なノートは、論文が簡単ではない場合、通常、技術セクションに複数の意味のある ### 小見出しを含むべきです。
• 下書きまたは保存の前に、完全な図表判断テーブルを生成し、生成された writing_contract.figure_table_contract を満たしてください。
• 統合バンドルが構築された後、note_plan を作成する前に、モデル主導の Visual Review Gate と Figure/Table Decision Freeze を完了してください。review_pending の項目がその境界を越えてはなりません。
• 進む前にグラウンディングと最終ノートの図ゲートを通過してください。失敗した判断カバレッジ、挿入、構造、ステータスチェックは修正してください。
• insert 判断は、Formal Save が選択された画像を論文ローカルの images/ ディレクトリに実体化し、書き込みが成功して初めて完了します。
• ノートは、設定された言語のスタイルゲートを通過する必要があります。zh-CN は中国語と英語が混在した文の不自然な箇所を拒否し、en は引用メタデータ外の中国語の文を拒否します。
• スタイルゲートは、KV缓存 of、批量ing、In相关 Researcher、Single 序列 generation のような機械的な用語置換の不自然な箇所も拒否します。部分的に翻訳されたフレーズを保持するのではなく、文を自然に書き直してください。
• スタイルゲートの適用: lint_note.py の出力に passes_style_gate: false が含まれる場合、報告された問題を修正し、lint を再実行してください。lint が通過するまで修正と再実行を続けてください。複数回のラウンドは正常であり想定内です。いかなる失敗も許容される例外であると判断しないでください。固有名詞、数式、引用メタデータは自動的な免除ではありません。同じ失敗が複数回のラウンドにわたって変化なく現れ、減少が見られず、モデルがそれ以上自律的に進歩できないことを示す場合にのみ、ユーザーにエスカレーションしてください。
• PDF またはエビデンスの品質が、真に深いノートを作成するには不十分な場合、フェイルクローズドしてください。停止し、ブロックされたステージを報告し、続行に必要なより良い PDF、OCR/ソース素材、またはその他の入力を求めてください。 モデル優先のルール：
• スクリプトは証拠を収集し、整理してもかまいません
• スクリプトを論文理解の主要な手段にしてはいけません
• 論文の最終的な理解とノートの執筆はモデルが担います
• 生成されたバンドルの仕様を使って、論文の種類、セクションの意味、証拠に裏付けられた主張、境界、比較、再利用可能な追加質問を選択します。スクリプトによる提案はあくまでヒントであり、執筆を左右するものではありません
• 長い自由形式の<thinking>ブロックを必須にしたり、表示したりしないでください
• 技術論文では、概要レベルの要約よりも再現可能なレベルの説明を優先してください
• 数式、目的関数、計算量の式が中心的な場合は、重要なものを最終ノートに含めてください
• 数式はインラインコードやフェンス付きコードブロックではなく、$...$または$$...$$で表記してください
• 最終保存の前に、ノートに十分な技術的詳細、重要な数値、必要な数式が含まれているかを明示的に自己レビューしてください
• final_quality_reviewでは、次の7つの問いに照らしてノート全体を確認してください。中心となる証拠の連鎖が完全か、重要な設定と数値が含まれているか、メカニズムやプロトコルが、それらによって説明される結果のパターンと結び付けられているか、強力なベースラインや代替手法に対する論文の位置付けが明確か、考察や限界に関する結論がメカニズムの観点から説明されているか、実証済みの主張と未実証の主張が区別されているか、研究・エンジニアリング・再現・妥当性に関する示唆が再利用できるほど具体的かを確認してください
• 3つ以上のシステム、設定、タスク、データセット、指標、アブレーション行を含む中心的な定量比較は、通常、簡潔なMarkdownテーブルにまとめ、その後に解釈を添えてください。テーブルのほうが明瞭な場合、主要な結果を箇条書きだけで示してはいけません
• 短い論文でも、深掘りしたノートを完全な形で作成する必要があります。ノートを簡潔な要約に圧縮するのではなく、節約できた分量を使ってプロトコルの詳細、アブレーション、限界、デプロイや再現への示唆を説明してください
• final_quality_reviewに合格したら、読みやすさを確認するため、ノート全体をもう一度読み直してください。形式的な要件を満たすだけで終わらせないでください
• final_readability_reviewでは、固有名詞の表記を維持しながら、言語の残りを設定言語の自然な文章に書き換えてください
• リントを通すためだけに、final_readability_reviewを使って新しい事実を作り出したり、中身のない埋め草を加えたり、より浅い無難な表現にしたりしないでください

上記のトピック資料は難しい実行時の参考になりますが、通常の実行手順では、それらすべてを読む必要はありません。

スクリプト

ワークフローをゼロから作り直すのではなく、同梱の次のスクリプトを使用してください。

• scripts/check_environment.py
• scripts/user_configuration.py
• scripts/create_input_record.py
• scripts/locate_zotero_attachment.py
• scripts/resolve_paper.py
• scripts/run_pipeline.py
• scripts/collect_metadata.py
• scripts/fetch_pdf.py
• scripts/extract_source_text.py
• scripts/extract_evidence.py
• scripts/extract_pdf_assets.py
• scripts/plan_figures.py
• scripts/plan_figure_table_decisions.py
• scripts/build_synthesis_bundle.py
• scripts/lint_grounding.py
• scripts/lint_note.py
• scripts/materialize_figure_asset.py
• scripts/write_obsidian_note.py

Python インタープリターのルール：

• DeepPaperNote には Python >=3.10 が必要です。
• リポジトリのスクリプトを実行する前に、現在のシェルのデフォルトが要件を満たすと思い込まず、インタープリターのバージョンを確認してください。
• デフォルトの python3 が 3.10 未満の場合は、要件を満たす別のインタープリター（python3.12、python3.11、python3.10、/opt/anaconda3/bin/python3、/opt/homebrew/bin/python3、/usr/local/bin/python3 など）が利用できるか、自動的に探してください。
• 最初に見つかった要件を満たすインタープリターを使用し、現在のタスクでリポジトリのスクリプトを実行する際は、以降もそのインタープリターを使用してください。
• 要件を満たすインタープリターが見つからない場合は、処理を中止し、見つかったインタープリターと報告されたバージョン、および DeepPaperNote には Python >=3.10 が必要であることをユーザーにはっきり伝えてください。

トラブルシューティングのルール：

• 具体的な依存関係または統合に関する問題が実行を妨げている場合に限り、scripts/check_environment.py を使用してください。
• 必須の依存関係、任意の拡張機能、機能が制限される場合の動作については、別のトラブルシューティングワークフローに誘導せず、直接説明してください。
• 環境の調査を、ユーザー向けの擬似コマンドとして紹介しないでください。

現在の状況：

• 単一論文向けの決定論的なコアパイプラインは、MVP として実装済みです。
• scripts/run_pipeline.py は、モデル向けの統合バンドルをデフォルトで構築するようになりました。
• scripts/write_obsidian_note.py は、最終的なノートを指定した Vault に書き込めます。
• ワークフローを場当たり的に置き換えるのではなく、スクリプトにパッチを適用してください。

制限事項

• 論文の識別情報が曖昧な場合は、書き込みを行う前に確認してください。
• サポート対象のすべての取得方法を試しても PDF が利用できない場合は、処理を中止して、必要な入力を報告してください。完成品として、品質を落としたノート、暫定ノート、または抄録のみのノートを作成してはなりません。サポート対象の取得方法には、ローカル PDF、Zotero 添付ファイル、メタデータの pdf_url、PDF の直接 URL、arXiv／オープンアクセスソース、アクセス可能な場合の出版社 PDF、DOI による補完、その他ワークフローに実装されている現在の取得方法が含まれます。
• 図の計画ではプレースホルダーを優先する必要があります。画像の抽出は任意であり、テキストの網羅性を決して損なってはなりません。