academic-paper-composer

学術論文作成

概要

これは、Codex をベースとする学部ソフトウェア工学論文の執筆および最終仕上げ用スキルです。ストラテジストが作成した、根拠に裏付けられた計画を受け取り、実際のプロジェクトに基づく、整った提出可能な原稿に仕上げます。

連携するフロー：

1. academic-paper-strategist - 構成、根拠の対応表、維持／書き換え／削除する範囲を決定します
2. academic-paper-composer - セクションを書き換え、論文の最終本文を組み立てます
3. drawio - 必要に応じて、エンジニアリングスタイルの図を作り直します
4. playwright - 論文に実行中のシステムの根拠が必要な場合、実際のランタイムスクリーンショットを取得します
5. doc - Word の書式を適用し、最終 DOCX を目視で確認します

このスキルは、論文の本文と最終的な組み立て処理を担います。複製した DOCX、またはユーザーが指定した作業用 DOCX の書式設定と確認が完了するまで、作業完了を宣言してはいけません。

必須入力

• ストラテジストの概要または書き換え指示書
• 既存の論文草稿
• 学校の書式サンプル
• 実際のプロジェクトの根拠ファイル
• 入手可能な場合は検出レポート（類似度／剽窃／AIGC の PDF、スクリーンショット、抽出テキスト）
• 複製した最終 DOCX の正確な保存先、またはユーザーが編集を続けたい作業用草稿の正確なパス
• 提供される場合は、改訂レポートの正確な保存先

絶対に守るルール

• ユーザーが現在手作業で編集した草稿を作業ファイルとして使用すると明示しない限り、複製した草稿のみを対象に作業します。
• ユーザーが手を加えていない元の草稿を上書きしてはいけません。
• 以下を読み、必ず遵守してください。
  • references/zjkj-undergrad-thesis-format.md
  • references/project-grounding-rules.md
  • references/finalization-task-rules.md
• 類似度または AIGC リスクを下げるようユーザーから依頼され、レポートが提供された場合は、references/detection-report-rewrite-playbook.md を読み込んでください。
• 手作業で編集した草稿の続きから作業する場合、一部のセクションを置き換える場合、元の表や図を復元する場合、または実際の実行中システムのスクリーンショットを追加する場合は、references/docx-draft-salvage-and-runtime-screenshot-playbook.md を読み込んでください。
• 作業中の草稿を編集する場合は、編集順序が重要なため、references/thesis-revision-operation-checklist.md を読み込んでください。
• 根拠のない文章は、誤った内容を磨き上げるのではなく、書き換えてください。
• 類似度または AIGC リスクを下げる場合は、プロジェクトの事実を維持しながら表現を書き換えてください。事実を捏造したり、不可欠な内容を削除したりしてスコアを操作してはいけません。
• 原稿内で見える文字はすべて黒にしてください。
• ハイパーリンクのスタイル、作業メモ、説明文、テンプレートのヒントを削除してください。
• プロジェクトの根拠で裏付けられた図とスクリーンショットのみを使用してください。
• 描き直すよりも、根拠に裏付けられた元の図や表を復元することを優先してください。
• テストの章は、慎重かつ根拠に基づいた内容にしてください。

ワークフロー

ステップ 1：安全なコピーの作成

ユーザーから元の草稿と保存先が指定された場合：

• まず元の草稿をコピーします
• 保存先にコピーが存在することを確認します
• 元の草稿には手を加えずに保管します

ユーザーがすでに手作業で編集した草稿を作業ファイルとして指定した場合：

• そのファイルを作業用原稿として扱います
• 構成を変更する前に、タイムスタンプ付きのバックアップを作成します
• 以降の編集はすべて、その作業ファイルに対してのみ行います

いかなる場合も、誤ったファイルに対して直接編集を始めてはいけません。

ステップ 2：書式の基準を抽出

references/zjkj-undergrad-thesis-format.md と、提供された学校のサンプルを読みます。

以下を抽出し、適用します。

• 表紙の構成
• オリジナリティ宣言
• 著作権利用許諾
• 中国語の要旨ページ
• 英語の要旨ページ
• 自動目次
• 見出しの階層
• 本文のタイポグラフィ
• 図表のキャプションスタイル
• 参考文献
• 謝辞
• 付録

ステップ 3：草稿の監査

現在の草稿を確認し、以下の項目に分類します。

• 残す内容
• 書き直す内容
• 削除する内容
• 差し替える図
• 元の草稿から保持する図・表
• 削除する書式上の混入物

具体的には、以下を削除します。

• 色付きのタイトル
• ハイパーリンク形式の見出し
• テンプレートのプロンプト
• 改訂メモ
• 裏付けのないデータに関する主張
• 装飾用の図

ステップ 3A：検出レポートのトリアージ

ユーザーから類似度レポートまたは AIGC レポートが提供された場合は、references/detection-report-rewrite-playbook.md を読んでください。

この段階では、以下を行います。

• 最新のスコアとホットスポットのページを抽出する
• 各ホットスポットをコピーされた草稿内の該当箇所に対応付ける
• 各ホットスポットに大幅な構成の書き直しが必要か、軽微な修正でよいかを判断する

ステップ 3B：既存草稿の続行／救済モード

ユーザーが草稿の一部をすでに手作業で編集している場合、または古い内容を残すよう依頼した場合は、このモードを使用します。

このモードでは、以下を行います。

• 最初に実際に作業する DOCX を特定する
• 次に保護対象のバックアップ／原本 DOCX を特定する
• 目次のテキストではなく、本文の見出しスタイルで差し替え範囲を特定する
• セクションの差し替えの基準として、目次の段落を決して使用しない
• 2.3 などのセクションより前または後の内容だけを差し替えるようユーザーから依頼された場合は、その本文範囲だけを編集する
• 依頼された範囲外にある、変更されていない手動編集を保持する
• 元の E-R 図、表ごとのデータベース説明、または裏付けのあるその他の旧版資産を残すようユーザーから依頼された場合は、再生成せずにバックアップから復元する

ステップ 4：論文本文の書き直し

プロジェクトによって裏付けられた証拠だけを使い、章ごとに書き直します。

各章で扱う一般的な内容は以下のとおりです。

• 序論：背景、意義、範囲、章構成
• 要件分析：役割、ワークフロー、機能要件と非機能要件
• 全体設計：アーキテクチャ、モジュール、データ設計、セキュリティ／制御方針
• 詳細実装：コードと設定に基づく実際の仕組み
• テスト：実際の機能検証と、誇張を避けた要約
• 結論：実際に完了した作業と今後の改善点の要約

各セクションでは、以下を行います。

• 正確なエンジニアリング用語を優先する
• 新規性を誇張する表現を避ける
• 裏付けのない指標を避ける
• 最終的な組み立ての前に、指示文をすべて削除する

類似度または AIGC のリスクを下げる作業が含まれる場合は、以下の書き直しルールを適用します。

• references/detection-report-rewrite-playbook.md に記載された書き直しの原則と変換方法に従う
• 裏付けがない場合を除き、技術的事実、章構成、図表番号、引用を維持する
• 意味の保持を最優先し、スコアの低減は事実の正確性よりも優先度を下げる

ステップ 4A：AIGC／類似度対策の書き直しループ

「10％未満に下げる」などの目標をユーザーが指定した場合：

1. 効果の大きいホットスポットから優先して対処する
2. コピーされた原稿を再構成する
3. ユーザーから新しいレポートが提供された場合は、トリアージ → 書き直し → 再構成のループを繰り返す
4. 後続の作業では、論文全体を再び書き直すのではなく、残っているホットスポットのページだけに取り組む

事前にスコアを保証してはいけません。作成者の責任は、事実を損なわずに安全な低減を最大化することです。

ステップ 5：図、旧版資産、データベースの表

論文に、裏付けのある元の図または表のブロックがすでに含まれており、ユーザーが残すことを希望している場合：

• バックアップ／原本の草稿から保持または復元する
• キャプションのスタイルを学校のサンプルに合わせる
• 必要な場合に限り、後続の図表番号を振り直す

よくある救済事例：

• 元の E-R 図のブロック
• 表ごとのデータベースフィールドの説明ブロック
• 有効な旧版の原稿からすでに抽出されたスクリーンショット
• プロジェクトとの整合性が保たれている元のエンジニアリング図

図が存在しない、裏付けがない、または視覚的に適切でない場合に限り、drawio を使って描き直します。

Step 5A: 実行中のアプリケーションのスクリーンショットを撮影する

論文にシステムの稼働中のスクリーンショットが必要な場合：

• 静的なモックアップを作成するより、実際のアプリケーションを撮影してください
• playwright または同等のブラウザーワークフローを使用してください
• スクリーンショットのアセットは output/playwright/ または同様に明確な出力ディレクトリに保存してください
• スクリーンショットは関連する小節の近くに配置し、短い導入文と論文形式のキャプションを添えてください

メインのデータベースが利用できない場合や、操作にリスクがある場合：

• スクリーンショット撮影専用の一時設定を作成してください
• プライマリの application.yml を変更するより、分離した H2 + Flyway の構成を優先してください
• スクリーンショットに必要な最小限のデモデータのみをシードまたは作成してください
• 撮影後は一時的な実行環境を終了してください

スクリーンショットの適切な撮影対象：

• 認証の章ではログインページ
• 予約フローの章では住民向け予約ページ
• ヘルスコードの章では住民向けダッシュボード／ヘルスコードページ
• 報告の章では住民向け健康報告ページ
• バックエンド運用の章では管理者向け予約／審査ページ
• 運用の概要／稼働状況の節では管理者向けダッシュボード

Step 6: Doc で最終 DOCX の書式を整える

doc を使用して、作業中の .docx を仕上げてください：

• 学校指定の見出しスタイルを適用してください
• すべてのテキストが黒であることを確認してください
• 学校の見本で明示的に指定されていない限り、中国語の見出しを太字にしないでください
• 段落間隔と行間が学校の見本に合っていることを確認してください
• 目次が自動生成であることを確認してください
• 図とキャプションが正しく配置されていることを確認してください
• 参考文献にぶら下げインデントと適切なタイポグラフィを適用してください
• 見本で指定されている場合、項目説明の表に適切な小さいフォントを適用してください
• 可能であれば、ページをレンダリングして視覚的に確認してください

Step 7: 別途、修正報告書を作成する

修正報告書は最終論文の外部に置き、次の内容を記載できます：

• 削除または弱めた主張
• 引用・維持しなかった、根拠のないデータ
• 手動での確認が必要な項目
• 図の再作成に関するメモ
• 書式の修正
• 類似性／AIGC 対応の場合：問題のあるページ、採用した書き換え方針、次回の報告で引き続き再確認が必要な点
• 修復作業の場合：バックアップから復元した節、新たに撮影したスクリーンショット、意図的に保持した手動編集

これらの内容を最終 DOCX の本文に混入させないでください。

Step 8: 最終セルフチェック

以下のすべてを満たすまで提出しないでください：

• 元の草稿が未変更であるか、ユーザーが指定した作業用草稿によって明示的に置き換えられている
• 構成を変更する前に作業用 DOCX のバックアップが作成されている
• 目次の段落を本文のアンカーと誤認していない
• すべての見出しと本文のテキストが黒である
• 青いタイトルが残っていない
• すべての図とスクリーンショットが論文のスタイルに合っている
• ユーザーから保持または復元を求められた既存の図表が維持または復元されている
• 作業手順や指示のテキストが残っていない
• 学校の書式見本に従っている
• 目次が自動生成である
• 原稿が提出可能な状態である

正確性を重視した慎重な執筆ルール

• 根拠のない「性能評価」は、適切な場合、「機能検証」または「シナリオベースのテスト」に置き換えてください。
• 正式な負荷テストがない場合、性能ベンチマークの表を作成しないでください。
• 実際のデプロイがない場合、クラスターへのデプロイ、本番運用、同時実行の規模に関する主張は避けてください。
• モジュールが設定済みでも十分に実証されていない場合、大規模な能力が証明されたかのように記述せず、実装済みのサポート機能として慎重に説明してください。
• AIGC リスクの高い段落では、「いくつかの単語を置き換える」より「文全体の論理を組み直す」ことを優先してください。
• 文章が洗練されたテンプレートのように読める場合は、正確さを損なう前に、文章の洗練度を下げてください。文の長さに変化をつけ、定型的なつなぎ表現を取り除き、実際のリポジトリに基づいた表現にしてください。

必要に応じて読み込む参考資料

• references/zjkj-undergrad-thesis-format.md
• references/project-grounding-rules.md
• references/finalization-task-rules.md
• references/detection-report-rewrite-playbook.md
• references/docx-draft-salvage-and-runtime-screenshot-playbook.md
• references/thesis-revision-operation-checklist.md
• references/chinese-call-prompt-templates.md
• references/section_guides.md
• references/writing_standards.md

プロンプトの例

• 手作業で修正した初稿を引き続き修正してください。本文の「1 はじめに」から「2.3」の直前までだけを置き換え、目次を基準にしないでください。
• 元のデータベース E-R 図と各テーブルのフィールド説明表を残し、定稿に対応する内容を working draft に戻してください。
• この最新の AIGC レポートに基づいて、残りのホットスポットページだけを修正し、10% 未満に下げてください。全文を書き直さないでください。
• 学校のテンプレートに従って、現在の working docx を最終版に整えてください。タイトルは太字にせず、全文を黒色にし、テーブルのフィールド説明は五号にしてください。
• 論文にシステムの実行画面のスクリーンショットを追加してください。スクリーンショットは実際のプロジェクト画面から取得し、修正内容の説明を別途出力してください。

出力要件

次のものを作成してください：

• 整理済みの論文原稿
• コピーしたドラフトまたはユーザー指定の作業用ドラフトで実行した、DOCX の最終版作成ワークフロー
• 別途作成した修正レポート

著者へのコメント、修正メモ、レビュー注記を原稿の内容として扱わないでください。