paper-glossary

論文用語集

*_source_manifest.json から共有用語集のメモを作成します。--source-manifest は常に必須です。--raw-sections は、明示的に指定した *_raw_sections.jsonl で raw_sections_path を上書きする場合にのみ使用します。このスキルが論文を読むワークフローを実行または変更することはありません。論文の内容にアクセスできるのは、マニフェストと raw-sections ファイルのみです。JSON と CLI の仕様については、references/file-contract.md を参照してください。

プレビューして待機（デフォルト）

1. 初回は、使用する人／デバイスごとに保存済みの設定を表示します。 設定がない場合は、Obsidian の保管庫内にある用語ディレクトリを確認して設定します。以降は有効な設定を再利用します。セットアップにより ~/.paper-glossary/config.json が作成される場合があります。
2. 記事へのリンクが要求された場合は、記事の Markdown パスを明示的に指定する必要があります。 そのパスと設定済みの用語ディレクトリが同じ Obsidian 保管庫内にあることを検証します。記事パスを推測してはいけません。
3. 有効な本文から決定的な候補提案を実行します。
4. 根拠に基づくホストの意味レビューを厳密に 1 回実施し、候補を shortlist_limit 件までに絞ります。レビューでできるのは候補の除外または並べ替えのみです。採用する提案候補の term 文字列は一字一句そのまま保持する必要があります。
5. plan_glossary.py --review-proposal PROPOSAL --reviewed-terms NAMES を使って、レビュー済みの候補リストを記録します。これにより、保存済みの提案が現在の論文ソースと照合され、各候補の全情報、順序付きの surface_forms、および来歴が保持されます。 レビューの結果、レビュー済み候補リストが空になった場合は、no_candidates と報告して、選択 UI を表示せずに終了します。
6. レビュー済みアーティファクトから採用された用語をすべて、番号付きの Markdown リストとして提示します。これはターミナル、Codex、Claude Code でのやり取りです。解決された用語ディレクトリ、記事の Markdown パス（または指定されていない旨）、および選択によって用語集への書き込み／情報拡充と、記事が指定されている場合は記事内で最初に安全に出現する箇所へのリンク追加が許可されることを示します。
7. 選択前に用語集のメモや記事の Markdown ファイルが書き込まれていないことを伝えます。 応答を終了して待機します。 プレビュー中は、トリアージ、インベントリ作成、生成、リンク追加、リントを行ってはいけません。

選択後

直前の番号付きリストにある数字、正確な用語名、または 全部写入 のみを受け付けます。 スクリプトを実行する前に、選択内容を表示されている正確な term 文字列に解決してください。全部写入 はそのリストにのみ適用されます。無効な選択には、有効な範囲を示して再入力を待ちます。トリアージでは --reviewed-shortlist REVIEW と、解決済みの正確な名前を指定した --terms の両方が必要です。--terms のみを使ったり、エイリアス構文を追加したりしないでください。

現在の --source-manifest、任意の --raw-sections、保存済みの --reviewed-shortlist をインベントリー、ライター、リンカーに渡してください。インベントリーは、選択用の入力として保存済みの --triage アーティファクトを使用します。ライターとリンカーにも、同じ保存済みの --triage を渡してください。グロッサリーや記事への書き込みを行う前に、独立したこの認可情報と term および surface_forms の順序付きリストが完全に一致している必要があります。

1. 選択内容をトリアージします。選択の識別情報では、選択した正確な名前と、論文に基づく順序付きの表記がそれぞれ結び付けられます。
2. そのトリアージアーティファクトからライブラリーのインベントリーを実行します。提案、レビュー、選択の来歴チェーン全体を再計算し、論文、ソース、ショートリスト、または表記が一致しない場合は処理を中止します。
3. 次に、アクションを考慮したバッチを1つ生成します。
4. 設定済みのグロッサリーディレクトリーに対して、ライターを1回実行します。ライターは同じ来歴チェーンを再検証し、インベントリーの順序付き結果が認可済みのトリアージと完全に一致することを確認してから、バッチ全体の事前チェックを行い、その後に作成・拡充・再利用のコミットを実行します。ライターはデバイス固有の設定（またはそのデバイス用に明示された --config-path）を解決し、単独の書き込み先は受け付けません。--article を指定した場合、バックリンクは解決済みの記事 Markdown のステムから導出されます。記事を指定しない場合、グロッサリーのみのリクエストのバックリンクには、検証済みマニフェストの paper_id が使用されます。成功したアーティファクトには triage_sha256、来歴、記事コンテキスト、順序付きマッピング、および決定的な mappings_sha256 が保持されます。マッピングダイジェストはトリアージの識別情報に結び付けられています。
5. 記事 Markdown が指定または要求された場合に限り、ライターが成功を返した各結果を、最初の安全な出現箇所にリンクします。リンカーは、ライターの来歴、コンテキスト、ダイジェスト、ノートのパス、ステム、表記を、同じ現在のソースおよびレビューと照合して認証し、記事パスが結び付けられていないアーティファクトを拒否します。グロッサリーのみのリクエストでは、link_glossary_terms.py をスキップしてください。
6. ライターが返した変更済みのグロッサリーノートファイルのうち、action が created、enriched、または updated のものを、--input PATH 引数を繰り返し指定して、lint_glossary.py を1回実行してリントします。記事 Markdown を lint_glossary.py に渡さないでください。
7. 観測可能な実時間とステータスを報告します。ホストのみで行うフェーズは個別に計測してください。各 CLI は、処理全体の呼び出し時間を示すトップレベルの elapsed_ms を出力します。ライターの1回の実行には、バッチ全体の事前チェックとコミットが含まれます。事前チェックとコミットの時間を個別に報告しないでください。

new エントリーは作成されます。existing_thin エントリーには、不足している構造化フィールドと出現箇所のみが追加されます。existing_complete エントリーには、不足している出現箇所のみが追加される場合があります。既存のノート内容を上書きしないでください。existing_thin、エントリー操作、ライターの forms、リンクステータスについては references/file-contract.md を参照してください。

根拠付け

• anchor_only：論文での簡潔な用法と、簡単な一般的説明。
• needs_explanation：確信度と論文内の出現箇所を示した、背景説明のラベル付き記述。
• 参考文献のみの出現箇所は根拠として除外してください。論文の事実は occurrence に記載し、外部知識にはラベルを付けてください。