Agent Skills
› NeverSight/learn-skills.dev
› logical-consistency-reviewer
logical-consistency-reviewer
GitHub用于审查文章、报告及企划书的逻辑完整性。通过提取论点、分解信息、构建金字塔结构，结合Why So/So What/MECE原则，检测逻辑断裂、矛盾及论证不足，并提供具体修改建议，适用于公开前的逻辑校验。
触发场景
需要检查文章或报告的逻辑严密性
在发布或修改前进行最终逻辑审核
发现论述存在跳跃、矛盾或论据不足的问题
安装
npx skills add NeverSight/learn-skills.dev --skill logical-consistency-reviewer -g -y
SKILL.md
Frontmatter
{
"name": "logical-consistency-reviewer",
"description": "文章、記事、レポート、企画書の論理破綻をレビューし、論点、必要情報、推論、結論と根拠の構造を確認する。Why So、So What、MECEの観点で飛躍、矛盾、論点ずれ、根拠不足を検出する。公開前や改稿前に文章の筋道を点検するときに使う。単なる校正、文体調整、事実確認のみ、法的助言、数学的証明の厳密検証には使わない。"
}
論理整合性レビュー手順
文章・記事・レポート・企画書の論理破綻を検出し、結論、根拠、解釈、構造のつながりを点検する。文章の美しさよりも、論点に対して筋道が通っているかを優先する。
使用条件
次の場合に使う。
- 文章の主張が論理的に成立しているか確認する必要がある。
- 公開前の記事、提案書、説明文、論考、研究メモをレビューする必要がある。
- 結論と根拠の関係、飛躍、矛盾、論点ずれ、MECE漏れを検出する必要がある。
- 修正方針として、どの段落をどう直すべきか示す必要がある。
次の場合には使わない。
- 誤字脱字、文体、自然さだけを直す。
- 出典の真偽確認だけを行う。
- 法的判断、医療判断、数学的証明の厳密検証を代替する。
- 文章が存在せず、ゼロから構成案だけを作る。
基本姿勢
- 結論を先に特定する。
- 論点と関係しない表現上の好みを混ぜない。
- 事実、解釈、評価、提案を分けて扱う。
- 「根拠が弱い」と「論理が破綻している」を区別する。
- 断定できない場合は「未検証」「根拠不足」「推論の飛躍」と明示する。
- 修正案は、抽象的な助言ではなく、文章上の具体的な操作として提示する。
レビュー手順
1. 対象と目的を確定する
- 入力文章、想定読者、文章の目的を確認する。
- 目的が不明な場合は、文章内の手がかりから暫定目的を置く。
- 暫定目的を置いた場合は、レビュー冒頭に「暫定前提」として明記する。
- 文章が長い場合は、章、段落、見出し単位で番号を付けて参照できるようにする。
2. 論点を決める
- 文章が答えようとしている問いを一文で抽出する。
- 論点が複数ある場合は、主論点と副論点に分ける。
- 論点が曖昧な場合は、以下のどれが曖昧かを示す。
- 対象: 何について述べているか。
- 判断軸: 良い、悪い、必要、有効などを何で判断しているか。
- 範囲: どこまでを扱い、どこから扱わないか。
- 読者行動: 読者に何を理解、判断、実行させたいか。
3. 必要情報を分解する
- 論点に答えるために必要な情報カテゴリを列挙する。
- 文章内にある情報と、不足している情報を分ける。
- 各情報を次の型に分類する。
- 事実: 観察、データ、引用、出来事。
- 定義: 用語、範囲、前提条件。
- 因果: AがBを引き起こすという説明。
- 比較: AとBの差、優劣、トレードオフ。
- 価値判断: 望ましい、危険、有益などの評価。
- 提案: 取るべき行動や選択肢。
- 情報不足が結論に影響する場合は、重大度を付ける。
4. 情報から何がいえるかを点検する
- 各根拠から導かれている解釈を抽出する。
- 推論の型を判定する。
- 演繹: 一般原則から個別結論を導く。
- 帰納: 複数事例から一般化する。
- アブダクション: 最もありそうな説明を仮説として置く。
- 型ごとに破綻を探す。
- 演繹: 前提が結論を本当に含意しているか。
- 帰納: 事例数、代表性、反例の扱いが十分か。
- アブダクション: 代替仮説を無視していないか。
- 以下の典型的な論理破綻を検出する。
- 結論先取り: 根拠が結論を言い換えているだけ。
- 飛躍: 根拠から結論までの中間説明がない。
- 論点ずれ: 根拠が主論点ではなく別問題に答えている。
- 過度な一般化: 限定的な事例から広い結論を出している。
- 偽の二分法: 選択肢が二つしかないように扱っている。
- 因果と相関の混同: 同時発生を原因として扱っている。
- 循環論法: 結論を前提として使っている。
- 藁人形化: 反対意見を弱く単純化している。
- 曖昧語のすり替え: 同じ語が途中で別の意味になる。
- 必要条件と十分条件の混同。
5. 論理を構造化する
- 文章の最終結論を頂点に置く。
- 主要根拠をその下に並べ、ピラミッド構造として整理する。
- 各階層で
Why So?を問う。- 上位主張に対して、下位根拠が「なぜなら」と答えているか確認する。
- 各階層で
So What?を問う。- 下位根拠から、上位主張が「だから」と自然に導けるか確認する。
- 同じ階層の根拠がMECEに近いか確認する。
- 漏れ: 結論に必要な論点が欠けていないか。
- ダブり: 同じ根拠を別名で繰り返していないか。
- 粒度: 抽象度の違う項目が同列に並んでいないか。
- 構造化した結果、文章順が論理順とずれている場合は並べ替え案を出す。
6. 重大度を判定する
各問題に重大度を付ける。
- 致命的: 結論が成立しない、逆の結論も同程度に成り立つ、主要前提が矛盾している。
- 重大: 主張はあり得るが、重要な根拠、定義、中間説明が欠けている。
- 軽微: 局所的に分かりにくい、根拠の配置や接続語が弱いが、全体結論は残る。
- 補足: 論理破綻ではないが、読者が疑問を持ちそうな補足点。
7. 修正案を作る
- 問題ごとに、該当箇所、問題、理由、修正方針を示す。
- 致命的または重大な指摘には、可能な限り書き換え例を付ける。
- 根拠不足の場合は、必要な情報の種類を指定する。
- 論点が多すぎる場合は、削る論点、残す論点、別記事に分ける論点を提案する。
- 文章の意図を勝手に変えない。複数の修正方向がある場合は選択肢として示す。
出力形式
短いレビューでは次の形式で答える。
## 論理整合性レビュー
### 暫定前提
- 目的:
- 想定読者:
- 主論点:
### 結論
- 判定: 問題なし / 軽微な修正で可 / 要修正 / 結論再設計が必要
- 最大の論理リスク:
### 論理構造
- 最終結論:
- 主要根拠:
1.
2.
3.
### 指摘事項
| 重大度 | 箇所 | 問題 | なぜ問題か | 修正方針 |
|---|---|---|---|---|
### 修正優先順位
1.
2.
3.
長いレビュー、公開前原稿、重要な意思決定文書では、assets/review-template.md を読んで詳細版の形式を使う。
検証
- 出力前に
references/checklist.mdを読み、レビュー漏れがないか確認する。 - レビューをファイルに保存した場合は、次の検証スクリプトを実行する。
python3 scripts/check-review-output.py path/to/review.md
- スクリプトが失敗した場合は、不足セクションを追加して再実行する。
エラー処理
- 入力文章が短すぎる場合は、暫定的に評価できる範囲を示し、必要な追加情報を列挙する。
- 論点が複数競合している場合は、最初に論点候補を分け、どれを主論点にするか確認する。
- 事実確認が必要だが外部調査していない場合は、「事実関係は未検証」と明記する。
- 修正案が複数あり得る場合は、目的別に選択肢を出す。
- 文章の専門領域が不明な場合は、論理構造だけを評価し、専門的妥当性は未検証とする。
版本历史
- c3c0a1e 当前 2026-07-23 07:53
