paper-interpreter

論文解説アシスタント

適用シーン

• ユーザーが https://arxiv.org/... のリンクを送り、「論文解説」「論文の分析」「詳細な要約」「レポートの作成」「論文のダウンロード」を明確に求めている場合
• 論文資料をローカルディレクトリに保存し、構成が整っていて、継続的に加筆しやすい中国語のレポートを作成したい場合
• 会話内で要約を読むだけでなく、ローカルファイルを主な成果物として受け取ることを希望している場合

ユーザーが200字程度の推薦文だけを求めている場合は、paper-recommendation を優先して使用し、この skill は使用しないでください。

設計パターン

この skill では、主に以下を採用します。

• Pipeline：「資料のダウンロード → 資料の閲覧 → 初稿の作成 → 納品 → 必要に応じた再確認」の順序を厳守して実行します
• Generator：固定のレポート構成に基づいて、長期的に改訂できる文書を作成します
• Inversion（軽度）：開始前に範囲を確認し、再確認の前に改めてユーザーの同意を得ます

注意点

• 「論文の推薦文」を「論文解説」と誤認しないでください。この2つは異なる skill に振り分けます
• 再確認を既定で予定しないでください。再確認を行うかどうかは、必ず先にユーザーに確認してください
• 論文全文を読み終えたかのように装わないでください。要旨、手法、実験を重点的に確認しただけの場合は、そのことを明確に伝えてください
• 論文に存在しない実験、数式、結論、データを捏造しないでください
• パスだけを伝えてファイルを送らないのではなく、現在のチャネルがファイル送信に対応している場合は、レポートファイルを優先して直接送信してください

ワークフロー

0. まず実行範囲を確認する（必須）

開始前に、少なくとも次の3点を簡潔にユーザーへ確認してください。

• 論文をローカルにダウンロードしてレポートを作成すること
• 初版はまず1版を完成させ、再確認を自動では予定しないこと
• 最終的には会話内で全文を長々と出力するのではなく、ファイルを主な成果物として納品すること

ユーザーがすでに「ローカルにダウンロードしてレポートを作成する」という進め方に明確に同意している場合は、繰り返し確認せず、そのまま続けてかまいません。

1. 保存先ディレクトリを決める

次の優先順位でベースディレクトリを選択します。

1. ユーザーが明確に指定したディレクトリ
2. 現在のコンテキストから、ユーザーが普段使っているワークスペースと明らかに判断できるディレクトリ
3. ~/Documents/working/papers

新しいディレクトリを勝手に作らないでください。特定できない場合は、既定値を使用してください。

2. 論文用ワークスペースを初期化する

まずスクリプトを実行し、論文用ディレクトリを作成してリソースをダウンロードします。

python3 skills/paper-interpreter/scripts/bootstrap_arxiv_paper.py '<arxiv_url>' '<base_dir>'

スクリプトは以下を行います。

• arXiv ID を解析します
• 論文タイトルを使ってサブフォルダーを作成します
• PDF をダウンロードします（論文タイトルをファイル名に使用）
• TeX Source のダウンロードを試みます
• 識別できる場合は、自動的に source/ に展開します
• metadata.json を書き込みます
• レポートファイル {论文标题}_报告.md が存在しない場合は、レポートのひな形を作成します

スクリプトの出力にある paper_dir、report_path、pdf_path、source_path を優先して参照してください。

3. 資料を読み、初版レポートを作成する

レポートを作成する前に、次の順序で情報を取得します。

1. metadata.json
2. arXiv の要旨ページ
3. TeX Source（ダウンロードに成功した場合は、数式、モジュール名、アルゴリズムの手順を確認するために優先して使用します）
4. PDF ファイル（論文タイトルをファイル名に使用）

レポートは論文用ディレクトリ内の {论文标题}_报告.md に書き込み、以下の条件を満たす必要があります。

• 中国語で出力すること
• 構成が整っていて、長期的な改訂に適していること
• 論文に存在しない実験、数式、結論を捏造しないこと
• 不確かな内容には「論文では明確に説明されていません」または「追加の確認が必要です」と明記すること
• 適切な箇所で mermaid skill を呼び出して Mermaid 図を作成すること。少なくとも1つ、通常は2～3つが適切です
• 複数のレポートを作成する必要がある場合は、引き続きタイトルを接頭辞に使用し、末尾の名前で区別します。例：{论文标题}_报告_复查1.md、{论文标题}_报告_分享版.md

report-outline.md の構成を優先して使用してください。

4. 初稿の完成要件（必ず実行）⚠️

初版レポートの作成後、直ちにレポートファイルをユーザーに納品してください。

• レポートファイルを納品します：{论文标题}_报告.md
• 現在のチャネルがファイル送信に対応している場合は、ファイルを優先して直接送信してください
• 現在のチャネルがファイル送信に対応していない場合は、少なくともアクセス可能なパスを明確に提示してください
• 初稿であることをユーザーに伝えてください
• さらに確認する価値があると判断した場合は、「必要であれば、もう一度確認できます」と付け加えてもかまいませんが、すでに予定済みであるかのように伝えないでください

例：

✅ 论文初稿已生成！

📄 报告文件：<报告文件路径或文件>
📝 当前版本：v1.0 初稿
如果你要，我可以再复查一轮，补实验细节和边界条件。

5. レポートの執筆要件

レポートでは、少なくとも以下を扱います。

• 論文の基本情報
• 一文での要約
• 解決する課題と研究の動機
• 手法の分析
• 学習または推論のフロー
• 実験設定と主な結果
• 優れた点、限界、適用範囲
• 実際の応用や研究の発展に関する見解
• 用語の説明
• 再確認の記録

mermaid skill を呼び出す際は、次の図を優先して検討できます。

• 手法の概要：flowchart LR / flowchart TD
• 学習または推論の段階：sequenceDiagram または flowchart
• モジュール間の関係：graph TD

理解に本当に役立つ図だけを残してください。図の数を満たすために mermaid skill を呼び出して図を追加しないでください。

6. 再確認が必要な場合は、必ずユーザーの同意を得る

初版レポートが完成した時点で、既定の作業フローは終了です。

ユーザーが「再確認を続ける」ことに明確に同意した場合に限り、その後の改善プロセスに進めます。具体的な要件は次のとおりです。

• 再確認するかどうかを先にユーザーに尋ね、自己判断で予定しないでください
• ユーザーの同意を得てから、1回または複数回の遅延再確認を予定できます
• 現在の環境が定期実行タスク、バックグラウンドタスク、リマインダーに対応している場合は、確認を得た後に予定できます
• 現在の環境が実際の定期実行に対応していない場合は、その制約を明確に伝え、レポートに再確認時の推奨事項を記載してください

7. 再確認タスクの更新原則

再確認時にレポート全体を書き直さず、増分更新に従ってください。

• まず現在のレポートファイルを読み込みます
• 次に論文の原文、PDF、Source と現在のレポートの差分を確認します
• 漏れていた実験の詳細、手法の適用範囲、制約条件、図、用語の説明を優先して補足します
• 复查记录 セクションに、今回の更新日時、主な追加内容、修正内容を明記します
• ユーザーが手作業で追加した内容は、論文の事実と矛盾することを確認した場合を除き、削除しないでください

出力要件

初版レポート完成後に必ず行うこと⚠️

ステップ1：レポートファイルを納品する

• 現在のチャネルがファイル送信に対応している場合は、{论文标题}_报告.md を直接送信します
• 現在のチャネルがファイル送信に対応していない場合は、明確でアクセス可能なファイルパスを提示します
• 以下を簡潔に添えます。
  • 初稿が完成したこと
  • 現在のバージョン情報
  • 再確認が必要な場合は、引き続き依頼できること

ステップ2：基本情報を報告する

• 論文用ディレクトリのパス
• PDF ファイル（論文タイトルをファイル名に使用）のダウンロード成否
• TeX Source のダウンロード成否
• レポートファイルのパス（既定では {论文标题}_报告.md）
• 再確認を推奨するかどうか、および再確認には必ず事前にユーザーの同意が必要であること

注意：必ず先にファイルを送信し、その後で情報を報告してください。順序を逆にしないでください。

TeX Source が存在しない、またはダウンロードに失敗した場合は、「ソースファイルを取得できませんでした」と明確に伝えたうえで、レポートの作成を続けてください。