review-report

star 0

Reviews generated reports and blogs by reading source and reference papers, evaluating correctness and quality. Use when the user wants to verify the accuracy and quality of a generated report or blog.

shibuiwilliam By shibuiwilliam schedule Updated 1/25/2026
play_arrow Run Skill in Manus View GitHub

name: review-report description: Reviews generated reports and blogs by reading source and reference papers, evaluating correctness and quality. Use when the user wants to verify the accuracy and quality of a generated report or blog.

レポート・ブログレビュースキル

生成されたレポートまたはブログを、元論文と参照論文を読み直して検証し、正確性と品質を評価します。

概要

このスキルは以下を実行します：

  1. レポート/ブログの読み込み: 対象ファイルを完全に読み取り
  2. 元論文の再読: 元の arXiv 論文を PDF で再度読み取り
  3. 参照論文の検証: 引用されている参照論文を WebSearch で調査
  4. 正確性の検証: レポート内容と元論文の整合性をチェック
  5. 品質評価: 構造、詳細度、読みやすさを評価
  6. レビューレポートの生成: 問題点と改善提案を出力

ワークフロー

ステップ 1: 対象ファイルの特定

ユーザーが指定したレポートまたはブログファイルを特定します。

# レポートファイルの一覧
ls -lt reports/*_report.md | head -5

# ブログファイルの一覧
ls -lt reports/*_blog.md | head -5

指定がない場合は、最新のファイルを対象とします。

ステップ 2: レポート/ブログの読み込み

対象ファイルを完全に読み込み、以下を抽出します：

  • 基本情報: arXiv ID、タイトル、著者
  • 主要な主張: 論文の核心的な主張
  • 技術的詳細: 手法、数式、アルゴリズム
  • 実験情報: データセット、評価指標、結果
  • 参照論文リスト: 引用されている論文

ステップ 3: 元論文の再読

arXiv ID から元論文を取得し、再度読み取ります。

# PDF のダウンロードと情報確認
uv run pdf-chunker <arxiv_id>

長いドキュメント（100ページ以上）の場合:

# チャンクにエクスポート
uv run pdf-chunker <arxiv_id> --export-dir chunks/<arxiv_id>

その後、チャンクファイルを順番に読み取ります。

ステップ 4: 参照論文の検証

レポートに記載されている参照論文について、WebSearch で情報を検証します：

  • 著者名、年、発表先の正確性
  • 論文の概要・貢献の正確性
  • 本論文との関係性の記述が適切か

ステップ 5: 正確性の検証

以下の項目について、元論文との整合性をチェックします。

検証項目

A. 事実の正確性

項目 チェック内容 重要度
タイトル・著者 正確に記載されているか 高
主要な主張 論文の主張を正確に反映しているか 高
数値データ 実験結果の数値が正確か 高
数式 数式が正確に転記されているか 高
引用文 原文の引用が正確か 中
図表の説明 図表の内容を正確に説明しているか 中

B. 内容の完全性

項目 チェック内容 重要度
セクションのカバー すべての重要なセクションが含まれているか 高
手法の詳細 提案手法が十分に詳しく説明されているか 高
実験の詳細 実験設定が十分に記載されているか 中
限界・課題 論文の限界が記載されているか 中
参照論文 重要な参照論文が十分にカバーされているか 中

C. 解釈の妥当性

項目 チェック内容 重要度
過度な解釈 論文に書かれていないことを断定していないか 高
主張の強さ 著者の主張の強さを正確に反映しているか 中
推測と事実の区別 推測は推測として明示されているか 中
因果関係 相関と因果を混同していないか 中

D. 参照論文の正確性

項目 チェック内容 重要度
書誌情報 著者、年、発表先が正確か 高
概要の正確性 参照論文の内容を正確に説明しているか 中
関係性の記述 本論文との関係が正確か 中
URL の有効性 リンクが正しいか 低

品質評価項目

E. 構造と読みやすさ

項目 チェック内容 評価基準
論理的構成 セクションの順序が論理的か 5段階
見出しの明確さ 見出しが内容を適切に表しているか 5段階
段落の適切さ 段落が適切な長さで区切られているか 5段階
図表の配置 図表が適切な位置に配置されているか 5段階

F. 詳細度と深さ

項目 チェック内容 評価基準
技術的深さ 技術的な内容が十分に詳しいか 5段階
背景の説明 予備知識なしでも理解できるか 5段階
数式の解説 数式の意味が説明されているか 5段階
具体例 具体例が十分に含まれているか 5段階

G. 文体と表現

項目 チェック内容 評価基準
文体の統一 ですます調で統一されているか 合格/不合格
専門用語の説明 専門用語に説明があるか 5段階
明確さ 曖昧な表現がないか 5段階
冗長さ 不要な繰り返しがないか 5段階

レビューレポートのテンプレート

# レビューレポート: {arxiv_id}

> レビュー対象: `{対象ファイルパス}`
> レビュー日: YYYY-MM-DD

---

## 総合評価

| カテゴリ | 評価 | コメント |
|---------|------|---------|
| **事実の正確性** | ⭐⭐⭐⭐⭐ (5/5) | [概要] |
| **内容の完全性** | ⭐⭐⭐⭐☆ (4/5) | [概要] |
| **解釈の妥当性** | ⭐⭐⭐⭐⭐ (5/5) | [概要] |
| **参照論文の正確性** | ⭐⭐⭐⭐☆ (4/5) | [概要] |
| **構造と読みやすさ** | ⭐⭐⭐⭐⭐ (5/5) | [概要] |
| **詳細度と深さ** | ⭐⭐⭐⭐☆ (4/5) | [概要] |
| **文体と表現** | ⭐⭐⭐⭐⭐ (5/5) | [概要] |

**総合スコア**: XX/35

---

## 詳細な検証結果

### 1. 事実の正確性

#### 正確に記載されている項目 ✓

- [項目1]: [確認内容]
- [項目2]: [確認内容]

#### 問題が見つかった項目 ✗

##### 問題 1: [問題のタイトル]

| 項目 | 内容 |
|------|------|
| **箇所** | [レポートの該当箇所] |
| **レポートの記述** | "[レポートの記述内容]" |
| **元論文の記述** | "[元論文の正確な内容]" |
| **問題の種類** | [誤記/省略/誤解釈/過度な解釈] |
| **重要度** | [高/中/低] |
| **修正提案** | [具体的な修正案] |

##### 問題 2: [問題のタイトル]

[同様の形式で記載]

---

### 2. 内容の完全性

#### 十分にカバーされている項目 ✓

- [項目1]
- [項目2]

#### 不足している項目 ✗

##### 不足 1: [不足のタイトル]

| 項目 | 内容 |
|------|------|
| **不足箇所** | [レポートのセクション] |
| **不足内容** | [含まれるべき内容] |
| **元論文での記載箇所** | [セクション/ページ番号] |
| **重要度** | [高/中/低] |
| **追加提案** | [具体的な追加案] |

---

### 3. 解釈の妥当性

#### 適切な解釈 ✓

- [項目1]: [解釈が妥当な理由]

#### 問題のある解釈 ✗

##### 解釈問題 1: [問題のタイトル]

| 項目 | 内容 |
|------|------|
| **箇所** | [レポートの該当箇所] |
| **レポートの解釈** | "[レポートの記述]" |
| **元論文の実際の主張** | "[元論文の記述]" |
| **問題の種類** | [過度な一般化/因果関係の誤認/主張の強さの誤り] |
| **修正提案** | [具体的な修正案] |

---

### 4. 参照論文の検証結果

#### 検証した参照論文

| 論文 | 書誌情報 | 概要 | 関係性 |
|------|---------|------|--------|
| [論文1] | ✓ 正確 | ✓ 正確 | ✓ 適切 |
| [論文2] | ✓ 正確 | △ 一部不正確 | ✓ 適切 |
| [論文3] | ✗ 誤り | - | - |

#### 参照論文の問題詳細

##### 問題 1: [論文名] の書誌情報

| 項目 | レポートの記載 | 正確な情報 |
|------|---------------|-----------|
| **著者** | [レポートの記載] | [正確な著者] |
| **年** | [レポートの記載] | [正確な年] |
| **発表先** | [レポートの記載] | [正確な発表先] |

---

### 5. 構造と読みやすさ

#### 評価

| 項目 | 評価 | コメント |
|------|------|---------|
| 論理的構成 | ⭐⭐⭐⭐⭐ | [コメント] |
| 見出しの明確さ | ⭐⭐⭐⭐☆ | [コメント] |
| 段落の適切さ | ⭐⭐⭐⭐⭐ | [コメント] |
| 図表の配置 | ⭐⭐⭐⭐☆ | [コメント] |

#### 改善提案

- [改善提案1]
- [改善提案2]

---

### 6. 詳細度と深さ

#### 評価

| 項目 | 評価 | コメント |
|------|------|---------|
| 技術的深さ | ⭐⭐⭐⭐☆ | [コメント] |
| 背景の説明 | ⭐⭐⭐⭐⭐ | [コメント] |
| 数式の解説 | ⭐⭐⭐⭐☆ | [コメント] |
| 具体例 | ⭐⭐⭐☆☆ | [コメント] |

#### 詳細化すべき箇所

- [箇所1]: [詳細化の提案]
- [箇所2]: [詳細化の提案]

---

### 7. 文体と表現

#### 評価

| 項目 | 評価 | コメント |
|------|------|---------|
| 文体の統一 | ✓ 合格 / ✗ 不合格 | [コメント] |
| 専門用語の説明 | ⭐⭐⭐⭐☆ | [コメント] |
| 明確さ | ⭐⭐⭐⭐⭐ | [コメント] |
| 冗長さ | ⭐⭐⭐⭐☆ | [コメント] |

#### 文体の問題

- [問題1]: "[該当する文]" → "[修正案]"
- [問題2]: "[該当する文]" → "[修正案]"

---

## 修正優先度リスト

### 高優先度（必須修正）

1. **[問題タイトル]**: [簡潔な説明と修正方法]
2. **[問題タイトル]**: [簡潔な説明と修正方法]

### 中優先度（推奨修正）

1. **[問題タイトル]**: [簡潔な説明と修正方法]
2. **[問題タイトル]**: [簡潔な説明と修正方法]

### 低優先度（任意修正）

1. **[問題タイトル]**: [簡潔な説明と修正方法]

---

## まとめ

[レビュー全体のまとめ。良い点と改善すべき点を簡潔に記述]

### 良い点

- [良い点1]
- [良い点2]

### 改善すべき点

- [改善点1]
- [改善点2]

---

*このレビューレポートは Claude Code によって自動生成されました。*
*レビュー日: YYYY-MM-DD*

検証の詳細手順

A. 事実の正確性の検証

数値データの検証

レポートに記載されている数値を、元論文と照合します：

  1. 実験結果テーブルの各数値を確認
  2. 改善率（パーセンテージ）の計算が正確か確認
  3. データセットサイズ、パラメータ数等を確認
検証例:
- レポート: "提案手法は 85.3% の精度を達成"
- 元論文 Table 1 を確認 → 85.3% ✓ 正確

数式の検証

レポートの数式を元論文と照合します：

  1. 変数名が正確か
  2. 添字が正確か
  3. 演算子が正確か
  4. 数式番号の参照が正確か

引用文の検証

英語の引用文が原文と一致するか確認します：

  1. 引用箇所を元論文で特定
  2. 一字一句正確か確認
  3. 省略がある場合は「...」が適切に使われているか

B. 内容の完全性の検証

セクションカバレッジの確認

元論文の主要セクションがレポートでカバーされているか確認：

元論文セクション レポートでの対応 ステータス
Abstract 概要 ✓ / ✗
Introduction 背景と動機 ✓ / ✗
Related Work 関連研究 ✓ / ✗
Method 提案手法 ✓ / ✗
Experiments 実験 ✓ / ✗
Results 結果 ✓ / ✗
Conclusion 結論 ✓ / ✗

重要な図表の確認

元論文の重要な図表がレポートで言及されているか確認：

  1. アーキテクチャ図（通常 Figure 1）
  2. 主要結果テーブル（通常 Table 1-2）
  3. アブレーション結果
  4. 定性的結果（可視化例）

C. 解釈の妥当性の検証

主張の強さの確認

元論文の表現とレポートの表現を比較：

元論文の表現 主張の強さ レポートで使うべき表現
"demonstrates" 強い 「実証しています」「示しています」
"shows" 中程度 「示しています」
"suggests" 弱い 「示唆しています」
"may" 可能性 「可能性があります」
"could" 仮定 「可能性があります」「〜かもしれません」

過度な一般化の確認

レポートが元論文の範囲を超えて一般化していないか確認：

  • 特定のデータセットでの結果を「一般的に」と表現していないか
  • 特定の条件下での結果を無条件に主張していないか

D. 参照論文の検証

各参照論文について WebSearch で以下を確認：

# 検索クエリの例
WebSearch: "[論文タイトル] [著者名] [年]"
WebSearch: "[論文タイトル] arxiv"

確認項目：

  1. 著者名のスペルが正確か
  2. 発表年が正確か
  3. 発表先（会議/ジャーナル）が正確か
  4. arXiv ID/DOI が正確か

コマンド例

# レポートのレビュー
/review-report 2401.12345

# ブログのレビュー
/review-report 2401.12345 --type blog

# 特定のファイルをレビュー
/review-report reports/2401.12345_report.md

# 特定の項目のみ検証
/review-report 2401.12345 --check accuracy
/review-report 2401.12345 --check completeness
/review-report 2401.12345 --check references

# 詳細レベルを指定
/review-report 2401.12345 --level thorough   # 詳細な検証
/review-report 2401.12345 --level quick      # 簡易検証

オプション

オプション 説明 デフォルト
--type レビュー対象のタイプ（report/blog） report
--check 特定の検証項目のみ実行 all
--level 検証の詳細レベル（quick/normal/thorough） normal
--output レビューレポートの出力先 reviews/{arxiv_id}_review.md

--check の選択肢

値 検証内容
all すべての項目を検証
accuracy 事実の正確性のみ
completeness 内容の完全性のみ
interpretation 解釈の妥当性のみ
references 参照論文の正確性のみ
quality 構造・詳細度・文体のみ

--level の選択肢

値 検証の詳細度
quick 主要項目のみ（5-10分）
normal 標準的な検証（15-30分）
thorough 詳細な全項目検証（30-60分）

出力先

reviews/{arxiv_id}_review.md      # レポートのレビュー
reviews/{arxiv_id}_blog_review.md # ブログのレビュー

検証後のアクション

レビュー完了後、問題が見つかった場合は /fix-report スキルを使用して修正：

# レビュー結果に基づいて修正
/fix-report 2401.12345 --based-on reviews/2401.12345_review.md

注意事項

  • 元論文の完全な読み直しを行うため、処理に時間がかかります
  • 長いドキュメント（100ページ以上）の場合は、チャンク処理を使用します
  • 参照論文の検証には WebSearch を使用するため、ネットワーク接続が必要です
  • レビュー結果は自動検証であり、最終判断は人間が行ってください
  • 数式や図表の検証には限界があります

関連スキル

  • /analyze-paper: レポート生成（レビュー対象の作成）
  • /fix-report: レビュー結果に基づく修正
  • /blog-format: ブログ形式への変換（レビュー対象の作成）
  • /add-figures: 図表の追加

よくある問題パターン

1. 数値の転記ミス

症状: 実験結果の数値が元論文と異なる

確認方法: 元論文の Table を直接参照して照合

修正: 正確な数値に置き換え

2. 著者名のスペルミス

症状: 参照論文の著者名が不正確

確認方法: WebSearch で論文を検索して正確な著者名を確認

修正: 正確なスペルに修正

3. 過度な一般化

症状: 限定的な結果を一般的な主張として記述

確認方法: 元論文の主張の範囲を確認

修正: 条件や限定を明示

4. 主張の強さの不一致

症状: "suggests" を "demonstrates" として記述

確認方法: 元論文の動詞を確認

修正: 適切な動詞に変更

5. セクションの欠落

症状: 重要なセクション（Ablation Study 等）が記載されていない

確認方法: 元論文の目次と照合

修正: 欠落セクションを追加

サブスキル: 改善提案の生成（propose-improvements）

レビュー結果に基づいて、Why（なぜ）・How（どのように）・What（何を） の観点から具体的な改善提案を生成します。

概要

このサブスキルは、レビューで発見された問題を単なる指摘で終わらせず、実行可能な改善アクションに変換します。

# 改善提案の生成
/review-report 2401.12345 --propose-improvements

# レビューと改善提案を同時に実行
/review-report 2401.12345 --with-proposals

改善提案のフレームワーク

各問題に対して、以下の3つの観点から改善提案を生成します：

観点 説明 質問
Why（なぜ） 修正が必要な理由・根拠 なぜこの修正が重要なのか？
How（どのように） 修正のアプローチ・方法 どのような手順で修正するか？
What（何を） 具体的な修正内容 実際に何を変更するか？

改善提案テンプレート

## 改善提案レポート: {arxiv_id}

> 対象: `{対象ファイルパス}`
> 生成日: YYYY-MM-DD
> 基となるレビュー: `reviews/{arxiv_id}_review.md`

---

## 改善提案サマリー

| # | 問題 | 優先度 | 影響範囲 | 難易度 |
|---|------|--------|---------|--------|
| 1 | [問題の概要] | 高/中/低 | [影響するセクション] | 簡単/普通/難しい |
| 2 | [問題の概要] | 高/中/低 | [影響するセクション] | 簡単/普通/難しい |

**推定修正時間**: 約 XX 分

---

## 詳細な改善提案

### 提案 1: [問題のタイトル]

#### 📋 概要

| 項目 | 内容 |
|------|------|
| **問題カテゴリ** | [事実の正確性/内容の完全性/解釈の妥当性/参照論文/品質] |
| **該当箇所** | [セクション名、行番号など] |
| **優先度** | 🔴 高 / 🟡 中 / 🟢 低 |
| **難易度** | ⭐ 簡単 / ⭐⭐ 普通 / ⭐⭐⭐ 難しい |

#### ❓ Why（なぜ修正が必要か）

**問題の本質**:
[この問題が存在する根本的な理由を説明します]

**修正しない場合のリスク**:
- [リスク1]: [具体的な影響]
- [リスク2]: [具体的な影響]

**修正による効果**:
- [効果1]: [具体的なメリット]
- [効果2]: [具体的なメリット]

**根拠**:
> "[元論文からの引用や、問題を裏付ける証拠]"

#### 🔧 How（どのように修正するか）

**修正アプローチ**:
[修正の全体的な方針・戦略を説明します]

**手順**:
1. **準備**: [準備として行うこと]
2. **調査**: [追加で調査が必要な場合]
3. **修正**: [実際の修正作業]
4. **確認**: [修正後の確認方法]

**必要なツール/リソース**:
- [ツール1]: [用途]
- [リソース1]: [参照先]

**注意点**:
- [注意点1]
- [注意点2]

#### ✏️ What（具体的に何を変更するか）

**現在の記述**:
```markdown
[現在のレポートの該当部分を引用]

修正後の記述:

[修正後の具体的な文章を提示]

変更点の説明:

📝 修正用コマンド（オプション）

# /fix-report を使用する場合
/fix-report {arxiv_id} --section "[セクション名]" --fix "[修正内容の要約]"

提案 2: [問題のタイトル]

[同様の形式で記載]

修正の実行計画

フェーズ 1: 高優先度の修正（必須）

順序 提案 推定時間 依存関係
1 [提案X] X分 なし
2 [提案Y] X分 提案Xの完了後

フェーズ 2: 中優先度の修正（推奨）

順序 提案 推定時間 依存関係
3 [提案Z] X分 なし

フェーズ 3: 低優先度の修正（任意）

順序 提案 推定時間 依存関係
4 [提案W] X分 なし

品質向上のための追加提案

レビューで発見された問題以外に、レポートの品質をさらに向上させるための提案：

追加提案 1: [提案タイトル]

Why

[この追加提案が価値を持つ理由]

How

[実現方法]

What

[具体的な追加内容]

修正後の期待される改善

評価項目 修正前 修正後（予測）
事実の正確性 ⭐⭐⭐⭐☆ ⭐⭐⭐⭐⭐
内容の完全性 ⭐⭐⭐☆☆ ⭐⭐⭐⭐⭐
解釈の妥当性 ⭐⭐⭐⭐☆ ⭐⭐⭐⭐⭐
総合スコア XX/35 YY/35

この改善提案は Claude Code によって自動生成されました。 生成日: YYYY-MM-DD


---

### Why-How-What の記述ガイドライン

#### Why（なぜ）の書き方

**目的**: 修正の必要性と重要性を明確にする

**含めるべき内容**:
1. **問題の本質**: なぜこの問題が発生したか
2. **影響**: 修正しない場合のリスク・悪影響
3. **効果**: 修正による具体的なメリット
4. **根拠**: 元論文や信頼できるソースからの裏付け

**記述例**:
```markdown
#### Why（なぜ修正が必要か）

**問題の本質**:
実験結果の数値「87.5%」は、元論文 Table 2 の「85.7%」と異なっています。
これは転記時の誤りと考えられます。

**修正しない場合のリスク**:
- 読者が誤った性能値を信じてしまう
- 他の手法との比較が不正確になる
- レポートの信頼性が損なわれる

**修正による効果**:
- 正確な情報提供により、読者の意思決定を支援
- レポートの学術的信頼性が向上

**根拠**:
> 元論文 Table 2: "Our method achieves 85.7% accuracy on the test set."

How（どのように）の書き方

目的: 修正の具体的な手順と方法を示す

含めるべき内容:

  1. アプローチ: 修正の全体的な方針
  2. 手順: ステップバイステップの作業工程
  3. ツール: 使用するツールやリソース
  4. 注意点: 作業時に気をつけること

記述例:

#### How（どのように修正するか）

**修正アプローチ**:
元論文の Table 2 を再確認し、正確な数値に置き換えます。
関連する記述（比較分析、結論など）も一貫性を保つよう修正します。

**手順**:
1. **準備**: 元論文 PDF を開き、Table 2 を確認
2. **調査**: 87.5% が記載されている全箇所を検索
3. **修正**: 各箇所を 85.7% に修正
4. **確認**: 修正後、数値の一貫性を確認

**必要なツール/リソース**:
- 元論文 PDF（Table 2 の参照用）
- テキスト検索（「87.5」で検索）

**注意点**:
- 他の表や図の数値と混同しないよう注意
- 改善率の計算も再確認が必要

What（何を）の書き方

目的: 具体的な変更内容を明示する

含めるべき内容:

  1. 現在の記述: 問題のある現在のテキスト
  2. 修正後の記述: 正しい内容に修正したテキスト
  3. 変更点の説明: 何がどう変わったかの解説

記述例:

#### What（具体的に何を変更するか）

**現在の記述**:
```markdown
実験の結果、提案手法は **87.5%** の精度を達成し、
従来手法の 80.2% を大きく上回りました。

修正後の記述:

実験の結果、提案手法は **85.7%** の精度を達成し、
従来手法の 80.2% を 5.5 ポイント上回りました。

変更点の説明:

  • 精度: 87.5% → 85.7%（元論文 Table 2 に基づく）
  • 改善幅の記述を追加（5.5 ポイント = 85.7 - 80.2）

---

### 問題カテゴリ別の提案パターン

#### A. 事実の正確性に関する問題

**典型的な Why**:
- 読者に誤情報を提供してしまう
- 学術的な信頼性が損なわれる
- 引用・参照される際に誤りが広がる

**典型的な How**:
1. 元論文の該当箇所を特定
2. 正確な情報を抽出
3. レポートの全箇所を修正
4. 関連する計算・記述も確認

**典型的な What**:
- 数値の置き換え
- 引用文の修正
- 数式の訂正

#### B. 内容の完全性に関する問題

**典型的な Why**:
- 論文の重要な貢献が伝わらない
- 読者が全体像を把握できない
- 実用的な情報が不足している

**典型的な How**:
1. 元論文の該当セクションを読み直す
2. 要点を抽出・整理
3. レポートの適切な位置に追加
4. 既存の内容との整合性を確認

**典型的な What**:
- 新しいセクションの追加
- 既存セクションの拡充
- 図表の説明の追加

#### C. 解釈の妥当性に関する問題

**典型的な Why**:
- 著者の主張を歪めてしまう
- 読者に誤った理解を与える
- 論文の貢献を過大/過小評価してしまう

**典型的な How**:
1. 元論文の主張の強さを再確認
2. 適切な表現に修正
3. 条件や限定を明示
4. 推測と事実を区別

**典型的な What**:
- 動詞の修正（demonstrates → suggests）
- 限定句の追加（「特定の条件下で」）
- 推測の明示（「と考えられます」）

#### D. 参照論文に関する問題

**典型的な Why**:
- 読者が参照論文を見つけられない
- 関連研究の理解が不正確になる
- 学術的な正確性が損なわれる

**典型的な How**:
1. WebSearch で正確な情報を検索
2. 公式ソース（arXiv、学会サイト）で確認
3. 書誌情報を修正
4. 内容の説明も必要に応じて修正

**典型的な What**:
- 著者名のスペル修正
- 発表年・発表先の訂正
- URL の更新

#### E. 品質に関する問題

**典型的な Why**:
- 読みやすさが低下する
- 理解に余計な労力がかかる
- プロフェッショナルな印象が損なわれる

**典型的な How**:
1. 問題のあるセクションを特定
2. 改善方針を決定
3. 文章・構造を修正
4. 全体の一貫性を確認

**典型的な What**:
- 文体の統一
- 段落の再構成
- 見出しの改善
- 冗長な表現の削除

---

### コマンド例

```bash
# レビューと改善提案を同時に生成
/review-report 2401.12345 --with-proposals

# 既存のレビューから改善提案を生成
/review-report 2401.12345 --propose-improvements --from-review reviews/2401.12345_review.md

# 特定カテゴリの改善提案のみ
/review-report 2401.12345 --propose-improvements --category accuracy

# 高優先度の改善提案のみ
/review-report 2401.12345 --propose-improvements --priority high

# 改善提案を含む詳細レビュー
/review-report 2401.12345 --level thorough --with-proposals

オプション（サブスキル用）

オプション 説明 デフォルト
--with-proposals レビューと改善提案を同時生成 false
--propose-improvements 改善提案のみ生成 false
--from-review 既存のレビューファイルを使用 -
--category 特定カテゴリの提案のみ all
--priority 特定優先度の提案のみ all
--output-proposals 改善提案の出力先 reviews/{arxiv_id}_proposals.md

出力ファイル

reviews/
├── {arxiv_id}_review.md           # レビューレポート
├── {arxiv_id}_proposals.md        # 改善提案レポート
└── {arxiv_id}_blog_proposals.md   # ブログ用改善提案

改善提案の活用フロー

[レビュー実行]
     ↓
[問題の発見]
     ↓
[改善提案の生成]
     ↓
[Why-How-What の確認]
     ↓
[優先度に従って修正]
     ↓
[/fix-report で修正実行]
     ↓
[再レビューで確認]

このスキルは、レポート・ブログの品質を向上させるための検証ツールです。

Install via CLI
npx skills add https://github.com/shibuiwilliam/paper2detail --skill review-report
Repository Details
star Stars 0
call_split Forks 0
navigation Branch main
article Path SKILL.md
Occupations
Mathematical Science Occupations all other
More from Creator
shibuiwilliam
shibuiwilliam Explore all skills →