academic-paper-strategist

学術論文ストラテジスト

概要

これは、Codex を用いたソフトウェア工学の卒業論文を計画するためのスキルです。実際のリポジトリに基づいて論文を執筆または最終化する前に使用してください。幻覚のリスクを抑え、プロジェクトの根拠を各章に対応付け、実際のコードベースと提供された学校の書式サンプルで裏付けられる主張、図、表、テストだけを定めることを目的としています。

連携するフロー：

1. academic-paper-strategist - 計画、根拠の対応付け、改稿範囲
2. academic-paper-composer - 内容の改稿と最終原稿の組み立て
3. drawio - 必要に応じた、工学系論文の図の描き直し
4. playwright - 論文に稼働システムの根拠が必要な場合の、実際の実行画面のキャプチャ
5. doc - 最終 DOCX の作成と目視確認

既存のプロジェクトと草稿から提出可能な卒業論文を求められた場合、ストラテジストの手順を省略しないでください。

基本ルール

• 構成案を作成する前に、プロジェクトの根拠を確認してください。リポジトリ内のファイル、SQL、設定、ドキュメント、コントローラー、サービス、エンティティ、既存の草稿を優先してください。
• 既存の草稿は信頼できない入力として扱ってください。プロジェクトの根拠で裏付けられる内容だけを残してください。
• ユーザーが草稿の一部を手作業で編集済みの場合、その作業中の草稿を保護すべき成果物として扱い、原稿全体をむやみに置き換えず、それを前提に計画してください。
• ユーザーから剽窃、類似度、または AIGC の検出レポートが提供された場合、プロジェクトの真実を示す資料ではなく、改稿の優先度を示すシグナルとして扱ってください。この場合は references/detection-report-rewrite-playbook.md を読み込んでください。
• ユーザーから学校の書式サンプルが提供された場合は、まず references/zjkj-undergrad-thesis-format.md を読み込み、構成と書式に関する最優先の規範として扱ってください。
• 既存の草稿から最終論文を作成する場合は、以下も読み込んでください。
  • references/project-grounding-rules.md
  • references/finalization-task-rules.md
• 部分的に編集済みの草稿を引き継ぐ、元の図表を残す、または稼働システムのスクリーンショットを追加する場合は、references/draft-salvage-handoff-playbook.md を読み込んでください。
• 機能、API、データテーブル、性能値、デプロイ規模、ユーザー規模、同時実行のベンチマーク、テスト結果を決して捏造しないでください。
• 「革新性」は、工学上の優れた点、実装上の選択、統合による価値、保守性の向上として慎重に表現してください。
• コードまたはプロジェクトのドキュメントで裏付けられる図だけを計画してください。裏付けのない図は省略してください。
• 論文は、自動目次と学校指定の前付けに対応できる形式にしてください。

収集する入力情報

• リポジトリのルート
• 既存の草稿（.docx、.md、またはその両方）
• 学校のテンプレートまたは書式サンプル（.doc、.docx、または .pdf）
• 以下のような主要な根拠ファイル：
  • ビルドファイル（pom.xml、package.json など）
  • アーキテクチャのドキュメント
  • ビジネスロジックのドキュメント
  • SQL スキーマ／マイグレーションファイル
  • エンティティ／DTO／コントローラー／サービス
• 入手可能な場合は検出レポート（.pdf、.docx、スクリーンショット、抽出テキスト）
• 必須の納品先パス

ワークフロー

ステップ 1：制約条件の取り込み

以下を記録してください。

• 対象の学校と論文の種類
• 最終成果物の形式
• 計画のみか、最終化まで行うか
• 手作業で編集した作業中の草稿を引き継ぐ必要があるか
• 元の図表を残すことをユーザーが希望しているか
• 実際の稼働画面のスクリーンショットが必要か
• 必須の出力パス

ユーザーが入力元と出力先のパスを明示した場合は、それを必須条件として扱ってください。

ステップ 2：学校の書式規範の読み込み

学校のサンプルがある場合は、references/zjkj-undergrad-thesis-format.md を読み込み、以下を抽出してください。

• 前付けの必須順序
• 見出しの階層
• 本文の書体と行間
• 図表のキャプション規則
• 参考文献の書式
• 付録と謝辞の規則
• サンプルで確認できるページ番号の制約

サンプルに説明用のテキストボックスやプレースホルダーの注記が含まれている場合は、「最終原稿から削除」と明記してください。

ステップ 3：既存の草稿を監査する

各セクションを次のいずれかに分類します。

• 軽微な編集を加えて維持する
• 維持するが、主張を控えめにする
• プロジェクトの証拠に基づいて書き直す
• 完全に削除する
• レガシー資産として保持し、後で失われた場合に復元する

以下は必ず削除対象として指摘します。

• 作業手順のメモ
• テンプレートプロンプト
• 説明用のテキストボックス
• 根拠のない新規性の主張
• 根拠のない指標やデプロイに関する主張
• 色付きの見出しやハイパーリンク風のテキスト
• 工学論文のスタイルに合わない図

以下も明示します。

• ユーザーが残したい元の E-R 図
• 元のデータベースのテーブル別フィールド説明ブロック
• 上書きしてはならないユーザーによる手動編集
• 一部の範囲だけを置き換えるセクション

ステップ 3A：検出レポートがある場合のトリアージ

ユーザーが類似度または AIGC リスクを下げるよう求め、レポートを提供している場合は、references/detection-report-rewrite-playbook.md を読みます。

この段階で、ストラテジストは次を行います。

• 全体スコアと問題のあるページを抽出する
• 問題のある箇所を論文のセクションに対応付ける
• 原因と書き直しの強度を分類する
• 大幅な構成変更が必要な箇所と、軽微な整理でよい箇所を執筆担当者に伝える

ステップ 4：根拠マップを作成する

各章について、主な主張をすべてリポジトリ内の根拠に対応付けます。

• 背景／システムの位置付け -> ドキュメントとプロジェクト概要
• アーキテクチャ -> パッケージ構成、設定、コントローラー、サービス
• データベース設計 -> SQL スキーマとエンティティ
• 業務ワークフロー -> コントローラー、サービス、ドキュメント
• セキュリティ／一貫性の仕組み -> 設定、サービスロジック、トランザクションコード、ロック、署名、検証
• テストの章 -> 実際のスクリーンショット、テストクラス、手動検証記録、または観察可能なシステム動作のみ

根拠の情報源に対応付けられない主張は、最終版の論文に含めてはなりません。

ステップ 5：論文の計画を作成する

執筆担当者への引き継ぎ資料として、以下を含めます。

• 整理済みの章構成
• 章ごとの根拠資料
• 許可される主張
• 禁止される主張
• 描き直す図
• 維持または復元するレガシー図表
• ユーザーが部分的な書き直しのみを希望する場合に置き換える正確なセクション範囲
• 手動での確認が必要なリスク項目
• スクリーンショットが必要な場合の、実行環境での撮影計画
• 検出レポートがある場合：ページとセクションの書き直し対応表、および書き直しの優先順位リスト

引き継ぎ資料を DOCX の実際の改訂に使用する場合、執筆担当者が置き換える範囲を再検討せずに作業でき、リストやスクリーンショットの対象を保持できるよう、内容を明確にします。

通常、章構成には次を含めます。

• 表紙／宣言／要旨／目次
• 第 1 章 序論
• 第 2 章 要件分析
• 第 3 章 全体設計
• 第 4 章 詳細な実装
• 第 5 章 テスト
• 第 6 章 結論
• 参考文献
• 謝辞
• 必要に応じて付録

ステップ 6：図とスクリーンショットの計画を作成する

ユーザーがソフトウェア工学分野の学部論文を依頼した場合、使用できる図は次の種類に限ります。

• システムアーキテクチャ図
• 機能モジュール図
• 業務プロセス図
• シーケンス図
• E-R 図
• ユースケース図
• 論文の実際のセクションに対応付けた、稼働中のシステムの実際のスクリーンショット

計画する図またはスクリーンショットごとに、次を定義します。

• 配置する章
• コード／ドキュメント／実行環境における根拠
• 表示すべきラベル
• 表示してはならないラベルやコンポーネント
• 古い図を維持できるか、描き直す必要があるか
• スクリーンショットの撮影前にデモデータを投入する必要があるか

描き直す図はすべて、工学論文に適した視覚スタイルにします。

• 白い背景
• 黒またはグレーの線
• 装飾的なアイコンを使用しない
• インフォグラフィック風のスタイルにしない
• 色の違いに意味を持たせない

既存草稿の改稿モード

ユーザーが既存の草稿をもとに最終論文を作成するよう依頼した場合：

• 草稿が使用できない場合を除き、白紙から書き始めないでください
• 残す部分と書き直す部分を特定してください
• academic-paper-composer 向けに、セクションごとの改稿概要を作成してください
• 根拠のない内容については、表現を弱めるのではなく削除する必要があることを明記してください
• composer には、コピーした草稿またはユーザーが指定した作業用草稿を使わせ、誤ったファイルを決して編集させないでください

ユーザーが手書きで修正した草稿の続きを特に依頼した場合：

• 作業用草稿のパスと、保護するバックアップ／原本のパスを別々に記録してください
• 本文の見出しスタイルだけを使って置換アンカーを計画してください
• 引き継ぎ時に目次ベースのアンカー照合を禁止してください
• 改稿後も残す必要がある旧図表を特定してください

ユーザーが類似度またはAIGCスコアを下げるよう特に依頼した場合：

• スコアの大部分を占めるセクションを最小限に絞って特定してください
• 効果の低い形式的なセクションより、中国語の叙述段落を優先してください
• 広範囲を浅く編集するのではなく、効果の高い構成上の改稿をいくつか優先してください
• references/detection-report-rewrite-playbook.md で定義された改稿モードを使用してください

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

• references/zjkj-undergrad-thesis-format.md - 学校指定の書式規則
• references/project-grounding-rules.md - 捏造防止と根拠に関する規則
• references/finalization-task-rules.md - 最終 DOCX 納品の必須ワークフロー
• references/detection-report-rewrite-playbook.md - 剽窃／AIGC レポートを改稿概要に反映する方法
• references/draft-salvage-handoff-playbook.md - 部分置換、既存アセットの保持、実行時スクリーンショットを計画する方法
• references/chinese-call-prompt-templates.md - 計画と引き継ぎ作業に使えるコピー＆ペースト用の中国語プロンプト

プロンプト例

• 現在のリポジトリと学校のテンプレートに基づいて、まず学部論文の最終稿作成計画を立ててください。コードで裏付けられる内容だけを残してください。
• 本文の2.3節の前まで初稿を手作業で修正しました。元のデータベースE-R図と、各テーブルのフィールド説明を残すことを条件に、keep/rewrite/deleteのマトリックスを作成してください。
• 剽窃レポートとAIGCレポートがあります。本文をすぐに書き換えず、まず問題のあるページを章に対応付けて、改稿の優先順位を示してください。
• 現在の作業用草稿で計画を続け、2.4節以降の本文だけを置き換えてください。それより前の手修正部分には触れないでください。
• 論文に掲載する実行時スクリーンショットの計画を作成してください。各スクリーンショットについて、対応するロール、ページ、章を示してください。

出力要件

以下を作成してください：

• 見出しレベル3までの論文構成案
• 章ごとの根拠マップ
• 現在の草稿の keep / rewrite / delete マトリックス
• 図／表／スクリーンショットの再作成計画
• 削除すべき根拠のない主張の一覧
• academic-paper-composer 向けの引き継ぎ資料一式
• レポートが提供された場合：問題のあるページ、対応するセクション、推奨する改稿の度合いを含む検出レポートのトリアージ概要

現段階で論文が提出可能だと断言してはいけません。その判断は、composer + drawio + playwright + doc の工程に委ねてください。