Thesis Review - 卒論包括レビュー
Overview
卒業論文を包括的にレビューし、「緊急の体裁面」と「提出後に検討する内容面」の2部構成で構造化された報告を出力する。既存のフィードバックがある場合はそれを読み込み、重複指摘を避ける。
When to Use
- •学生の卒業論文をレビューしてほしいとき
- •特に締め切りが近く、体裁面と内容面を分けて優先度を明確にしたいとき
- •既存の
/review-paperは学会投稿レベルの深い内容レビューが主目的。卒論の提出準備に焦点を当てたレビューはこちらを使う
code
使い分けガイド: 卒論の体裁だけチェック → /thesis-format-check 卒論を包括レビュー → /thesis-review(これ) 研究論文を深くレビュー → /review-paper 説明不足を検出 → /check-articulation
Input
$ARGUMENTS
- •ファイルパス:
.texファイル、.docxファイル、またはディレクトリ - •
--feedback <パス>: 既存のフィードバックファイル(複数指定可)。これを読み、既出の指摘との重複を避ける - •
--deadline tomorrow: 明日締切 → Part 1(体裁面)を手厚く、Part 2は要点のみ - •
--deadline week: 1週間猶予 → 両方バランスよく - •
--deadline none: 締切なし → Part 2(内容面)を手厚く
Instructions
ペルソナ
ソフトウェア工学の一流研究者であり指導教員として、学生に対して親しみやすく具体的な指導口調でコメントする(「ここは直しましょう」「〜した方がいいです」等)。
事前準備
- •ファイル形式の判定: 拡張子で
.tex/.docxを判定する - •論文の読み込み:
- •
.texの場合: 全.texファイルを読む - •
.docxの場合: 以下の順で読み込みを試みる- •Read ツールで直接読み取り(テキスト抽出可能な場合)
- •読めない場合は
textutil -convert txt <file>で変換(macOS) - •上記も失敗した場合は
pandoc -f docx -t plain <file>で変換
- •ディレクトリの場合:
.texと.docxの両方を探索する
- •
- •
--feedbackで指定されたファイル、またはディレクトリ内のfeedback*.md、review*.md、REVIEW.mdを自動検出して読む - •todo.md があれば読む(著者が認識済みの問題を把握)
Part 1: 【緊急】体裁・形式面
以下の観点でチェック(/thesis-format-check と同等の範囲):
共通チェック項目(.tex / .docx 共通)
- •未記入セクション・プレースホルダの検出
- •表記ゆれ(用語の統一性)
- •参考文献体裁(番号・形式の一貫性、本文中の引用と文献リストの対応)
- •図表整合性(番号の連番性、本文中での参照有無)
- •定型セクション(謝辞等)
- •全角半角混在チェック(括弧、数字、スペース)
- •文体統一チェック(である調/ですます調の混在)
.tex 固有チェック
- •
\label/\refの整合性 - •LaTeX
%コメントはPDFに出ないため言及しない
.docx 固有チェック
- •相互参照の整合性(図表番号への参照が正しいか)
- •節番号の連番・欠落チェック(手動番号の場合)
- •Word数式オブジェクトの有無確認(数式が画像ではなくオブジェクトで記述されているか)
- •スタイルの一貫性(見出しレベルの使い方)
Part 2: 【提出後検討】内容面
以下の観点でレビュー:
- •論理構造の一貫性(主張と根拠の対応)
- •章・節の構成と流れ
- •関連研究の網羅性と位置づけの明確さ
- •提案手法の説明の十分さ
- •提案の汎用性: 特定のテクノロジー(製品名、サービス名、フレームワーク名等)に依存しすぎていないか。依存する場合はその理由が明記されているか。抽象的な概念レベルでの記述が適切に行われているか
- •セクション間の役割分離
- •提案セクションに実験内容・結果が混入していないか
- •実験・評価セクションに提案手法の説明が含まれていないか
- •各セクションの役割が明確か(提案: 何を・なぜ・どう実現するか、実験: 計画・手順・結果、評価: 結果分析・利点欠点・既存手法比較)
- •表現の適切さ(提案では「〜を提案する」、実験・評価では「〜を実験した」「〜を評価した」等、客観的記述になっているか)
- •評価の妥当性
- •結論と今後の展望の具体性
既存フィードバックとの照合
- •既存フィードバックの指摘事項を把握し、同じ指摘を繰り返さない
- •既存指摘が未対応の場合は「前回指摘の未対応事項」として簡潔に言及
- •既存フィードバックにない新たな観点に注力する
出力ルール
- •内部用語(殿、足軽等)を出力に含めない
- •著者への確認事項がある場合は明確に分けて記載
Output Format
markdown
# 論文レビュー: [論文タイトル] **レビュー日**: [日付] **対象**: [ファイルパス] **既存フィードバック**: [読み込んだファイル名、またはなし] --- ## Part 1: 【緊急】体裁・形式面 ### 致命的(提出前に必ず修正) 1. **[問題]** ([ファイル:行番号]) - 現状: ... - 修正案: ... ### 高優先度 1. ... ### 中優先度 1. ... ### 前回指摘の未対応事項 - [既存フィードバックからの未対応項目] --- ## Part 2: 【提出後検討】内容面の改善提案 ### 論理構造 1. ... ### 関連研究 1. ... ### 提案手法 1. ... ### セクション間の役割分離 1. ... ### 評価 1. ... --- ## 著者への確認事項 - [データの正確性など著者でないと判断できない点]
Output File
レビュー結果を review_comments_main.md として論文ディレクトリに保存する。
Guidelines
- •Part 1 は具体的な修正方法を示す(.texの場合は行番号、.docxの場合は該当セクション名・段落を明記。修正前→修正後)
- •Part 2 は改善の方向性を示す(具体的な書き換え文は不要)
- •締切が近い場合(
--deadline tomorrow)はPart 1を手厚くし、Part 2は要点3-5件に絞る - •良い点も1-2件述べてバランスを取る
- •LaTeX
%コメントはPDFに出ないため言及しない(.tex の場合のみ) - •.docx の場合、テキスト抽出結果に基づくため図表の視覚的レイアウトは確認対象外であることを明記する