研究計画（research-plan）

Research → plan.md + ソースファイル

3つのスキルから成るスイートのオーケストレーター：

• source-triage：ソースを発見し、読み取り前にアクセス、到達可能性、整合性、グレードを分類する。
• research-plan（このスキル）：到達可能なものを読み、計画とソースファイルを作成する。
• evidence-check：すべての主張が実際のソースに基づいているかを独立監査する。

兄弟スキルがない場合は、以下の要約に従ってインラインで各ステップを実行する。決定論的チェッカーはこのスキル内に含まれる：python3 <this skill's folder>/scripts/research_checks.py。これはPython標準ライブラリのみで動作し、独自のコードサンドボックス内で実行する（PDFテキストには pypdf が必要；不足している場合は pip install pypdf）。決定論的チェックが必要な場面では常にこれを使用する。コード実行が利用できない場合のみ手動でチェックし、その旨を明記する。

出力（固定ファイル名）

research/<topic-slug>/plan.md
research/<topic-slug>/sources__<topic-slug>__<YYYY-MM-DD>.md   ← 人間用
research/<topic-slug>/ledger.md                                ← 作業状態、逐次書き込み
research/<topic-slug>/notes/<citekey>.md                       ← ソースごとのノート
research/<topic-slug>/notes/raw/<citekey>.txt                  ← 生の全文（API XML/PDFテキスト）、逐語保持
research/<topic-slug>/claims.json                              ← 引用付きの主張、チェック用

• <topic-slug>：3～6語の具体的な単語を小文字ハイフン結合（例：starch-fructan-engineering-plants）。
• 以前の実行を上書きしない。同じトピック：新しい日付のソースファイル＋変更履歴エントリ。新しい角度：新しいスラグ。
• ユーザーの接続フォルダがあればそこで作業し、なければカレントディレクトリで作業する。最後に両方のメインファイルを送信する。

モード

• auto（デフォルト）：一時停止なし。最後に選択内容を一覧表示する。step：各 ◆ で停止する。
• quick：8～15ソースを維持。上位最大5ソースは全文読み、残りは sections:（要約＋結果＋考察）。反証：最大3回の検索。スノーボールは任意。
• deep：25＋ソース、スノーボール、並列スカウト、全A/Bソースの全文読み。
• update：ユーザーがファイルをダウンロードした、または更新を依頼した場合 → フェーズ6。
• リクエスト内のハード制約（2つの書籍章、語数制限、必須データベースを要求するルーブリックなど）は提案ではなく要件。検証済みのソースで満たすか、どの制約が満たせなかったかを明確に述べる。

フェーズ0 — フレーム設定

1メッセージで以下を定義：

• 計画の目的とその用途（エージェント / スキル / MCP / レポート / 実験 / 決定）。
• 範囲、年数、深さ、モード。
• ハード制約。
• 2～6の MECE軸（重複のないサブ質問）。

タスクリストを作成する：フレーム設定 → トリアージ → 読み取り → 統合 → 書き込み → チェック。タスクツールがない場合は、research/<slug>/run-notes.md の先頭にリストを保持する。 ◆ チェックポイント：軸＋範囲。

フェーズ1 — トリアージ（source-triage を実行）

ライブラリを最初に → 発見 → 名前を挙げるものすべてに対して整合性 → アクセス＋到達可能性 → グレード／役割／⭐。

台帳は逐次書き込む。 各検索と分類したソースを即座に追記する。コンテキストは実行中に失われる可能性があり、台帳ファイルだけが残るからである。

ディープモードでサブエージェントを使用する場合、各軸に対して1人のスカウトを並列で送る。各スカウト：

• 最大15回のツール呼び出し。
• notes/<axis>.md に「要点」「引用付きの発見（リンク付き）」「推論」「ギャップ」のセクションを書き込む。
• 候補を台帳に追記する。

サブエージェントがない場合、軸を順次実行する。 ◆ チェックポイント：アクセス分類ごとの件数＋⭐ショートリスト。

フェーズ2 — 読み取り

• readable／held なソースを、最高グレードから読む。生のルート（Europe PMC XML はシェル経由、PDFテキスト）を優先し、テキストを notes/raw/<citekey>.txt に保存する。
• WebFetch による読み取りは read: full (extracted) とする。理解には使用できるが、それに基づく主張には ⚠ extracted を付け、引用で「裏付けられた」とは決して言わない。
• 長いテキストは、参考文献リストに到達するまでチャンクで読む。Quick モードでは sections: 読み取りを許可し、ラベルを付ける。
• 台帳の各行に read を設定：full · sections:<which> · abstract · metadata。
• ソースごとに notes/<citekey>.md に以下を保持：
  • WHY（問題）
  • HOW（方法、データ）
  • WHAT（発見：数値は正確にコピー、セクション／ページ位置を添える）
  • LIMITS。各制限には author-stated（位置情報付き）または my-inference のタグを付ける。 全文がない場合：limits: not assessed (read: abstract)。
• 計画書で主張を支える文には、生のテキストから40文字以上の逐語引用を claims.json にコピーする：{"id","claim","source":"notes/raw/<citekey>.txt","quote","locator"}。
• ノートを記憶だけで埋めない。「私が読んだ部分にはなかった」は有効な回答である。

フェーズ3 — 統合

• エビデンスマトリックス： ソース × テーマ（支持／反証／沈黙）。ソースごとではなくテーマごとにグループ化する。
• 収束（3以上が一致） · 乖離（方法、集団、または時間で説明） · 沈黙（2未満のソース：ギャップ）。
• 独立研究のカウント： 「4件の研究（2件は独立）」。共有データセット、コホート、チーム、トライアルは1回と数える。
• 反証パス： 主要な発見に対して、ヌル結果、失敗した再現、批判を検索する。何も見つからなくても検索語を記録する。Quick モード：最大3回の検索。
• 否定的な主張（「誰もXをやっていない」）は、その背後にある検索と、検索範囲の限定を伴う。
• 貢献チェック： ユーザーはこの計画を使って以前はできなかった何ができるか？どの⭐ダウンロードが最も効果を変えるか？
• 悪魔の代弁者パス： 最も強力な反論、チェリーピッキング、疑問視されていない前提。都合が悪くても異議を落とさない。

フェーズ4 — ファイルの書き込み

plan.md

• ヘッダー： 目的 · 用途 · 範囲 · 日付 · ソースファイルへのリンク · エビデンスベース：N 全文（生） · N 全文（抽出） · N セクション · N 要約 · N メタデータ。
• 本文： リクエストに応じた内容。
• 引用： <sup>[3](sources__<slug>__<date>.md#s3)</sup>。初出順に番号付け。
• 引用後のフラグ：
  • ⚠ abstract-only：要約のみ読了。
  • ⚠ metadata-only：タイトル／掲載先のみ既知。
  • ⚠ extracted：WebFetch経由で読んだため、逐語チェック不可。
  • ⚠ preprint。
• 閉じ： 未解決の疑問 · ⭐ダウンロードで解けること · 満たせなかった制約（ある場合） · 変更履歴。

sources____.md

# ソース — <読みやすいトピックタイトル>（<日付>）
計画：[plan.md](./plan.md) · 質問：<1行> · モード：<quick|deep> · 検索：<データベース＋日付>
件数：N 合計 · ⭐ X · readable R · free-but-blocked B · paywalled P · non-paper W · excluded E     （合計＝台帳の全行）
エビデンスベース：<plan.mdと同じ内訳>

## ⭐ 1. ダウンロードしてローカルで確認すべきもの
| # | ソース | 種類 | グレード | アクセス・ライセンス | <構築物>にとって重要な理由 | 入手方法 | 保存名 | 再配布可否 |

## 2. オープンで読み取り可能（計画に統合済み）
### <テーマA>
<a id="s1"></a>**[1]** 著者（年）.[タイトル](URL). *掲載誌／書籍名、ページ*. [DOI](https://doi.org/…) — `gold · CC-BY` · `readable:europepmc-xml` · 読み：全文 · グレードA · エビデンス
（プレプリントの場合、この行に `` `preprint` `` ラベルを追加。チェッカーはその引用に `⚠ preprint` を要求する。）
- WHY … · HOW … · WHAT … · LIMITS …

## 3. 無料だがAIエージェントにはブロックされている（自分で開くこと）
エントリ＋確認されたブロック＋直接リンク＋グリーンコピーへのリンク

## 4. ペイウォールあり
エントリ＋グリーンコピーリンク（「見つからず」の場合も）＋要約レベルの知見（使用した場合）

## 5. 論文以外のソース
種類別、ティアT1–T5。灰色文献：URL＋アクセス日＋スナップショットリンク。

## 6. 除外されたもの（理由付き）
除外レコードごとに1行、**除外：** <理由> で始める。

## 7. 検索ログとアクセス経路レポート

ルール：

• すべてのエントリには計画書の番号と一致する <a id="sN"> アンカーがある。
• すべてのURLは [テキスト](URL) リンク。ヘッダー行も含む。
• ⭐行はメインエントリ番号を指す。
• アクセス分類ごと、次にテーマごとにグループ化する。

フェーズ5 — チェック、そして配信

1. 決定論的チェック： python3 <this skill's folder>/scripts/research_checks.py all research/<slug>/ を実行する。すべてのエラー（アンカー欠落、⚠フラグ欠落、件数不一致、語彙、引用がソースにない）を修正し、パスするまで再実行する。
2. エビデンスチェック： evidence-check を実行する。
   • サブエージェントありの場合： 新しいエージェントで、ファイルのみを与えて実行。
   • サブエージェントなしの場合： 同一セッション内で、すべてのファイルをディスクから再読み込みし、書き込み時の記憶を使用しないチェック。same-session (not independent) とラベルを付け、これに依存する前に新しいチャットで evidence-check を実行するようユーザーに提案する。
3. スポットオープン： アクセス分類ごとに3リンクを開く。出版社からの403/429は何の証明にもならない。その旨を述べる。

両方のファイルを以下の1行コメント付きで配信する：

• 計画の見出し。
• ⭐の数。
• 手動ダウンロードが必要なソースの数。
• 満たせなかった制約。

auto モードでは、選択内容（軸、年、データベース、フィルタ、上限）も一覧表示する。

フェーズ6 — 更新（ユーザーがダウンロードした後）

1. フォルダ内のファイルを保存名と照合する。
2. 検証する（python3 <this skill's folder>/scripts/research_checks.py pdf <files>）。
3. 各ファイルを読み、生テキストを保存し、held: user と read: full を設定する。
4. 再グレードし、仮の ? グレードを削除する。
5. ⚠フラグを引用付きの支持された主張に変えるか、新しいテキストが矛盾する主張を書き直す。
6. 変更されたセクションに対してフェーズ5を再実行する。
7. 新しい日付のソースファイルを書き、変更履歴エントリを追加する。

注意すべき点（Red flags）

考え	現実
「読んだ後にアクセスを確認しよう」	まずトリアージしないと、ペイウォールの要約がこっそり計画を歪める。
「OAだから読める」	経路をテストせよ。OA記事でもテストでブロックされた。
「WebFetchがテキストをくれた」	モデルの抽出結果だ。読むには使えても、引用には使うな。
「この論文／章は知っている」	経験から誤ったタイトル、誤った書籍、存在しない論文を生成したことがある。まず確認せよ。
「DOIが解決するから章は正しい」	書籍タイトルとページも確認せよ。
「ブロックされたからミラーを試そう」	絶対にダメ。正規のグリーンコピーを見つけるか、ユーザーにリストアップせよ。
「台帳は最後に書こう」	コンテキストリセットで消える。逐次書け。
「3つの研究が一致している」	独立研究を数え、反対の結果が出た研究を検索せよ。