mcpField
A
academic-writing-cs

academic-writing-cs

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

academic-writing-cs について

コンピューターサイエンス研究者向けの論文執筆スキルです。構成の計画から草稿作成、改稿までを支援し、文章の明瞭さや分野ごとの慣習も扱います。

主な機能

  1. 01論文の構成と展開の計画
  2. 02セクション別の執筆ガイド
  3. 03文の明瞭さを高める原則
  4. 04CSの慣習と投稿先の要件
  5. 05論文品質のチェックリスト

活用シーン

  1. 01会議論文のアウトライン作成
  2. 02方法または結果セクションの改稿
  3. 03段落や文の流れの改善
  4. 04投稿先の慣習に照らした原稿確認

インストール

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

$npx skills add https://github.com/sipengxie2024/helios-writing --skill academic-writing-cs

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

同梱ファイル

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

assets/
section_checklists.md
references/
cs_conventions.md
narrative_framework.md
phrasebank.md
sentence_clarity.md

詳細

コンピューターサイエンスの学術論文執筆

概要

このスキルは、質の高いコンピューターサイエンス研究論文を執筆するための一貫したサポートを提供します。分野固有の慣例を守りながら、明快で説得力のある技術的なストーリーを構成することに重点を置いています。

基本理念:

  • 学術論文は、テンプレートを埋めるものではなく、物語の展開(問題 → 解決策 → 根拠 → 示唆)です
  • 明快さは構成から生まれます。読者になじみのある情報を先に、新しい情報を後に配置します
  • すべての設計上の選択には正当な理由が必要であり、すべての主張には裏付けが必要です

対象範囲:

  • 会議論文(6〜12ページ、競争の激しい会議)
  • ジャーナル論文(15〜30ページ、包括的な内容)
  • 学位論文の章(長さは柔軟で、詳細に扱います)
  • CS の全サブ分野:AI/ML、システム、理論、HCI、セキュリティなど

このスキルを使う場面

次のようなときに、このスキルを呼び出してください。

  • 論文の構成やストーリーの流れを計画するとき
  • あらゆるセクション(要旨、序論、手法、結果、考察、結論)の草稿を作成するとき
  • 明快さ、一貫性、会議やジャーナルの要件への準拠を目指して改稿するとき
  • 文単位の文章を確認し、明快さに関する問題を見直すとき
  • CS 固有の慣例(記法、図、引用)を確認するとき
  • セクションごとの品質チェックリストを使って網羅性を確認するとき
  • 査読者のコメントに回答するとき

ワークフローの判断ツリー

ステージ 1:計画と構成

新しい論文を始めるとき、または大幅な改訂を行うとき:

  1. ストーリーの展開を定義する

    • どのような問題を解決し、なぜ重要なのですか?(1〜2文)
    • 主な貢献は何ですか?(1文)
    • その貢献を裏付ける重要な結果を3つ挙げると何ですか?
    • 主な限界は何ですか?

    参考資料: references/narrative_framework.md — 論文のストーリーをどのように構成するかを理解するため、「Core Principle」と「Section-Level Narrative Structure」の各セクションを読んでください。

  2. 投稿先と制約を特定する

    • 会議ですか、それともジャーナルですか?
    • ページ数の上限、書式要件、匿名化ルールはありますか?
    • サブ分野固有の慣例(ML とシステムと理論の違いなど)はありますか?

    参考資料: references/cs_conventions.md(セクション 8:投稿先固有のガイドライン、セクション 5:サブ分野固有の慣例)

  3. セクションごとにアウトラインを作成する

    • 主要な各セクションについて、次の点を定義します。
      • このセクションの目的は何ですか?
      • 伝えるべき重要な点は2〜3つ何ですか?
      • どの図や表で裏付けますか?

    ツール: assets/section_checklists.md(草稿作成前の簡易計画チェックリスト)を使い、執筆を始める前に重要な問いすべてに答えられていることを確認してください。


ステージ 2:草稿の作成

各セクションで、次の手順に従ってください。

要旨
  1. 4文構成を使います:背景 → ギャップ → 貢献 → 影響
  2. assets/section_checklists.md(要旨チェックリスト)に照らして確認します
  3. 単独で内容が理解でき、語数の上限(150〜250語)に収まるようにします

よくある間違い:

  • 貢献が曖昧:「X を改善します」→ 具体的にします:「精度を15%向上させます」
  • 具体的な結果がない:必ず数値や指標を含めます

序論
  1. ファネル構成に従います:広い視点 → 焦点を絞る → 具体化

    • 第1段落:問題領域とその重要性
    • 第2〜3段落:具体的な問題、動機、既存研究の不十分な点
    • 第4段落:ギャップの説明(「しかし、既存のアプローチには……が欠けています」)
    • 第5段落:貢献の概要(本論文が提供するもの)
    • 第6段落:結果の要約(具体的な知見を2〜3点)
    • 第7段落:論文の構成(任意)
  2. 重要な要件: 第4〜5段落の終わりまでに、読者が貢献を明確に理解できるようにします。

  3. ML/システム系の論文では、図(アーキテクチャまたは主要な結果)を少なくとも1つ含めます。

  4. assets/section_checklists.md(序論チェックリスト)に照らして確認します

参考資料: 詳細なガイダンスと例については、references/narrative_framework.md の「Introduction」セクションを参照してください。


関連研究
  1. テーマ別に整理する(時系列順ではなく):3〜5個のカテゴリーに分類します

  2. 各カテゴリーについて:

    • 一般的なアプローチを説明します
    • 代表的な研究を3〜5件挙げ、それぞれ1文で説明します
    • 自分の貢献に関連する限界を指摘します
  3. 最後に位置づけを示す段落を置きます:「[X]とは対照的に、私たちのアプローチは……」

    • 違いと利点を明確に述べます
  4. assets/section_checklists.md(関連研究チェックリスト)に照らして確認します

よくある間違い:

  • 先行研究を統合せず、引用を羅列する
  • 先行研究との関係において、自分の研究を位置づけない
  • 先行研究を軽視する(敬意を払いつつ、違いを明確にします)

方法論
  1. 2つの目的:

    • 再現性:再実装に十分な詳細を示します
    • 直感的な理解:アプローチが機能する理由を説明します
  2. 構成は論文の種類によって異なります:

    • ML/AI 論文:問題の定式化 → 概要+図 → 詳細設計 → 実装 → 計算量
    • システム論文:アーキテクチャの概要 → コンポーネント設計 → 主要なメカニズム → 実装
    • 理論論文:形式的な定義 → 主な結果(定理)→ 証明の概略
  3. 必ず含めるもの:

    • 明確な表記法(すべての記号を初出時に定義します)
    • 詳細に入る前の概要
    • 設計上の選択の根拠(またはアブレーション分析に委ねます)
  4. assets/section_checklists.md(方法論チェックリスト)に照らして確認します

参考資料: references/narrative_framework.md(方法論のセクション)および references/cs_conventions.md(セクション1:表記法と数学的な文章作法)


実験/結果
  1. 実験設定(小節):

    • データセット:規模、分割、前処理
    • ベースライン:比較対象(引用付き)
    • 評価指標:測定する内容とその理由
    • ハードウェア/ソフトウェア:インフラストラクチャとバージョン
    • ハイパーパラメーター:選定方法
  2. 主な結果(小節):

    • 主要な比較を示す表/図
    • 本文:「表1は、私たちの手法が……を上回ることを示しています」
    • 具体的な数値を挙げて重要な知見を強調します
    • 統計的有意性を報告します(信頼区間、p値、または標準偏差)
  3. アブレーション分析(重要な小節):

    • 各コンポーネントの必要性を示します
    • コンポーネントを削除/変更した場合の効果を表にまとめます
  4. 分析(小節):

    • 手法が優れている点と、失敗する点を示します
    • 定性的分析、エラー分析、失敗事例
  5. 計算コスト(該当する場合):

    • 学習時間、推論時間、メモリ使用量
    • ベースラインとの比較
  6. assets/section_checklists.md(実験/結果チェックリスト)に照らして確認します

参考資料: references/narrative_framework.md(実験/結果のセクション)


考察
  1. 知見を要約する(1段落):主な結果を改めて述べます

  2. 結果を解釈する(1〜2段落):手法が機能する理由や、得られた知見を説明します

  3. 限界を認める(0.5〜1段落):適用範囲や失敗事例について率直に述べます

  4. より広い意味合いを述べる(0.5〜1段落):分野への影響、応用、今後の方向性を示します

  5. assets/section_checklists.md(考察チェックリスト)に照らして確認します

トーン: バランスを保ち、自信を持ちつつも、誇張は避けます。限界を述べることで、信頼性が高まります。


結論
  1. 貢献を改めて述べる(1段落):問題、解決策、主な知見を振り返ります

  2. より広い影響(0.5段落):意義と応用を述べます

  3. 今後の研究(0.5段落):未解決の問いや拡張の可能性を示します

    • 「興味深い方向性の一つは……です」のように機会として表現します(「今後の研究では……に取り組みます」は避けます)
  4. assets/section_checklists.md(結論チェックリスト)に照らして確認します

してはいけないこと: 新しいアイデアを持ち込む、要旨をコピー&ペーストする、曖昧な表現を使う。


ステージ3:明確さを高めるための改訂

草稿を作成した後、文単位で明確さを高める原則を適用します:

3 つの黄金律(Gopen & Swan)
  1. 旧情報から新情報へ:文はなじみのある情報から始め、新しい情報で終えます

    • これにより、各文が前の内容を踏まえて展開する、一貫性のある流れが生まれます
  2. 主語と動詞を近づける:動詞は主語の近くに置きます

    • 主語と動詞の間が離れすぎると、理解しにくくなります
  3. 強調位置の効果:最も重要な情報を文末に置きます

    • 読者は文末にある内容を記憶し、強く意識します

これらのルールを体系的に適用します:

  • 各段落について、文の流れが自然か(旧情報から新情報へ)を確認します
  • 各文について、次の点を確認します:
    • トピック位置(文頭)に、なじみのある情報が含まれている
    • 強調位置(文末)に、重要な新情報が含まれている
    • 動詞が主語のすぐ後にある

参考資料: references/sentence_clarity.md — 詳しい原則、例、よくあるアンチパターンについて、全文をお読みください。

実践チェックリスト:

  • 文頭(トピック位置)に、なじみのある情報がある
  • 文末(強調位置)に、重要な新情報がある
  • 動詞が主語の近くにある
  • 能動態を使っている(受動態のほうが適切な場合を除く)
  • 並列する考えには並列構造を使っている

修正すべきよくあるアンチパターン:

  • 「埋もれた動詞」症候群:動詞を名詞に変える(名詞化)
    • ❌ 「各手法の比較が示されています……」
    • ✅ 「表 1 では各手法を比較しています……」
  • 「前置きが長い」表現:「注目すべき重要な点は……」のような弱い書き出し
    • ❌ 「注目すべき重要な点は、私たちの手法が精度を向上させることです。」
    • ✅ 「私たちの手法は精度を向上させます。」
  • 「強調の置き去り」:弱い要素で文を終える
    • ❌ 「このアプローチは性能を大幅に向上させます。[23] に示されています。」
    • ✅ 「[23] に示すように、このアプローチは性能を大幅に向上させます。」

ステージ 4:推敲と要件への適合
言葉遣いと表現

特定の学術的な機能について執筆または改訂する際は、references/phrasebank.md を参照してください。

  • 研究の紹介:研究領域を示す、課題を特定する、貢献を述べる
  • 出典への言及:文中引用と括弧内引用
  • 手法の説明:一連の手順、条件分岐、実装の詳細
  • 結果の報告:知見を示す、ベースラインと比較する、解釈する
  • 知見の考察:成功の理由を説明する、限界を認める、示唆を述べる
  • 結論の執筆:要約する、より広い影響を述べる、今後の研究を示す

一般的な言語機能:

  • 慎重な表現(ヘッジ):「may」、「appears to」、「likely」
  • 批判的な表現:弱点を特定する、妥当性に疑問を呈する
  • 比較と対照:類似点、相違点
  • 傾向の説明:増加、減少、安定
  • 因果関係の説明:原因、結果、条件

使い方: テンプレートは文脈に合わせて調整し、そのままコピーしないでください。自然な流れを保つために、表現に変化をつけてください。


CS 固有の慣例

分野の慣例に従ってください。

  1. 表記法:

    • すべての記号は初出時に定義します
    • 表記の慣例を統一します(ベクトルは太字、スカラーは斜体など)
    • 数式は句読点を付けて文に組み込みます
  2. 図と表:

    • 図や表は、掲載前に本文中で参照します
    • キャプションだけで内容が理解できるようにします
    • 高解像度で読みやすいフォント(≥8pt)を使用します
    • 色覚多様性に配慮した配色を使用します
  3. 引用:

    • 投稿先の引用スタイル(著者名・出版年方式または番号方式)に従います
    • 基盤とする先行研究や比較対象とする先行研究をすべて引用します
    • 参考文献一覧は正確かつ完全なものにします
  4. コードと再現性:

    • コードの利用可否を明記します
    • 実装の詳細を十分に記載します
    • ハイパーパラメーター、乱数シード、実行回数を報告します
  5. サブ分野固有の違い:

    • ML/AI:アブレーション、統計的有意性、計算コストを重視します
    • システム:アーキテクチャ図、スループット/レイテンシ、スケーラビリティを重視します
    • 理論:形式的な定義、定理、証明、計算量の上界を重視します
    • HCI:ユーザー調査、定性的なフィードバック、インターフェースのスクリーンショットを重視します
    • セキュリティ:脅威モデル、攻撃シナリオ、防御メカニズムを重視します

参考資料: references/cs_conventions.md — 表記法、図、引用、コード、サブ分野の慣例、投稿先の要件を網羅したガイドです。


品質保証

投稿前に assets/section_checklists.md を使用してください。

  1. セクションごとの確認:

    • 各セクションのチェックリストを確認します
    • 必要な項目がすべて含まれていることを確認します
    • よくある落とし穴がないか確認します
  2. 投稿前チェックリスト:

    • 内容の完全性(すべてのセクション、図、引用)
    • 書式(投稿先のテンプレート、ページ数の上限、余白)
    • 匿名化(ダブルブラインドの場合)
    • 再現性(十分な詳細、コードの利用可否)
    • 最終的な品質確認(スペルチェック、文法、共著者による確認)
  3. 緊急チェックリスト(締め切りが迫っている場合):

    • 優先項目:アブストラクト、序論の貢献の説明、主な結果を示す表、少なくとも1つのアブレーション、読みやすい図、正確な参考文献一覧

ステージ 5:査読への対応

査読者からフィードバックを受け取った後:

  1. コメントを体系的に分析します。

    • 分類します:重大な問題(実験、明確さ、主張)と軽微な問題(誤字、書式)
    • 優先順位を付けます:まず重大な問題に対応します
  2. 改訂を計画します。

    • 変更する項目をすべて列挙します
    • 実験を求められた場合は、慎重に計画します
    • 明確化が必要な場合は、改訂するセクションを特定します
  3. 改訂して回答します。

    • すべてのコメントに対応します(反論または改訂版で)
    • 丁寧で専門的な口調を用います
    • 変更箇所を明確に示します(投稿先から求められた場合)
  4. 改訂版を確認します。

    • すべての変更が反映されていることを確認します
    • assets/section_checklists.md の関連するチェックリスト(改訂チェックリスト)を再度実行します
    • ページ数の上限を引き続き満たしていることを確認します

参考資料: assets/section_checklists.md(改訂チェックリスト)


主なリソースの概要

論旨と構成
  • references/narrative_framework.md:論文の基本構成(アブストラクト、序論、関連研究、手法、結果、考察、結論)。論旨の展開や、各セクション固有の指針を理解するために使用します。
文単位の明確さ
  • references/sentence_clarity.md:Gopen と Swan の原則(主題の位置、強調の位置、既知から未知への流れ)。文や段落を改訂し、明確さを最大限に高めるために使用します。
学術表現
  • references/phrasebank.md:一般的な学術的文章の機能(研究の紹介、出典の引用、結果の報告、知見の考察)に使えるテンプレート。原稿の執筆や表現に変化を持たせたいときに使用します。
CS の慣例
  • references/cs_conventions.md:分野固有の慣例(表記法、図、引用、コード、サブ分野による違い、投稿先の要件)。CS の文章作法に準拠していることを確認するために使用します。
品質チェックリスト
  • assets/section_checklists.md:すべてのセクションに対応した包括的なチェックリストに加え、提出前、改訂、緊急時のチェックリストも含まれています。計画、レビュー、最終的な品質保証に使用してください。

ワークフローの例

ワークフロー 1:ゼロから始める

ユーザー:「新しい半教師あり学習手法について、学会論文を書きたいです。」

プロセス:

  1. 計画(ステージ 1):

    • 物語の流れを定める:問題(ラベル付きデータは高価)→ 解決策(私たちの半教師あり手法)→ 根拠(3 つのデータセットでの実験)→ 示唆(ラベリングコストを削減)
    • references/narrative_framework.md(基本原則)を読む
    • assets/section_checklists.md(ドラフト作成前の簡易計画チェックリスト)を使用する
  2. ドラフト作成(ステージ 2):

    • アブストラクト:4 文構成(背景:ディープラーニングにはデータが必要、課題:ラベリングは高価、貢献:私たちの手法 STCR、成果:ラベル 10%で精度 82%)
    • 序論:ファネル構成(広い話題:DL の成功 → 焦点を絞る:ラベリングコスト → ギャップ:既存の半教師あり手法には X がない → 貢献:STCR は一貫性を活用 → 結果:7%向上)
    • 各セクションを assets/section_checklists.md に照らして確認する
  3. 改訂(ステージ 3):

    • 各段落に references/sentence_clarity.md の原則を適用する
    • 既知から新しい情報への流れと、ストレス位置の使い方を確認する
  4. 仕上げ(ステージ 4):

    • references/phrasebank.md を使って表現に変化をつける
    • references/cs_conventions.md(ML/AI の慣例)に準拠していることを確認する
    • assets/section_checklists.md の提出前チェックリストを実施する

ワークフロー 2:明確さを高めるための改訂

ユーザー:「序論が分かりにくいです。貢献内容が理解できなかったと査読者に言われました。」

プロセス:

  1. 問題を診断する:

    • assets/section_checklists.md(序論チェックリスト)に照らして確認する
    • 第 4~5 段落までに貢献内容が明確に述べられているか
    • ファネル構成(広い話題 → 焦点を絞る)が守られているか
  2. 必要に応じて再構成する:

    • references/narrative_framework.md(序論のセクション)を読む
    • 次の流れを確認する:導入 → 背景 → ギャップ → 貢献 → 結果 → 構成
    • 次のように明示する:「本論文では、[X] を提示します。これは [Z] によって [Y] に対処するものです。」
  3. 文単位で改訂する:

    • references/sentence_clarity.md の原則を適用する
    • 各文が前の文から自然につながっているか(既知から新しい情報への流れ)を確認する
    • 重要な文は、重要な情報を文末(ストレス位置)に置く

ワークフロー 3:結果セクションのドラフト作成

ユーザー:「実験結果はどのように提示すればよいですか?」

プロセス:

  1. 構成:

    • references/narrative_framework.md(実験/結果セクション)を読む
    • 次の順序に従う:設定 → 主な結果 → アブレーション → 分析 → コスト
  2. 表や図を作成する:

    • 主な結果の表:手法(行)と指標(列)
    • 最良の結果を太字にし、標準偏差を含める
    • references/cs_conventions.md(図表のセクション)を確認する
  3. 説明文を書く:

    • 「表 1 は、私たちの手法が X を達成し、最も強力なベースラインを Y%上回ることを示しています。」
    • 表現には references/phrasebank.md(セクション 4:結果の報告)を使用する
  4. 品質を確認する:

    • assets/section_checklists.md(実験/結果チェックリスト)を一通り確認する
    • 統計的有意性、アブレーションの有無、分析の記載を確認する

ワークフロー 4:CS 準拠の確認

ユーザー:「記法と引用スタイルは ICML の要件に合っていますか?」

プロセス:

  1. 投稿先の要件を確認する:

    • references/cs_conventions.md(セクション 8:投稿先固有のガイドライン)を読みます
    • ICML では番号付き引用 [1]、ダブルブラインド査読、LaTeX テンプレートを使用します
  2. 記法:

    • references/cs_conventions.md(セクション 1:記法と数学的な文章作成)を読みます
    • 次の点を確認します:ベクトルは太字、スカラーは斜体、すべての記号が定義されている
  3. 引用:

    • references/cs_conventions.md(セクション 3:引用と参考文献)を読みます
    • 番号付き形式を使用します:「Method X [1] achieves...」
    • ダブルブラインド査読に備えて、自己引用を匿名化します
  4. 最終確認:

    • assets/section_checklists.md(投稿前チェックリスト → 準拠セクション)

よくある落とし穴と回避方法

落とし穴 1:貢献の曖昧さ

問題:「X で性能を向上させます。」 **解決策:**具体的に記述します。「ImageNet で最も強力なベースラインよりも精度が 15% 高いことを達成します。」

落とし穴 2:アブレーションの不足

**問題:**根拠を示さずに、設計上の選択が重要だと主張すること。 **解決策:**アブレーション研究を含めます。各コンポーネントを取り除き、性能の低下を測定します。

落とし穴 3:情報の流れが悪い

**問題:**文のつながりが悪く、読者が話の流れを見失います。 **解決策:**既知から未知への流れを適用します。各文は、前の文で述べた情報から始めます。 参考: references/sentence_clarity.md

落とし穴 4:文末の強調が弱い

**問題:**文末が引用や重要度の低い詳細になっています。 例: ❌「[23] に示されているように、このアプローチは性能を大幅に向上させます。」 解決策: ✅「[23] に示されているように、このアプローチは性能を大幅に向上させます。」

落とし穴 5:限界を無視する

**問題:**適用範囲や失敗例に触れず、過大に売り込むこと。 **解決策:**考察に、限界について率直に述べる段落を設けます。これにより信頼性が高まります。

落とし穴 6:記法の不統一

**問題:**あるセクションでは入力に x を使い、別のセクションでは X を使うこと。 **解決策:**すべての記法を最初に定義します。必要に応じて、記法の表(付録)を作成します。 参考: references/cs_conventions.md(セクション 1)


効率的に執筆するためのヒント

  1. すばやく下書きし、徹底的に推敲します:

    • 最初の下書きで完璧を目指さないでください
    • まずアイデアを書き出し、その後、構成と明瞭さを磨きます
  2. セクションの順序にこだわらずに書きます:

    • Methods と Results から始めます(最も具体的な部分です)
    • 次に Introduction と Related Work を書きます
    • 最後に Abstract と Conclusion を書きます
  3. 早い段階で図を使います:

    • 執筆前に主要な図(アーキテクチャ、主な結果)を作成します
    • 図によって考えが明確になり、論旨の展開を導けます
  4. 早い段階でフィードバックを得ます:

    • 共著者や同僚に下書きを共有します
    • 模擬査読によって、投稿前に問題を特定できます
  5. 構成を繰り返し見直します:

    • セクションに違和感がある場合は、論旨の流れを見直します
    • すべてのセクションが「問題 → 解決策 → 根拠 → 意義」の展開を進めていることを確認します
  6. チェックリストを積極的に活用します:

    • セクションの下書きを始める前にチェックリストを読み、含める内容を確認します
    • 下書きの後にチェックリストを使い、内容に漏れがないか確認します

応用:特別なケースへの対応

トップクラスの投稿先向けの執筆
  • 新規性と厳密さへの要求が高い:貢献が漸進的なものではなく、重要なものであることを確認します
  • 強力なベースライン:単純な手法だけでなく、最先端の手法とも比較します
  • 包括的な評価:複数のデータセット、幅広いアブレーション、感度分析を実施します
  • 洗練された発表:高品質な図、明確な文章、一貫した記法を用います
反論書の執筆
  • すべての懸念に対応する:異議がある場合でも、敬意を持って向き合います
  • 根拠を示す:査読者が主張に疑問を持つ場合、追加の結果や引用を提示します
  • 簡潔に書く:反論書には厳しい長さ制限があるため、主要な問題を優先します
  • 変更点を強調する:「実験を追加し(表 3)、…を示しました」
論文の章を執筆する
  • より包括的に:背景を深掘りし、関連研究を広げ、得られた教訓を盛り込みます
  • 物語としての連続性:各章がつながるようにします(例:第3章は第2章を踏まえて展開します)
  • より広い範囲:否定的な結果や、うまくいかなかった探索も含められます
  • assets/section_checklists.md(長編論文チェックリスト)を使用します

まとめ:理想的なワークフロー

  1. 物語の流れを計画する:課題 → 解決策 → 根拠 → 意義
  2. セクションごとに下書きする:references/narrative_framework.md の構成ガイドラインを使用します
  3. 明瞭さを高めるために推敲する:references/sentence_clarity.md の原則を適用します
  4. 仕上げて規定に準拠する:references/phrasebank.md と references/cs_conventions.md を使用します
  5. 品質を確認する:assets/section_checklists.md に沿って確認します

覚えておきましょう:

  • 論文はテンプレートではなく、物語です
  • 明瞭さは構成から生まれます(既知から未知への流れ、トピック位置と強調位置)
  • すべての主張には根拠が必要であり、すべての設計上の選択には正当化が必要です
  • 限界を誠実に示すことで、信頼性が高まります

迷ったときは、次の点を確認しましょう:

  • 「これは物語の展開を前に進めているか?」
  • 「読者はこれを再現できるか?」
  • 「この主張には根拠があるか?」
  • 「これを表現する最も簡潔で明瞭な方法か?」

はじめに

新しい論文を書く場合:

  1. references/narrative_framework.md(基本原則)を読みます
  2. assets/section_checklists.md(下書き前の簡易計画チェックリスト)を使用します
  3. 論文の物語の流れを4文(課題、解決策、根拠、意義)でまとめます
  4. チェックリストを確認しながら、セクションごとに下書きします

既存の原稿を改訂する場合:

  1. 問題点(構成、明瞭さ、規定への準拠)を特定します
  2. 該当する参考ファイルを確認します
  3. 系統的に修正を適用します
  4. 適切なチェックリストで再確認します

文レベルの問題について:

  1. references/sentence_clarity.md(3つの黄金律)を読みます
  2. 問題のある各段落に適用します
  3. 既知から未知への流れ、強調位置の使い方、主語と動詞の近さを確認します

執筆の準備はできましたか?一緒に明瞭で説得力のある論文を作りましょう。

コメント