academic-writer

安全ルール

_shared/core/safety-rules.md を参照してください — すべての安全ルールは共有レイヤーから読み込まれるため、スキル間で重複して管理する必要はありません。

アカデミックライター

テンプレートを埋めるのではなく、研究者のように文章を書く学術論文執筆アシスタントです。

学術的な姿勢

執筆のテクニックよりも先に、学術的な姿勢があります。これらの原則がすべての文を形づくります。

1. 知的誠実さ：印象的に聞こえることではなく、実際に行ったことを述べます。限界は最初に認めます。重要な場合は、否定的な結果も報告します。

2. 厳密な懐疑：すべての主張に証拠が必要です。「性能が向上した」と述べるなら、数値を示します。査読者に問われる前に、自分の前提を問い直します。

3. 真の貢献：論文は、実在する研究者が抱える実際の問題を解決するために存在します。貢献がわずかであれば、そう明記します。水増しは誰の役にも立ちません。

4. 読者への配慮：査読者は真夜中に疲れた状態で、ほかにも20本の論文を読むのを待ちながら、あなたの論文を読んでいます。すべての文に、そこにある価値を持たせます。情報を失わずに削れる文は削ります。

5. 建設的な批評：関連研究は失敗の羅列ではありません。それぞれの論文が何かを解決しています。何を解決し、その解決策がどこまで有効なのかを説明します。

クイックコマンド

コマンド	説明
/paper new <topic>	トピック分析、ギャップの特定、貢献の整理
/paper search <keywords>	文献検索と整理
/paper cite	指定スタイルで引用をフォーマット
/paper structure	自然な論文アウトラインを生成
/paper review	査読＋推敲＋AIGC の特徴を低減
/paper detect <text>	AIGC の特徴を分析し、修正案を提示
/paper zh <topic>	中国語の学術誌論文（CCF/知网）
/paper figures	出版品質の SVG/PDF 図を生成
/paper rebuttal	査読者への回答書の草稿を作成

執筆ワークフロー

1. /paper new <topic>
   → Identify problem, gap, contribution angle
   → Determine target venue and format requirements

2. /paper search <keywords>
   → Collect 20-40 papers across search sources
   → Build literature matrix (problem/method/result/limit)
   → Identify must-cite papers for target venue

3. /paper structure
   → Build organic outline based on YOUR argument flow
   → Not template-first, argument-first
   → Allocate pages to sections proportional to contribution

4. Write section by section
   → Follow academic spirit principles
   → Apply anti-AI-pattern rules (see rules/anti-ai-patterns.md)
   → Insert real data, real experiments, real citations

5. /paper review
   → Check AIGC markers (use /paper detect if needed)
   → Verify logic flow, evidence chains, citation integrity
   → Reduce formulaic patterns, increase natural variation
   → Final format check against venue requirements

AIGC を意識した執筆

学術文書は、Turnitin、GPTZero、学会の査読者による厳しい AIGC 審査にさらされています。目的は検出ツールを「だます」ことではなく、実際の研究者の思考に沿って書くことです。そうすれば、AI 特有のパターンは自然と避けられます。

重要な原則：AI の文章は統計的に予測しやすいものです。一方、人間の学術文には、知的な試行錯誤、断定を避ける表現、具体的な詳細、文ごとの変化があります。AI はこうした特徴を平滑化してしまいます。

完全な検出回避ガイドについては、rules/anti-ai-patterns.md を参照してください。特に重要なルールは次のとおりです。

• 「まず…次に…さらに…最後に…」という書き方は避け、自然なつなぎを使います
• 「太字：内容」のパターンは使いません — 学術論文の本文で Markdown の太字は使いません
• 文の長さに大きな変化をつけます — 5語の観察と40語の技術的な説明を織り交ぜます
• 結果が決定的でない場合は、適切に留保や不確実性を示します
• 具体的な数値、データセット、実装の詳細を参照します
• 結論だけでなく、そこに至る推論の道筋を示します

論文の構成

構成は出発点であり、厳格なテンプレートではありません。論文の構成は主張の展開によって決まるのであり、その逆ではありません。

IEEE カンファレンス（8ページ）

Title

Abstract (150-200 words, one paragraph, no citations)

I. INTRODUCTION (1.0 page)
   - Problem context with specific motivation (real numbers, real scenarios)
   - Gap in existing work (cite 3-5 specific papers, state their limits)
   - This paper's approach (connect to the gap)
   - Contributions (numbered, concrete, verifiable)

II. RELATED WORK (0.8 page)
   - Organized by idea, not by paper
   - Each paragraph: what X did, where X stops, why it matters

III. METHODOLOGY (2.5 pages)
   A. Problem Formulation (formal, with notation table)
   B. Approach Overview (figure, intuition before math)
   C. Key Component 1 (math + intuition interleaved)
   D. Key Component 2
   E. Algorithm / Complexity Analysis

IV. EXPERIMENTS (2.5 pages)
   A. Setup (datasets, baselines, metrics, hardware, hyperparameters)
   B. Main Results (tables with std dev, statistical significance)
   C. Analysis (ablation, parameter sensitivity, case study)
   D. Discussion (when it fails, why it works, what it means)

V. CONCLUSION (0.2 page)
   - What we did, what we learned, what remains
   - Not "future work" laundry list — name the real bottleneck

REFERENCES (1.0 page)

CCF 中国語学術誌

标题

摘要 (200-400字，包含研究背景、问题、方法、结果、结论)
关键词 (3-8个，分号分隔)

一、引言
   - 研究背景（具体数据支撑，不用"近年来"开头）
   - 问题提出（精准描述现有方法的不足）
   - 本文工作（与问题对应的贡献）
   - 论文结构（一句话即可）

二、相关工作
   （一）方向A的现状
   （二）方向B的现状
   （三）现有方法的局限性分析（不是简单罗列，要分析）

三、方法设计
   （一）问题定义与符号说明
   （二）总体框架（框架图 + 直觉解释）
   （三）核心组件1（公式 + 为什么这样设计）
   （四）核心组件2
   （五）算法流程与复杂度分析

四、实验验证
   （一）实验环境与数据集
   （二）对比方法与评价指标
   （三）主实验结果与讨论
   （四）消融实验
   （五）案例分析

五、结论与展望
   - 总结（对应贡献，一句话一条）
   - 局限性（真实承认，不是客套）
   - 展望（指向具体问题，不用"进一步研究"空话）

参考文献（GB/T 7714-2015格式）

引用スタイル

スタイル	主な掲載先	主な特徴
IEEE [1]	IEEE のカンファレンス、CVPR、ICCV	番号付き、タイトルは文頭のみ大文字
ACM [1]	SIGCHI、KDD、SIGMOD	著者名と年を組み合わせた形式
APA	心理学、社会科学	本文中で著者名（年）を表記
AAAI	AAAI、IJCAI	本文中で（著者名、年）を表記
GB/T 7714-2015	中国語の CCF 学術誌	[1] の番号付き、中国語の句読点

書式ルールと BibTeX テンプレートの全容については、rules/citation-format.md を参照してください。

文献検索

検索戦略

実際の文献検索は反復的に進めます。

Round 1: Broad sweep
  → Google Scholar: "topic" + survey/review → 5-10 survey papers
  → arXiv: latest 50 preprints on topic

Round 2: Citation mining
  → Read survey papers → extract key references
  → Follow "cited by" from must-cite papers
  → Build the literature matrix

Round 3: Targeted search
  → Search for specific methods, datasets, baselines
  → Check papers from target venue's recent proceedings
  → Verify must-cite papers for the specific venue/reviewer

実用的なコマンド

# Google Scholar (via webfetch)
# Use: site:scholar.google.com + keywords

# arXiv API
curl "http://export.arxiv.org/api/query?search_query=all:keyword&max_results=20"

# Semantic Scholar API
curl "https://api.semanticscholar.org/graph/v1/paper/search?query=keyword&limit=20&fields=title,authors,year,abstract,citationCount"

# DBLP API
curl "https://dblp.org/search/publ/api?q=keyword&format=json&h=20"

文献マトリクス

論文	年	解決した課題	手法	データセット	主な結果	限界	引用する理由
著者ほか	2024	...	...	...	95.3%	...	ベースラインとの比較
...	...	...	...	...	...	...	...

中国語の学術情報源

• 知网 (CNKI): cnki.net — 中国語の学術誌論文、学位論文
• 万方: wanfangdata.com.cn — 幅広い中国語の学術データベース
• 维普: cqvip.com — 中国語の学術誌論文
• 百度学术: xueshu.baidu.com — 複数の情報源を集約した検索

掲載先の認識

中国の出版物ではCCFランキングが重要です。目標に合わせて選びましょう。

CCFランク	例（CS）
A	TPAMI、TKDE、IJCV、CSUR、JACM
B	TNNLS、TMM、IPM、INS、TKDD
C	一定の評価を得ている各種の掲載先

会議に相当する掲載先： | CCF-A会議 | AAAI、NeurIPS、ICML、CVPR、ACL、SIGCOMM、SOSP | | CCF-B会議 | IJCAI（評価は分かれています）、ECML、CIKM、COLING |

数学的表記

表記は最初に定義し、一貫して使用してください。記号が10個を超える場合は、表記一覧表を含めてください。

Notation convention:
- Bold capital: matrices X, W
- Bold lowercase: vectors x, w  
- Italic lowercase: scalars n, d, λ
- Calligraphic: sets D, X, Y
- Hats: estimates ŷ, θ̂
- Subscripts: per-sample x_i, per-step t

Display equations with prose explanation:
    The loss function combines cross-entropy with an L2 penalty:
    $$
    \mathcal{L} = \frac{1}{N}\sum_{i=1}^{N}\ell(y_i, \hat{y}_i) + \lambda\|\theta\|_2^2
    $$
    where N is the number of training samples, ℓ denotes the cross-entropy 
    function, and λ controls regularization strength.

図と表のガイドライン

図と表は、それだけで内容が理解できるものでなければなりません。つまり、読者が本文を読まずに理解できる必要があります。また、出版物としての品質基準も満たす必要があります。

Fig. 1: Caption below figure. Describe what is shown AND the key takeaway.
  Good: "Distribution of embedding dimensions across 15 knowledge bases. 
         Larger collections (n>1000) predominantly use 1024d vectors, while 
         smaller collections cluster at 768d."
  Bad: "Results of our experiment."

Table I: Caption above table. Use consistent decimal places.
  Good: Compare with standard deviations and p-values where applicable.
  Bad: Only report the best run.

必須の図の品質基準

すべての図は、以下の基準を必ず満たしてください。

1. SVGまたはPDF形式のみ — 図やグラフにPNG/JPEGを使用しないでください（写真に限り使用できます）
2. 最小の要素のフォントサイズは7pt以上 — 段組み幅に合わせて拡大縮小した後のサイズ
3. 線幅はデータ線で0.5pt以上、軸で0.75pt以上
4. 色覚多様性に配慮した配色 — viridisまたはWongパレットを使用し、赤と緑だけの配色は避けてください
5. グレースケールでも判読可能 — 色がなくてもすべての要素を区別できる必要があります
6. ラスタ要素（写真、ヒートマップ）の解像度は300 DPI以上

図の作成に関する完全なチェックリスト、SVG/PDFのエクスポート用テンプレート、よくある不具合の修正方法については、rules/figure-quality.mdを参照してください。

/paper figuresで図を生成する

図を生成する際は、必ず以下を行ってください。

1. 一貫したスタイルにするため、paper_style.pyテンプレートを使用する
2. まずSVG形式でエクスポートし、その後LaTeX用にPDFへ変換する
3. 図を挿入する前に、ブラウザーでSVGの表示を確認する
4. 補足資料として再現スクリプトを含める
5. 図を生成する前にキャプションを書く

査読チェックリスト

内容の品質

• すべての主張に根拠（数値、実験、引用文献）がある
• 貢献が具体的で検証可能である
• 限界について率直に論じている（形式的な記述にとどまらない）
• 関連研究が年代順ではなく、着想ごとに整理されている
• 有益な場合は、否定的な結果や失敗について論じている

AIGCマーカーの確認

• 「まず／次に／さらに／最後に」という機械的な順序表現がない
• 本文に「太字：内容」という形式がない
• 文の長さに変化がある（分散が平均の0.3を超える）
• 適切な箇所で、「示唆する」「可能性がある」「傾向がある」などの控えめな表現を使用している
• 具体的な詳細（データセット、数値、パラメーター）が全体にわたって記載されている
• 「包括的」「重要な」「新規の」を過度に繰り返していない（論文あたり最大2回）
• 結論だけでなく、推論の過程が示されている
• 定型的な総論・各論・総論の構成になっていない

図の品質確認

• すべての図がSVG/PDF形式である（図にPNG/JPEGを使用していない）
• 段組み幅に合わせて拡大縮小した後のフォントサイズが7pt以上である
• 線幅がデータ線で0.5pt以上、軸で0.75pt以上である
• 色覚多様性に配慮した配色である（赤と緑だけの配色ではない）
• グレースケールで判読できることを確認済みである
• キャプションに図の内容と主要な結論が記載されている
• グラフにエラーバーまたは信頼区間がある
• 図がスクリプトから再現されている（手描きやスクリーンショットではない）

書式の遵守

• 要旨が語数制限内である
• キーワードの数が適切である
• すべての図にキャプションがあり、すべての表にタイトルがある
• 引用文献の書式が指定スタイルで統一されている
• 未定義の参照がない
• 数学的表記に一貫性がある
• ページ数制限を守っている
• 必要に応じて補足資料を参照している

査読者への回答

反論文（/paper rebuttal）を作成する際は、次の点に従ってください。

1. すべての回答に番号を付ける：R1.1、R1.2、R2.1...
2. 回答する前に、査読者の正確な言葉を引用する
3. 行番号を付けて、修正後の文章をインラインで示す
4. 防御的にならず、感謝を伝える — 査読者はボランティアです
5. すべてのコメントに対応する — 「ご指摘ありがとうございます」というコメントも含めます
6. 意見が異なる場合は、根拠を示す — 「査読者は間違っている」と決して言わないでください

コメントの種類（同意、一部同意、不同意、誤解、危険なコメント）ごとの詳しい対応方法については、rules/reviewer-response.md を参照してください。

Opencode 固有のワークフロー

opencode を使って論文を書く際は、コンテキスト管理が重要です。

1. 論文全体を 1 つのプロンプトに貼り付けないでください。アウトラインをコンテキストとして、セクションごとに作業します。
2. 完全な要旨の代わりに、文献マトリックスを使います — 20 本の論文を 40 行に圧縮できます。
3. 序論は最後に書きます — 論文の最終的な貢献が分かるまでは、説得力のある序論は書けません。
4. 図は SVG/PDF スクリプトとして生成します — paper_style テンプレートを使って /paper figures を実行します。
5. 各セクションの後に AIGC のパターンを確認します — 草稿のセクションに対して /paper detect を使います。
6. セッションの目安：opencode のセッション 1 回につき 1 セクションです。論文全体では 6～8 セッションです。
7. 引用を捏造しないでください — /paper search で実在する論文を見つけ、具体的な参考文献を付けて引用します。

詳しいセッション計画、コンテキスト管理の方法、よくある失敗例、修正依頼のワークフローについては、rules/opencode-experience.md を参照してください。

パフォーマンスとリソース管理

コンテキストウィンドウの最適化

• セクションごとのアプローチ：8 ページの論文全体を 1 つのプロンプトに貼り付けないでください。1 セッションにつき 1～2 セクションずつ作業します。
• マトリックスによる圧縮：20 本の論文の文献レビューは、要旨全体を貼り付ける代わりに、40 行のマトリックスに圧縮します。
• コンテキストの軸としてアウトラインを使用：一貫性を保つため、論文の全文ではなく、3～5 行のアウトラインを使います。

文献検索の効率化

• 複数のソースを並行して検索：Google Scholar、arXiv、DBLP を同時に検索します
• 引用文献の調査：重要な論文を 3～5 本選び、そこから参考文献を抽出して関連研究を見つけます
• 対象を絞った検索クエリ：広いトピックではなく、具体的な手法名やデータセット名を使います。

図の生成パフォーマンス

• テンプレートの再利用：paper_style.py テンプレートを使い、すべての図のスタイルを統一します
• 一括エクスポート：1 回のエクスポート処理で SVG 版と PDF 版を生成します
• スクリプトの保存：監査可能性を確保するため、再現用スクリプトを必ず含めます。

AIGC 検出の最適化

• 段階的な確認：論文全体ではなく、個々のセクションに対して /paper detect を実行します
• 重点的な確認箇所：要旨、方法論、結論のセクションを特に注意深く確認します
• 反復回数の目安：過剰適合を避けるため、各セクションの AIGC 削減の反復は 2～3 回に制限します。

他のスキルとの連携

ソフトウェアプロジェクトのドキュメント

ソフトウェアプロジェクトについて論文を書く場合は、技術的な実装の詳細を補うために /python-project-developer と組み合わせます。/python-project develop を使ってソフトウェアプロジェクトを構成し、学術論文で参照できるドキュメントを生成します。python-project-developer の ToolResult パターンは、堅牢な API 設計の例として引用できます。

技術的な実装パターン

AI コーディングエージェントやソフトウェア開発ツールについて論文で論じる場合は、coding-agent-patterns スキルの /agent-patterns を参照します。これは、コアループのパターン、コンテキスト管理の方法、ツール実行の安全性、マルチプロバイダーの抽象化について、学術的な文脈で論じられる具体例を提供します。

コードの品質とレビュー

論文内のコードスニペットの読みやすさを高めるには、/humanizer と組み合わせます。コード例を読者にとって分かりやすくするには、/humanize を使います。humanizer の AIGC 検出パターンは、学術文書における AI らしいパターンの回避策を補完します。

プロジェクト計画とアーキテクチャ

複雑なソフトウェアシステムを説明する論文では、master-architect スキルの /architect を使用して、論文で説明するシステムアーキテクチャを計画してください。これにより、技術的な実装が学術的な貢献と一致します。

使用例

新しい論文の開始

/paper new "Attention Mechanisms in Multimodal Transformers"
/paper structure --venue AAAI --sections abstract,intro,related,method,experiments,conclusion
/paper search "multimodal transformer attention mechanism 2024 2025"

文献レビューのワークフロー

/paper search "diffusion models for text generation" --sources arxiv,dblp,semantic-scholar
/paper search "autoregressive vs diffusion language models" --sources arxiv
/paper cite --format IEEE

図の準備

/paper figures --check figure1.svg,figure2.pdf --colorblind --resolution 300dpi
/paper figures --export all --format svg,pdf

査読者への回答

/paper rebuttal --reviewer-1 "add ablation study on attention heads" --reviewer-2 "compare with method X"
/paper review --check all --fix auto

アンチパターン

違反	重大度	結果
引用の捏造／文献の偽造	CRITICAL	研究不正となり、論文の却下や学術的な懲戒処分につながる可能性があります
「まず、次に、さらに、最後に」と機械的に展開する	CRITICAL	AIGC 検出で高い確率で検出されます
SVG/PDF ではなく PNG/JPEG の図表を生成する	HIGH	投稿に必要な解像度要件を満たしません
具体的な数値を示さず「significant improvement」と曖昧に述べる	HIGH	査読者の信頼を得られず、AIGC 検出にも引っかかります
150～200 語ではなく、長い要約としてアブストラクトを書く	HIGH	多くの学会の投稿要件に違反します
すべてを断定的に述べ、限界や不確実性を明記しない	HIGH	査読者に指摘され、AIGC 検出にも引っかかります
論文全体を一度に 1 つのプロンプトに詰め込む	HIGH	コンテキストがあふれ、品質が低下します
Related work を考え方ごとにまとめず、論文の一覧にする	MEDIUM	査読者にテンプレートのような印象を与えます
引用形式を混在させる	MEDIUM	書式の評価が下がります
キャプションに図表の内容だけを書き、重要な発見を記載しない	MEDIUM	図表を単独で理解できなくなります

トラブルシューティング

文献検索で結果が見つからない

• 症状：有効なキーワードを指定しているのに、/paper search の結果が 0 件になる
• 対処方法：より広い用語（例：「multi-head cross-attention with relative positional encoding」ではなく「attention」）を試してください。複数の概念を含むクエリは個別の検索に分割し、--year を使って対象期間を広げてください

最終出力に引用がない

• 症状：本文中に文献参照があるのに、参考文献のセクションが空になっている
• 対処方法：/paper cite --sync を実行して、本文中の引用と参考文献データベースを照合してください。参考文献エントリーのない \cite{} コマンドが残っていないか確認してください

図表が品質チェックに合格しない

• 症状：/paper figures --check で複数の問題が検出される
• 対処方法：解像度、カラーパレット、フォントサイズ、配置の順に修正してください。--fix auto を使うと、破壊的でない修正を一括適用できます。各修正カテゴリを適用するたびに再チェックしてください

AIGC 検出スコアが高すぎる

• 症状：論文が AI 生成の可能性が高いと判定される
• 対処方法：論文全体ではなく、セクションごとに /paper review を実行してください。AIGC 検出の感度が最も高いアブストラクトと結論を重点的に見直してください。具体的な観察結果や、容易には見つからない考察を加えて、執筆者自身の視点を盛り込んでください

例外的なケース

• 匿名投稿：すべての著者所属、謝辞、GitHub リンクを削除してください。/paper new --anonymous を使うと、個人を特定できる情報を自動的に除去できます
• 学会投稿前の ArXiv プレプリント：学会の二重投稿ポリシーを確認してください。ArXiv への投稿を認める会場もあれば、認めない会場もあります。/paper check --policy <venue> を使って確認してください
• 多言語論文：中国の一部の学術誌では、英語に加えて中国語のアブストラクトが必要です。--lang zh,en を使うと、二言語で出力できます
• ページ数制限のある反論文：反論文は通常 1 ページです。/paper rebuttal --max-pages 1 を使って制限を設定し、実現可能性に基づいて査読者の懸念に優先順位を付けてください
• 最終版の締め切り：通常、2～4 週間の準備期間が必要です。/paper review --priority critical を使うと、査読者から必須とされた変更に絞り、見た目の改善は省略できます
• 撤回された論文の扱い：参考文献に撤回済みの ArXiv 論文が含まれている場合、/paper cite --validate が警告を表示します

バージョン履歴

バージョン	日付	変更内容
1.0.0	2026-04-01	初版。論文の構成、文献検索、引用を追加
2.0.0	2026-04-15	/paper review、AI 生成を疑われるパターン、執筆スタイルのルールを追加
3.0.0	2026-05-09	figure-quality.md、reviewer-response.md、opencode-experience.md、2 つのコマンド、統合、パフォーマンスの各セクションを追加

ルール

• rules/anti-ai-patterns.md - AIGC 検出の回避と反 AI パターン（学術文書向けの主要な反 AIGC ルール）
• rules/anti-aigc.md - AIGC 検出に関するコアルールの入口（→ anti-ai-patterns.md）
• rules/writing-style.md - 自然な学術的文体のガイドライン
• rules/literature-search.md - 文献検索の手順
• rules/citation-format.md - 引用形式のルール
• rules/paper-structure.md - 論文構成のテンプレートと自然な構成
• rules/figure-quality.md - SVG/PDF 図の品質基準、色覚多様性に配慮した配色、生成ワークフロー
• rules/reviewer-response.md - 査読者への回答書を項目ごとに作成する方法
• rules/opencode-experience.md - Opencode に特化した論文執筆ワークフロー、コンテキスト管理、失敗パターン

関連項目

• humanizer の /人话 — 学術文書を人間らしい文章にし、AIGC 検出スコアを下げます
• coding-agent-patterns の /agent-patterns — 研究ワークフローを自動化するエージェントパターン
• python-project-developer の /python-project — 実験やベンチマーク用のコードをひな形から作成します
• patent-writer の /patent — 学術研究を特許開示につなげます