intro-drafter

はじめにの草稿作成

概要

「はじめに」は、論文全体を圧縮したものです。1ページ半から2ページで、研究対象、問題が重要な理由、既存研究では不十分な理由、本論文の貢献、そして各貢献と各節の対応を述べる必要があります。査読者は「はじめに」を読み終えるまでに続きを読むかどうかを判断するため、論理展開に一切の隙があってはなりません。

このスキルは文章生成ツールであり、アウトライン生成ツールではありません。少数の入力（研究分野、限界、重要なアイデア、課題、解決策の概要、任意の参考文献）を受け取り、「はじめに」の本文となる6つの段落を作成します。6段落のフローチャートは内部の足場として機能し、出力には決して現れません。

生成される文章は、研究者が書いたかのように読める必要があります。流れるような段落で構成し、インラインタグ、「段落1：背景」といった見出し、重大度の表、整合性レポートは含めません。「はじめに」の本文だけを出力します。

明示的なアウトラインも引き続き利用できます。下記の「アウトラインモード」を参照してください。

エビデンスに関するルール（継承）

このスキルは、共有されているエビデンスの規律に従います。事実に関する主張はすべて、ユーザーの資料、このセッションで検証済みの検索結果、または分野の一般知識に基づくものとします。モデルの記憶は情報源として使いません。生成する文章には角括弧付きのプレースホルダータグを一切含めません。ユーザーから提供されていない詳細（具体的なシナリオ、メカニズム、規模、手順、識別子）は、創作せず省略します。

参照先：references/evidence-discipline.mdおよびreferences/prose-delivery.md（paper-writerと共有）。

このスキルを使う場面

• 「はじめにを書いてください」「このアイデアから序論の草稿を作成してください」と依頼された場合。
• ユーザーが研究についての考えを段落で提示し、箇条書きではなく完成した文章を求めている場合。
• ユーザーの目標と重要なアイデアは固まっているものの、「はじめに」の文章がまだない場合。
• ユーザーが参考文献を貼り付け、「はじめに」に盛り込むよう求めている場合。

このスキルを使わない場面

• ベンチマーク論文の場合：benchmark-paper-templateを使用します（フローチャートが異なります）。
• 「はじめに」以外の節の場合：paper-writerを使用します。
• 文章がすでにあり、推敲が必要な場合：paper-polishを使用します。
• 投稿準備が整っているかどうかの判定を求められた場合：pre-submission-reviewerを使用します。

事前確認：STEMかどうか

6段落モデル（背景、限界、目標、課題、解決策、貢献）は、STEMおよび技術論文向けに設計されています。人文学、社会科学、経済学、法学など、研究手法がSTEMに該当しない場合は、この足場に無理に当てはめず、paper-writerに引き継ぎます。paper-writerのCERプランニングはそうした研究パラダイムを対象としていますが、エビデンスに関するルールはすべて引き続き適用されます。判定基準となるのは研究手法です。実験、ベンチマーク、モデル、アルゴリズムを扱う場合はこちらを使用し、それ以外はpaper-writerに引き継ぎます。

基本手順（STEM）

まず内部で考え、その後に文章を作成します。中間段階の考えは出力しません。

ステップ1：論文のタイプを位置づける（内部）

TechniqueとNew Problem/Settingの区別、およびAlpha-SQL、AFlow、LEADを用いた具体例については、references/paper-types.mdを参照してください。

• Technique論文：既存の問題に対する新しい手法が貢献です。説明の軸は重要なアイデアであり、第3段落は短いつなぎとなります。
• New Problem/Setting論文：問題の定式化そのものが貢献です。第3段落が論文の要となります。

ステップ2：6段落を計画する（内部）

各段落の目的、執筆の要点、よくある失敗については、references/flowchart.mdを参照してください。

各段落について、目的、ユーザーの入力から導いた具体的な執筆ポイントを2～4個、そして不足情報（入力でまだカバーされていない点）を整理します。不足情報は文章の中ではなく、文章の後でユーザーに伝えます。

1. 背景と動機、具体例、問題が重要である理由。
2. 既存研究の限界（最大3つ）。
3. 問題の本質と目標。厳しい制約を明示します。
4. 主要な課題（最大3つ）。
5. 解決策の概要。各課題に1つずつモジュールを対応させます。
6. 貢献（3つまたは4つ。それぞれを節に対応づけます）。

ステップ 3：実行例（内部）

設計原則とパターンについては、references/running-example.md を参照してください。

ユーザーが実行例を提示していない場合は、捏造しないでください。 参照ファイルの第一原則は、例が実際のデータまたは実際のデプロイに基づくものであることです。背景の段落は、ユーザー自身が記述した抽象的な問題説明に基づいて書き、締めくくりの注記で次のように尋ねてください。 「具体的な実行例があると第 1 段落をより強くできます。実験やデプロイでの実例を共有していただけますか？」

ステップ 4：整合性の確認（内部、執筆前）

強い貢献パターンと弱い貢献パターンについては、references/contribution-patterns.md を参照してください。

次の点を黙って確認してください。第 1 段落の実行例が第 5 段落または第 6 段落で再び登場していること、各課題が限界または厳しい制約への回答になっていること、目標が貢献 1 と整合していること、課題とモジュールが一対一で対応していること、貢献が 3 つまたは 4 つあり、それぞれがセクションに結び付いていて、曖昧なもの（「広範な実験」など）が含まれていないこと。

確認に失敗した場合は、文章を書く前に計画を修正してください。破綻した論理の流れを取り繕うように書いてはいけません。

ステップ 5：本文を書く

次の方針に従い、流れのある 6 段落を作成します。

• 出力に段落ラベルを付けないでください。 自然なつなぎの表現で構成を示します（「こうした進展にもかかわらず、…」「本研究では、…」「貢献を以下にまとめます。」）。
• 各段落は 1 つのまとまりとし、おおむね 100～250 語とします。分量は論文の種類に応じて調整してください（references/paper-types.md を参照）。
• 引用：初出順の番号付き引用 [1]、[2]、…を使用します。6 段落から成る一般的な Introduction では、通常 15～25 件の文献を織り込みます。背景では 3～5 件、限界の説明では 5～8 件、第 3～5 段落では各 2～4 件、貢献の説明では 0～2 件です。文献が少ないと、意見記事のように読めてしまいます。執筆前に検索してください。異なるキーワードを使って 3～5 回検索し、文献候補を集めます。議論は、検索して見つけ、検証した研究を中心に構成します。出典を見つけられない主張は、引用を付けずに済ませるのではなく、その主張が不要になるように書き換えます。本文の後には、引用箇所と双方向に対応する References リストを付けます。引用が 3 件以上ある場合は、paper-writer で定義された独立した引用検証の手順を実施します。環境が許せば、新しいコンテキストで各文献を確認し、それができない場合は、検証範囲を適切に縮小し、その旨を明示してください。
• 数値と主張：割合、速度向上、ベンチマーク数値を捏造してはいけません。具体的な向上を記載できるのは、ユーザーが報告した場合のみです。それ以外の場合は、注釈を付けずに「既存のベースラインを上回る」とします。
• 時制：先行研究や観察結果には過去形を使い、論文独自の未検証の主張には現在形または未来形を使います（「本論文は提案する」）。報告済みの結果がない場合は、「達成した」や「実証した」と書いてはいけません。
• トーンの確認：最終化の前に、AI らしい表現や根拠のない最上級表現を取り除き、根拠の強さに合った動詞を使います（共有の用語リストの場所については、以下の「トーンに関する参考資料」セクションを参照）。

ステップ 6：短い締めくくりの注記（任意、最大 3 行）

本文（および References）の後に、必要であれば短く平易な注記を付けます。ユーザーが補うべき情報、不足している入力を踏まえた仮の段落、またはステップ 3 の実行例に関する依頼を記載できます。表、リスト、深刻度ラベルは使わないでください。伝えるべきことがなければ、注記は付けません。

ユーザーに渡すもの

• 空行で区切った Introduction の文章 6 段落。引用は [1]、[2]、…の形式。
• 引用がある場合は、本文の直後に References リスト。
• 任意で、1～3 行の平易な注記を 1 つ。

それ以外は何も出力しません。見出し、ゲートの結果、深刻度の要約、プレースホルダータグ、作業手順の前置きに関する禁止事項の完全な一覧は references/prose-delivery.md に記載されており、必ず従う必要があります。

アウトラインモード（明示的な依頼があった場合）

ユーザーが文章ではなくアウトラインを明示的に求めた場合（「アウトラインだけ」「まず骨子を示して」など）は、代わりに従来の構成を返します。まずタイプ、根拠、示唆という位置づけを示し、続いて6つの段落それぞれについて、目的、執筆ポイント、重大度を含む不足点を示します。最後に、5つの整合性チェック（実行例のループ、限界から課題へのつながり、目標から貢献1へのつながり、課題とモジュールの対応、貢献とセクションの対応）を示します。同じ内部計画を、依頼があった場合に一度だけ外部化します。

トーンの参考資料

共有スタイルの参考資料は、正本とともにpaper-polish（ai-tone-guardrails、academic-phrasebank、section-conventions）にあります。このスキルの文章仕上げにも適用されます。より細かな表現の助けが必要な場合は、このスキルの参照資料から確認してください。

スキル間の引き継ぎ

• はじめにが完成しており、論文の残りも執筆したい場合：paper-writer。
• 文章はできているものの、硬い場合：paper-polish。
• そのアイデア自体でトップ会議の論文として成立するか疑問がある場合：その疑問を「はじめに」に書かず、締めくくりの注記に一文だけ記し、idea-evaluatorを案内してください。

出力言語

明示的な言語指定を最優先してください。中国語の学術誌や中国語の学位論文が指定されている場合は、中国語で文章を作成します。それ以外の場合は、英語を標準とします。ユーザーのメッセージの言語から出力言語を推測してはいけません。