Review Tracker - レビュー統合・追跡

Overview

複数回のフィードバックや、複数人・複数パートに分かれたレビュー結果を1つの文書に統合する。最新の原稿と照合して対応状況を判定し、重複を排除した優先度順のチェックリストを生成する。

When to Use

•同じ文書に対して複数回のレビューが行われ、指摘事項が散在しているとき
•複数のレビュアーからのフィードバックを1つにまとめたいとき
•レビュー指摘の対応状況を追跡したいとき
•卒論に限らず、コードレビュー・設計レビュー・企画書レビュー等にも使える

code

使い分けガイド:
  卒論の体裁だけチェック       → /thesis-format-check
  卒論を包括レビュー           → /thesis-review
  複数レビューを統合・追跡     → /review-tracker（これ）
  研究論文を深くレビュー       → /review-paper
  説明不足を検出               → /check-articulation

Input

$ARGUMENTS

•レビューファイル: 1つ以上のレビュー結果ファイル（md, txt等）。スペースまたはカンマ区切り
•--source <パス>: 最新の原稿ファイルまたはディレクトリ。指定すると対応状況を自動判定
•--output <パス>: 出力先パス（デフォルト: 原稿ディレクトリの review_tracking.md）

Instructions

Step 1: レビューファイルの読み込み

指定されたレビューファイルを全て読み込む。ファイルが指定されていない場合は、原稿ディレクトリ内の以下のパターンを自動検出：

•feedback*.md
•review*.md
•REVIEW.md
•*_comments*.md

Step 2: 指摘事項の抽出

各レビューから指摘事項を抽出し、以下の属性を付与：

•ID: 一意の識別子（R1, R2, ...）
•出典: どのレビューファイルの何番目の指摘か
•カテゴリ: 体裁 / 内容 / 構造 / 表記 / その他
•優先度: 致命的 / 高 / 中 / 低
•対象箇所: セクション・行番号等

Step 3: 重複排除

異なるレビューで同じ箇所への同じ指摘がある場合は統合する。統合時は：

•より具体的な記述を残す
•複数のレビュアーが指摘している旨を注記（信頼度が高い）

Step 4: 対応状況の判定（--source 指定時）

最新原稿を読み、各指摘について：

•対応済み: 指摘された問題が修正されている
•未対応: 指摘された問題がそのまま残っている
•部分対応: 一部修正されているが不十分
•確認不能: 原稿からは判断できない（著者確認が必要）

Step 5: チェックリスト生成

優先度順にソートし、チェックリスト形式で出力。

Output Format

markdown

# レビュー統合・追跡レポート

**生成日**: [日付]
**対象原稿**: [パス]
**統合したレビュー**:
- [ファイル1] ([日付/回次])
- [ファイル2] ([日付/回次])

## サマリ
- 総指摘数: N件（重複排除後）
- 対応済み: n件 / 未対応: n件 / 部分対応: n件 / 確認不能: n件

## 未対応チェックリスト（優先度順）

### 致命的
- [ ] **R1**: [指摘内容] ([対象箇所])
  - 出典: [レビューファイル]
  - 状況: 未対応

### 高優先度
- [ ] **R3**: ...

### 中優先度
- [ ] **R5**: ...

### 低優先度
- [ ] **R8**: ...

## 対応済み一覧
- [x] **R2**: [指摘内容] — 対応確認済み
- [x] **R4**: ...

## 著者確認が必要な事項
- **R6**: [内容] — 原稿からは正否を判断できないため確認が必要

## 指摘カテゴリ別集計
| カテゴリ | 総数 | 対応済み | 未対応 |
|---------|------|---------|--------|
| 体裁 | | | |
| 内容 | | | |
| 構造 | | | |
| 表記 | | | |

Guidelines

•指摘の統合時は、情報を捨てない。両方のレビューの記述を残す
•対応状況の判定は保守的に行う（迷ったら「確認不能」）
•レビューファイルの日付・順序がわかる場合は、最新のレビューを優先
•出力は学生やチームメンバーに直接渡せる形を目指す
•内部用語（殿、足軽等）を出力に含めない