medical-imaging-review

医用画像AIレビュー

主張を最初の出典までさかのぼって監査できる、追跡可能なレビュー成果物を作成します。実際のプロジェクト状況と、未解決の人による確認事項を報告してください。編集上の成果を約束したり、未完成のプロジェクトを完了済みのレビューとして説明したりしないでください。

範囲と厳格な制約

3つの方法論的ファミリーにまたがる、次の4つのルートトークンのみをサポートします。

ユーザーの意図	ルートトークン	ルート
分野を解釈する	narrative	ナラティブレビュー
手法のファミリーを比較する	method-survey	手法サーベイ
利用可能なエビデンスと研究ギャップをマッピングする	scoping	スコーピングレビュー
統計的統合を行わずに、焦点を絞った質問に答える	systematic	定性的統合を伴うシステマティックレビュー

このスキルでは、メタアナリシス、ネットワークメタアナリシス、個々の参加者データのメタアナリシス、またはアンブレラレビューを実施しないでください。プールされた推定値、異質性統計量、フォレストプロットやファンネルプロット、レビュー重複分析、またはレビュー単位の評価が必要な依頼の場合は、これらにはこの環境では提供されていない、専門的なエビデンス統合方法のワークフローが必要だと明確に伝えて中止してください。確認できないワークフローの名前を挙げたり、文章や単純な平均でこれらの手法を近似したりしないでください。

lit-search からのコーパス引き継ぎ。 どのルートでも、検索の取得部分（網羅的な検索と再現率を示すエビデンス）は lit-search スキルの担当です。まずそれを実行し、dois.md／references.md（および --bibtex を指定した場合は references.bib）を候補プールとして使用してください。同梱のスクリプトで実行結果を取り込みます。スクリプトは成果物を読み取り専用のエクスポートとして search/exports/litsearch-<run_id>/ にコピーし、result_count をPRISMAの特定総数とする行を1件 search/search_log.csv に追加します。その実行結果がすでに取り込まれている場合、またはPRISMAの総数が欠けている場合は、何も書き込まずに処理を拒否します。

python3 <skill_dir>/scripts/import_litsearch.py --project-dir <project_dir> --run-dir <lit-search run dir> --searcher-id <named human>

次に、このスキルの人によるスクリーニングゲートに、その候補プールから引き継ぎます。このスキルはレビューを計画して執筆するものであり、検索の取得を再実行するものではありません。

文献収集や草稿作成の前に、references/REVIEW_TYPES.md を読んでください。ルートトークンには narrative、method-survey、scoping、systematic のみを使用してください。このスキルでの systematic は、常に定性的統合を意味します。エビデンス収集の開始前であれば、明示的な決定メモを添えて、修正後のルートを記録できます。収集開始後は、プロジェクトのルートを変更できません。別のルートに変更する場合は、以前のプロジェクトを凍結し、記録済みで出所を保持した成果物のみを引き継いで、新しいプロジェクトを初期化してください。

インテークゲート

複数段階のレビューを開始する前に、以下を確認して記録してください。

1. レビュールートと研究上の問い。
2. 対象となる集団、モダリティ、解剖部位、タスク、設定、アウトカムまたは概念。
3. 対象ジャーナルまたは読者、および拘束力のある指示。
4. 検索対象期間、言語の制限、データベース、グレイリテラチャーの方針、エビデンスのカットオフ。
5. 想定する成果物と現在のプロジェクト段階。
6. 該当する場合、スクリーニング、抽出またはチャーティング、裁定、バイアスリスク評価、確実性評価を担当する、氏名が指定された人の役割。
7. 計画しているAI支援とその開示。

スコーピングおよびシステマティックのルートでは、プロトコルや検索を設計する前に references/REPORTING_STANDARDS.md を読んでください。必須の決定事項が欠けている場合は、明確にラベル付けした計画案を示す範囲でのみ作業を続けてください。重大な影響を及ぼすプロトコル上のルールを、黙って選択しないでください。

プロジェクトの契約

新しい複数ステップのプロジェクトは、必ず同梱スクリプトで初期化します。

python3 <skill_dir>/scripts/init_review_project.py --parent <workspace-root> --name <topic-slug> --route <narrative|method-survey|scoping|systematic>

トピックのスラッグには、小文字のケバブケースを使用します。初期化スクリプトは、新しく作成されたプロジェクトのパスを出力します。

review_project/<topic-slug>-<YYYYMMDD-HHMMSS>-<8hex>/

以降のワークフローでは、出力されたパスを <project_dir> として扱います。初期化スクリプトは既存の対象を拒否し、別のプロジェクトディレクトリには書き込みません。生成された子ディレクトリを事前に作成、再利用、名前変更、またはフラット化しないでください。作業を再開する場合は、初期化を再実行せず、該当する既存の <project_dir> を選択します。

生成される主要な成果物は次のとおりです。

<project_dir>/
├── review_config.yaml
├── REVIEW_CONTEXT.md
├── IMPLEMENTATION_PLAN.md
├── PARADIGM.md
├── manuscript.md
├── references.bib
├── claim_ledger.csv
├── AI_USE_DISCLOSURE.md
└── route-specific subdirectories

REVIEW_CONTEXT.md は持ち運び可能なプロジェクト概要として使用し、review_config.yaml はルート、スコープ、基準、人間の役割、AI の使用、エビデンスの締め切り、ステータスに関する信頼できる情報源として使用します。各作業セッションの開始時に、両方を読み直してください。ツール固有の指示ファイル名には依存しないでください。

成果物を変更する前に、<project_dir> を確認してください。既存の内容を上書き、切り詰め、リセット、置き換えないでください。無関係な内容を維持し、限定的なパッチまたはマージを適用します。重大な競合を解決する前に確認してください。範囲を限定した助言の回答はインラインのままにできます。永続的な成果物が必要なタスクでない限り、プロジェクトを初期化しないでください。

第 1 段階の計画で永続的な成果物が必要な場合、回答には、実行した初期化コマンド、初期化スクリプトが出力した衝突安全な <project_dir>、および現在のプロジェクトステータスを明示してください。初期化が成功する前に、プロジェクトが存在するかのように示してはいけません。

安定した引用キーと主張台帳

調査と草稿作成では、たとえば [@smith2024model] のような安定した引用キーを使用してください。references.bib は、草稿作成とレンダリングに使用するプロジェクトの参考文献ファイルとして維持してください。ユーザーが承認した RIS、EndNote、Zotero などのエクスポートは変更不可のインポート成果物として保持し、承認済みレコードを安定した出典識別子を変更せずに references.bib へ正規化してください。作業中の草稿では、[17] のような変更可能な番号付き引用を使用しないでください。最終的な書式設定の段階でのみ、安定した引用キーから対象ジャーナルの番号順または著者・年方式のスタイルをレンダリングしてください。

イニシャライザーが定めた claim_ledger.csv のヘッダーを一字一句そのまま維持してください。各行は、原子的な主張と出典のペアを1つ記録します。すなわち、主張の重要な種類、指標、方向、およびその箇所に対応する引用キーの組を記録します。すべての節に文単位の引用を割り当てるのではなく、検証前に複合文を分割してください。

claim_id,section,claim_text,claim_type,citekey,source_id,source_locator,evidence_excerpt,population_or_dataset,data_split,split_unit,comparator,metric,estimate,unit,uncertainty_interval,direction,access_level,source_role,access_uri,accessed_at,verification_status,verified_by,verified_at,notes

スキーマのバージョンを明記した移行なしに、列の名称変更、並べ替え、削除、追加を行わないでください。

vNext 以前の22列の台帳は不変のレガシーインポートとして扱い、スキーマ2.0として扱わないでください。新しいスキーマ2.0の台帳を作成し、日付入りの移行マニフェストで列名に基づいて値を対応付け、新しい evidence_excerpt、split_unit、source_role の各フィールドには明示的に値を入力するか、未解決であることを示してください。レガシーファイルは保持してください。レガシーの行に対し、黙って値を埋めたり、列を並べ替えたり、意味を読み替えたりしないでください。移行した主張は、指名された人間が対応付けたレコードを検証するまで保留のままです。

事実、定量、方向性、新規性、規制、比較に関する主張すべてについて、以下を行ってください。

1. 1つ以上の安定した引用キーを紐付けます。
2. 根拠となるページ、表、図、セクション、または抄録の箇所を正確に記録します。
3. 一次資料に照らして、メタデータと主張の根拠を検証します。
4. 誰がいつ検証したかを記録します。
5. verification_status が未解決の間は、その主張を整った文章に含めないでください。

抄録しか閲覧できない場合は、抄録が直接裏付ける内容に主張を限定してください。閲覧できない本文から、内部アーキテクチャ、正確な性能、因果の方向性、または「初めて」のような優先性に関する主張を推論しないでください。references/CITATION_INTEGRITY.md を参照してください。

人間によるガバナンスのチェックポイント

LLM エージェントは、検索語の翻訳、重複排除の提案、優先順位付け、抽出草稿、整合性チェック、文章作成を支援できます。ただし、独立した人間の査読者には数えません。また、そのような査読者として記載してはなりません。

スコーピングレビューまたはシステマティックレビューを正式な手順で行う場合：

• 指名された人間の査読者2名が、タイトル・抄録および全文のスクリーニングをそれぞれ独立して完了する必要があります。指名された人間の裁定者が不一致を解決します。
• データのチャーティングまたは抽出では、プロトコルで事前に定めた方法に従い、独立した二重抽出、または1名による抽出と別の人間による独立した検証のいずれかで、指名された人間2名を関与させる必要があります。
• バイアスリスクの評価は、独立した人間による評価を行い、合意形成または裁定の過程を記録する必要があります。
• エビデンスの確実性を評価する場合は、人間による承認が必要です。
• 正式な手順で行ったスクリーニングの判断は、<project_dir>/screening/screening_decisions.csv に保存する必要があります。
• AI の支援内容、モデルまたはツールの識別情報、タスク、日付、人間による監督、および検証用サンプルがあればその内容を、ジャーナルと機関の要件に従って <project_dir>/AI_USE_DISCLOSURE.md に記録する必要があります。

人間のチームまたは必要な記録を確保できない場合は、暫定プロトコル、検索対象、スクリーニング提案、抽出草稿、または評価草稿として明確にラベル付けした段階で作業を止めてください。正式なスクリーニング、抽出、バイアスリスク評価、またはレビュー自体が完了したと主張しないでください。

標準の役割

次の4つの層を分けて扱います。

1. 実施指針は、レビューの進め方を定めます。
2. レビュー報告の指針は、レビューで何を報告するかを定めます。
3. 一次研究の報告フレームワークは、報告の完全性を抽出するのに役立ちますが、バイアスリスク評価ツールではありません。
4. バイアスリスクと確実性のフレームワークは、それぞれ異なるレベルのエビデンスを評価するものであり、相互に置き換えられません。

review_config.yaml でこれらの層を選択し、バージョンを指定してください。ルートごとの対応表については、references/REPORTING_STANDARDS.md を使用してください。

スタイルの優先順位

スタイルに関する判断は、次の順序で行います。

1. 投稿先ジャーナルの要件。
2. レビュー方法と報告に関する要件。
3. ユーザーの明示的な要件。
4. 検証済みの模範例で確認されたパターン。
5. このスキルのデフォルト設定。

見出しの深さ、番号付き見出し、囲み枠、表の数、引用の密度、ベンダーの配置、要点の形式、言い回しなどのスタイル上の好みは、警告にとどめます。これらが上記の優先順位を覆したり、それだけでレビューを不合格にしたりすることはありません。事実の完全性、ルートの妥当性、再現性、人間による作業の来歴、未解決のバイアスまたは確実性の判定ゲートは、作業の進行を妨げることがあります。

模範例の分析が役立つ場合に限り、references/PARADIGM.md を読んでください。模範例はスタイルの根拠として扱い、科学的主張の根拠としては扱わないでください。

ルートを考慮したワークフロー

1. ルートを選択し、設定します。インテークを完了し、対応するルートを1つ選び、その判断、標準、役割、エビデンスのカットオフを記録します。
2. 安全に初期化します。init_review_project.py を1回実行し、出力された <project_dir> を記録します。
3. 方法を設計します。スコーピングまたはシステマティックレビューでは、スクリーニングを始める前にプロトコルとデータベースごとの検索計画を確定します。
4. 情報源を収集し、登録します。正確なクエリ、プラットフォーム、日付、エクスポート、重複排除の判断、安定した citekey、情報源の来歴を保持します。
5. 人間による判定ゲートを通過します。ルートで求められるスクリーニング、マッピングまたは抽出、バイアスリスク、確実性の各ステップを完了し、記録します。
6. 適用範囲内で統合します。ナラティブレビューでは正当な理由に基づくコーパスを解釈し、スコーピングレビューではエビデンスをマッピングし、システマティックな質的レビューでは統計的統合を行わずに統合します。
7. 検証済みの記録に基づいて原稿を作成します。モデルの記憶ではなく、REVIEW_CONTEXT.md、抽出またはマッピングの表、claim_ledger.csv に基づいて <project_dir>/manuscript.md を作成します。
8. 検証し、状況を報告します。該当するチェックを実行し、未解決の判定ゲートを列挙して、成果物を正確に表示します。

このワークフロー内で、質的システマティックレビューをメタアナリシスに変更しないでください。統計的統合が必要になった場合は、現在の成果物を確定してから、専門のワークフローに引き継いでください。

エビデンスと情報源へのアクセス

ルートを選択する前に、現在のセッションで利用可能なツールを確認してください。目的に特化した文献コネクター、ユーザーが許可した Zotero ライブラリ、ローカルの PDF、一次情報のページを優先してください。特定の MCP サーバーがインストールされていると想定しないでください。ユーザーから明示的な依頼がない限り、ツールの設定を編集したり、コネクターをインストールしたりしないでください。

ツールアダプターと代替手段については、references/MCP_SETUP.md を読んでください。検索範囲、日付、結果件数は、研究課題と確定済みのプロトコルに従う必要があります。このスキルでは、普遍的な件数や最新性の割り当てを定めていません。

監査インターフェース

作業用原稿ができたら、次を実行します。

python3 <skill_dir>/scripts/audit_manuscript.py <project_dir>/manuscript.md --route <narrative|method-survey|scoping|systematic> --project-dir <project_dir> --fail-on critical --output <project_dir>/review_outputs/audit_report.md

--profile <project_dir>/style_profile.json は、そのプロファイルが現在のジャーナル要件または検証済みの参考例に基づいて作成されている場合に限り追加します。プロファイルは警告のみのスタイルチェックを制御します。

位置引数の原稿パス、--route、--project-dir は、同じ生成済みプロジェクトを示している必要があります。--fail-on critical は、自動検出された重大な問題がある場合に失敗ステータスを返します。--output は Markdown レポートを出力します。自動検出された問題がゼロの場合でも、実質的なチェックの結果は not_assessed と報告し、コンプライアンスへの合格、ジャーナル投稿可能な原稿、または専門家の承認とみなしてはいけません。自動チェックの成功は、出典による裏付け、ルートへの準拠、人的確認ゲートの完了、または専門家の承認を証明するものではありません。

提出時のステータス表記

完了したことと、未完了のことを明記します。ステータス表記には、次のようなものが適しています。

• 人による承認待ちのプロトコル草案
• 検索を実施済み。重複排除は未完了
• 2 名による判定待ちのスクリーニング候補
• 人による検証待ちのデータ抽出草案
• 人による合意待ちのバイアスリスク草案
• 検証済みの採択研究に基づく定性的統合が完了
• 未解決の主張を claim_ledger.csv に列挙した、manuscript.md のナラティブまたは方法調査の草案

エンジニアリングの完了、科学的方法上の完了、人による判定を、単一のステータスにまとめてはいけません。

学び

learnings/ には、日付入りのインシデント後メモが保存されています（例：相互に矛盾する JSON テンプレートが、すべてのゲートを通過して実行時まで残った事例）。監査ルールや参照契約を変更する前に確認し、手戻りに値する想定外の事態が起きた場合はメモを追加してください。

参照ファイル

ファイル	参照するタイミング
references/REVIEW_TYPES.md	ルートを開始または変更する前
references/REPORTING_STANDARDS.md	実施、報告、一次報告、バイアスリスク、または確実性に関する指針を選ぶとき
references/WORKFLOW.md	選択したルートを各フェーズに沿って実行するとき
references/TEMPLATES.md	生成される <project_dir> の成果物契約を把握するとき
references/CITATION_INTEGRITY.md	出典を登録し、主張を検証するとき
references/MCP_SETUP.md	利用可能なツールを見つけ、出典の代替手段を選ぶとき
references/PARADIGM.md	参考例から拘束力のないスタイル指針を導き出すとき
references/DOMAINS.md	ナラティブまたは方法調査のためのドメイン分類を検討するとき
references/HALLUCINATION_PATTERNS.md	事実誤認や帰属の誤りのパターンを確認するとき
references/QUALITY_CHECKLIST.md	ルート固有の成果物と未解決のゲートを監査するとき