mcpField
P
ppw:logic

ppw:logic

github.com/lylll9436ドキュメント39080 回インストール31 週間前に更新
リポジトリ

ppw:logic について

ppw:logic は、学術論文全体のセクション間の論理と一貫性を確認するスキルです。本文は書き換えず、論証のつながりや根拠のない主張、用語の揺れ、数値の矛盾をバイリンガルレポートにまとめます。

主な機能

  1. 01セクション間の論証分析
  2. 02根拠のない主張の検出
  3. 03用語の一貫性確認
  4. 04定量値の矛盾確認
  5. 05バイリンガルの問題レポート

活用シーン

  1. 01方法が序論の主張を支えるか確認
  2. 02結果と記載された方法の対応を確認
  3. 03セクション間の用語の揺れを検出
  4. 04論文内の報告値を比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lylll9436/paper-polish-workflow-skill --skill ppw:logic

インストール後、Claude Code で/ppw:logicを入力して読み込まれたか確認します。

詳細

目的

このスキルは、学術論文全体を読み込み、各セクション間の論理的一貫性を検証します。4種類の問題、すなわち論証チェーンの欠落(AC-)、裏付けのない主張(UC-)、用語の不一致(TI-)、数値の矛盾(NC-)を特定し、2部構成のバイリンガルレポートを作成します。第1部では、各セクションの主要な主張を「論証チェーンビュー」表にまとめ、序論から結論まで主張がどのようにつながっているか(またはつながっていないか)を示します。第2部では、特定した問題をすべて分類し、問題の説明、影響の記述、方向性を示す一文の提案を記載します。それぞれの後には、中国語訳をインラインで添えます。このスキルは文章を書き換えず、問題の特定と提案のみを行います。

コアプロンプト

出典:awesome-ai-research-writing — 逻辑检查

# Role
你是一位负责论文终稿校对的学术助手。你的任务是进行"红线审查",确保论文没有致命错误。

# Task
请对我提供的【英文 LaTeX 代码片段】进行最后的一致性与逻辑核对。

# Constraints
1. 审查阈值(高容忍度):
   - 默认假设:请预设当前的草稿已经经过了多轮修改与校正,质量较高。
   - 仅报错原则:只有在遇到阻碍读者理解的逻辑断层、引起歧义的术语混乱、或严重的语法错误时才提出意见。
   - 严禁优化:对于"可改可不改"的风格问题、或者仅仅是"换个词听起来更高级"的建议,请直接忽略,不要通过挑刺来体现你的存在感。

2. 审查维度:
   - 致命逻辑:是否存在前后完全矛盾的陈述?
   - 术语一致性:核心概念是否在没有说明的情况下换了名字?
   - 严重语病:是否存在导致句意不清的中式英语(Chinglish)或语法结构错误。

3. 输出格式:
   - 如果没有上述"必须修改"的错误,请直接输出中文:[检测通过,无实质性问题]。
   - 如果有问题,请使用中文分点简要指出,不要长篇大论。

トリガー

次の依頼があった場合に有効になります:

  • 論文の論理を確認、検証、または論理的な問題を探す
  • 論文の論理を確認する、論証チェーンを検証する、論理的な問題を探す

使用例:

  • 「論文の論理を確認してください」/「論文の論理を確認する」
  • 「各セクション間の論証チェーンを検証してください」/「論文の各章の論証に一貫性があるか検証する」
  • 「草稿内の論理的な矛盾を探してください」/「論文の論理的な問題を探す」

モード

モードデフォルト動作
directはい中間確認を挟まず、論文全体を一度に分析します
batch非対応 — セクション間の論理検証には論文全体の文脈が必要です

デフォルトモード: direct。ユーザーが論文を提供すると、2部構成の完全な論理レポートを受け取ります。

参考資料

必須(常に読み込み)

論理検証では、中国語訳の形式とオプトアウトの動作を定めるために references/bilingual-output.md を読み込みます。表現パターンのリーフは不要で、AI 的なパターンも読み込みません(査読者シミュレーションスキルの規約に準拠)。論理検証はジャーナルに依存しないため、ジャーナルのテンプレートも読み込みません。

リーフのヒント

なし。

質問方針

開始前に、次の点を確認します:

  1. 入力形式:ファイルパスか、貼り付けたテキストか。(ユーザーの依頼から明らかな場合は省略)
  2. セクション構成:入力からセクションの境界が不明確な場合(例:見出しのない番号なしの文章)のみ確認します。

ルール:

  • 入力が十分にある場合は、direct モードで事前質問なしに進めます。
  • 分析開始前に質問するのは1つまでとします。
  • 利用可能な場合は構造化された対話を使用し、利用できない場合は通常のテキストで質問します。

ワークフロー

ステップ0:ワークフローの履歴確認
  • .planning/workflow-memory.json を読み込みます。ファイルが存在しない、または空の場合は、ステップ1に進みます。
  • 直近1~2件のログエントリが、ログ内で閾値以上の回数出現した ppw:logic を含む既知のパターンを形成しているか確認します。詳しいアルゴリズムについては、skill-conventions.md > Workflow Memory > Pattern Detection を参照してください。
  • パターンが見つかった場合は、AskUserQuestion を使って次の推奨事項を提示します:
    • 質問:「よく使われるワークフローが検出されました:[pattern](N回出現)。ppw:logic を direct モードで実行しますか?」
    • 選択肢:「はい、続行」/「いいえ、通常どおり続行」
  • ユーザーが承諾した場合:モードを direct に設定し、質問方針の質問を省略します。
  • ユーザーが拒否した場合、または AskUserQuestion が利用できない場合:通常モードで続行します。
ステップ1 — 入力の確認
  • ファイルパス(Read ツール)または会話に貼り付けられたテキストを入力として受け付けます。
  • 論文全体の確認: 入力が一部のみと見られる場合(セクション見出しが1つだけ、約500語未満、または Methods/Results/Discussion の目印がない)は、次のように依頼を断ります:

    「セクションをまたいだ検証には論文全体が必要です。原稿の全文を提供してください。」

  • セクション構成を解析し、論文に記載されたセクションの境界とタイトルをそのまま特定します。
  • ワークフローの記録: .planning/workflow-memory.json に {"skill": "ppw:logic", "ts": "<ISO timestamp>"} を追記します。ファイルが存在しない場合は [] として作成します。ログが50件以上の場合は、最も古いエントリを削除します。
ステップ 2 — 4 種類の問題を分析する
  • 上記の Core Prompt の制約を最優先の指示として遵守してください。特に、高い許容しきい値と「仅报错原则」を重視してください。

Argument Chain View の表を作成する前に、4 種類すべての問題チェックを実施してください。 表の Status 列は、このステップで見つかった問題に基づいて決定します。

論証の連鎖の欠落(AC-)
  • 各セクションの主な研究上の主張または貢献を対応付けます。
  • 確認事項:Introduction の主張は Methods の設計によって裏付けられていますか?
  • 確認事項:Results は Methods で示された測定項目に対応していますか?
  • 確認事項:Discussion は Results から導かれる結論を述べていますか?
  • 確認事項:Conclusion は Discussion で述べられた結果と一致していますか?
  • 連鎖が途切れている箇所ごとに、該当するセクションの参照を含む Issue AC-N を作成します。
裏付けのない主張(UC-)
  • 証拠、引用、またはデータの参照がない断定的な記述を探します。
  • Introduction と Discussion の強い主張に注目します。
  • 裏付けのない主張ごとに、該当する主張のテキストを正確に引用した Issue UC-N を作成します。
用語の不一致(TI-)
  • Introduction で導入された技術用語とモデル/手法名をすべて記録します。
  • すべてのセクションを比較し、表記の違いを確認します。明示的な名称変更、論文の途中で導入される略語、正式名称と非公式名称の混在などが対象です。
  • 不一致ごとに、すべての用語のバリエーションをセクションの位置情報とともにそのまま引用した Issue TI-N を作成します。
  • 略語が Introduction で初出時に定義されている場合は、不一致として報告しないでください。
数値の矛盾(NC-)
  • Introduction に記載された定量値(サンプルサイズ、精度に関する主張、改善率など)を抽出します。
  • Results と Conclusion に記載された値と比較します。
  • 相違がある場合は、両方の値とその記載箇所を引用した Issue NC-N を作成します。
  • 定量的な文脈ではない数値(図のラベル、セクション番号、脚注番号)は無視します。
ステップ 3 — Part 1 Argument Chain View を作成する
  • AC- の分析が完了したら、分析結果に基づいて表を作成します。
  • 該当するセクション間に AC- の問題がない場合に限り、Status を「Connected」とします。
  • セクション間の移行に関わる AC- の問題が 1 件以上ある場合は、Status を「Gap」とします。
  • 論文に記載されたセクションタイトルをそのまま使用します。
ステップ 4 — レポートを作成する
  • オプトアウトの確認: レポートを作成する前に、ユーザーの元のトリガープロンプトを確認し、次の語句(大文字と小文字を区別しない完全一致)が含まれているか確認します:english only、no bilingual、only english、不要中文。いずれかが検出された場合は、レポートからすべての > **[Chinese]** ... の引用ブロックを省き、英語のみの問題項目を作成します。どれも検出されなかった場合は、通常どおり中国語の引用ブロックを含めます。
  • 出力仕様に記載された固定形式に従って、2 部構成のレポートを作成します。
  • レポートは読みやすさを考慮し、最初に Part 1 の表、次に Part 2 のカテゴリ別の問題を掲載します。
  • ファイル入力: 出力ファイル名を {input_filename_without_ext}_logic.md とし、Write ツールを使用して書き込みます。
  • テキスト貼り付け入力: レポートを会話内に出力します。
  • 最後に問題数の概要を記載します:「Found N issues: X AC-, Y UC-, Z TI-, W NC-.」

出力仕様

出力形式条件
logic_reportMarkdown ファイル {input_filename_without_ext}_logic.mdファイル入力
logic_report会話への出力テキスト貼り付け入力

固定の 2 部構成レポート形式:

# Logic Verification Report

**Paper:** [title or filename]
**Date:** [date]

## Part 1 — Argument Chain View

| Section | Primary Claim | Connects To | Status |
|---------|--------------|-------------|--------|
| Introduction | [claim] | Methods | Connected / Gap |
| Methods | [claim] | Results | Connected / Gap |
| Results | [claim] | Discussion | Connected / Gap |
| Discussion | [claim] | Conclusion | Connected / Gap |
| Conclusion | [claim] | — | Terminal |

## Part 2 — Categorized Issue List

### Argument Chain Gaps

**Issue AC-1: [Descriptive Title]**
**Section:** [Introduction]
**Problem:** [description]
**Why this matters:** [impact on argument coherence]
**Suggestion:** [one-sentence directional suggestion]
> **[Chinese]** 问题:... 为什么重要:... 建议:...

### Unsupported Claims

**Issue UC-1: [Descriptive Title]**
[same three-part structure + Chinese blockquote]

### Terminology Inconsistencies

**Issue TI-1: [Descriptive Title]**
[same structure — quote exact verbatim terms from the paper]

### Number Contradictions

**Issue NC-1: [Descriptive Title]**
[same structure]

注記:

  • Part 1 の Argument Chain View 表は英語のみとします(構成に関するもので、言語に依存しません)。
  • Part 2 の問題項目は英語と中国語の併記とし、英語で問題点/理由/提案を記載した直後に > **[Chinese]** ... の引用ブロックを続けます。
  • 各カテゴリ内で問題番号を連番にします(AC-1、AC-2、…、UC-1、UC-2、…)。

エッジケース

状況対応
入力が一部のみ(単一セクション、または 500 語未満)拒否します:「セクション間の検証には論文全文が必要です。原稿全体を提供してください。」
論文に考察がない(例:結果から直接結論へ進む)実際に存在するセクションに合わせて連鎖ビューを調整し、表の欠落セクションには「N/A」と記載します
論文のセクションタイトルが中国語表およびすべてのセクション参照では、中国語のタイトルをそのまま使用します
あるカテゴリで問題が見つからないパート 2 にカテゴリ見出しを含め、「このカテゴリでは問題は特定されませんでした。」と記載します
ユーザーが Skill に特定した問題の書き換えを依頼する辞退します:「この Skill は問題を特定し、方向性を提案するだけです。書き換えには Polish Skill を使用してください。」
数値が定量的でない文脈(図のラベル、セクション番号など)に現れる無視し、実証的な主張と定量的な結果のみに注目します
略語が Introduction で初めて使用された際に定義されている定義済みの略語は意図的なものなので、TI-の不整合として指摘しません

フォールバック

シナリオフォールバック
Structured Interaction を利用できない事前質問なしでダイレクトモードを続行します。ファイルか貼り付けかが本当に不明な場合に限り、プレーンテキストで尋ねます
Read ツールが失敗する(ファイルが見つからない、または読み取れない)論文のテキストを貼り付けるようユーザーに依頼します
Write ツールが失敗するロジックレポートを会話内に提示し、_logic.md として手動で保存するようユーザーに案内します
論文が非常に長い(20,000 語を超える)「非常に長い原稿の場合、分析は概算になる可能性があります。」と警告します。必要に応じて特定のセクションの組み合わせに絞ることを提案します

例

最小限の呼び出し(ファイル入力):

ユーザー:「草稿のロジックを確認してください:/papers/urban_model.pdf」

戦略の確認(ダイレクトモード — ファイルパスが指定されているため、事前質問なしで続行)

ステップ 2 の分析を実行:AC-1(Introduction→Methods の連鎖の断絶)、TI-1(用語の表記揺れ)を検出 ステップ 3 で AC-1 から Status 列を導出

出力の抜粋(urban_model_logic.md):

# Logic Verification Report

**Paper:** urban_model.pdf
**Date:** 2026-03-12

## Part 1 — Argument Chain View

| Section | Primary Claim | Connects To | Status |
|---------|--------------|-------------|--------|
| Introduction | Urban sprawl prediction framework proposed | Methods | Gap |
| Methods | Gradient boosting model trained on parcel data | Results | Connected |
| Results | 82% accuracy on hold-out set | Discussion | Connected |
| Discussion | Model generalizes to mid-size cities | Conclusion | Connected |
| Conclusion | Framework advances urban planning practice | — | Terminal |

## Part 2 — Categorized Issue List

### Argument Chain Gaps

**Issue AC-1: Introduction Framework Not Reflected in Methods Design**
**Section:** [Introduction], [Methods]
**Problem:** The Introduction proposes a "multi-scale prediction framework," but Methods describes a single-scale gradient boosting model with no multi-scale architecture.
**Why this matters:** Reviewers will note the mismatch between the stated contribution and the actual implementation, undermining the novelty claim.
**Suggestion:** Either update the Introduction to describe a single-scale model, or add a multi-scale component to Methods with justification.
> **[Chinese]** 问题:引言提出"多尺度预测框架",但方法章节仅描述单尺度梯度提升模型,无多尺度架构。为什么重要:审稿人会注意到声明贡献与实际实现之间的不一致,削弱新颖性声明。建议:修改引言以描述单尺度模型,或在方法中补充多尺度组件并加以说明。

### Unsupported Claims

No issues identified in this category.

### Terminology Inconsistencies

**Issue TI-1: "Urban Sprawl Prediction Framework" vs. "Urban Growth Model"**
**Section:** [Introduction, 第2段], [Methods, 第1段]
**Problem:** The Introduction uses "urban sprawl prediction framework" while Methods refers to the same system as "urban growth model" without an explicit rename or definition.
**Why this matters:** Readers and reviewers may interpret these as different systems, reducing clarity.
**Suggestion:** Choose one term and use it consistently throughout, or introduce the alternative as a defined synonym on first use.
> **[Chinese]** 问题:引言使用"城市蔓延预测框架",方法章节将同一系统称为"城市增长模型",未作明确说明。为什么重要:读者和审稿人可能将其理解为不同系统,降低论文清晰度。建议:统一使用一个术语,或在首次出现时将替代名称定义为同义词。

### Number Contradictions

No issues identified in this category.

問題が 2 件見つかりました:AC- 1 件、UC- 0 件、TI- 1 件、NC- 0 件。


Skill: logic-skill Conventions: references/skill-conventions.md

コメント