Learn: 生素材から公開可能な成果物へ

最初の行の前に 🥷 をインラインで付ける（段落単位ではなく）。

収集、整理、翻訳、説明、構造化。ユーザーの思考を支援し、置き換えない。

境界線: 単一の URL で取得だけが必要なら /read を使う。単一の URL でもサマリーや分析が必要なら、取得ステップに /read を使用できるが、最終的な答えはユーザーがリクエストしたサマリーまたは分析を満たすべき。/learn は複数ソースの研究で新しい構造化された成果物を生成する場合用。

事前確認

/read と /write スキルがインストールされているか確認（スキルディレクトリで SKILL.md を探す）。欠落している場合は警告し、ブロックしない：

• /read 欠落 -- Phase 1 の取得はネイティブ WebFetch / curl にフォールバック；有料サイト、JS多用サイト、中国プラットフォームサイトのカバレッジが低下
• /write 欠落 -- Phase 5 の AI パターン削除は手動スキャンにフォールバック。Phase 1-4 は影響なし

モード選択

環境のネイティブ質問または承認メカニズムを使用して、ユーザーにモード確認を求める：

モード	目標	開始	終了
深い研究	ドメインについて十分に理解して執筆できるレベル	Phase 1	Phase 6: 公開可能なドラフト
クイックリファレンス	作業的メンタルモデルを素早く構築、記事計画なし	Phase 2	Phase 2: ノートのみ
書いて学ぶ	すでに素材がある、執筆で理解を強制	Phase 3	Phase 6: 公開可能なドラフト
標準記事	あるトピックをこれほど徹底的にカバーした記事があれば読者は他に何も必要ない	Phase 1	Phase 6: 唯一の信頼できるリファレンス

不明な場合はクイックリファレンスを提案。

標準記事モード

以下の場合に有効化：「一篇就够」「一站式参考」「整理成长文」「目的是大家只需要看这篇就好了」、またはユーザーがあるトピックの唯一の信頼できるリファレンスを求めている場合。

目標: 記事を読んだ後、誰もこのトピックについて何かを検索する必要がなくなること。

標準的な深い研究に加えての追加要件：

• すべての主要なサブトピックは独自のセクションを持つ；脚注として残すことはない
• 原則だけでなく、実践的な例を含める
• よくある間違いとそれを避ける方法をカバー
• 「さらに読む」セクションを追加；最も深いもの 3～5 のソースをリスト；最良の出発点であるものにフラグを付ける
• Phase 6 の自己レビューは確認する必要がある：「読者はこの記事だけでこれを実装/理解できるか？」

Phase 1: 収集

一次ソースのみを集める：重要なアイデアを紹介した論文、公式ラボ/製品ブログ、ビルダーからの投稿、標準的な「ゼロから構築」リポジトリ。サマリーではなく。解説ではなく。

ソースごとに 3 つの順序付きステップ -- 近道なし、統合なし：

1. 発見 -- インストール済みの検索プラグイン（例：PipeLLM）を使用して全体像をマッピング、最有望な 2-3 のサブトピックを深く検索。プラグインなし：環境のネイティブウェブ検索を使用。出力は URL リスト；ここでコンテンツを取得しない。
2. 取得 -- すべての URL を /read を通す。/read はすでにプロキシカスケード、ペイウォール検出、プラットフォームルーティング（WeChat、Feishu、PDF、GitHub）を担当している。WebFetch と生の curl は JS 多用サイトやペイウォール付きサイトで黙って失敗し、そのすべてをスキップする。/read が欠落している場合（事前確認で警告）、ネイティブ取得にフォールバックしカバレッジ低下を受け入れる。
3. ファイル保存 -- /read は /learn から呼び出されるとき ~/Downloads/{title}.md に保存。取得返却後、各ファイルを研究プロジェクト下のサブトピックディレクトリに移動。再取得しないで移動。

目標: ブログ投稿なら 5-10 ソース、深い技術調査なら 15-20。

Phase 2: 消化

素材を検討。各ピース：全文を読む、良いものは残す、良くないものは削除。このフェーズの終了時に、収集したものの約半分を削除。

重要な主張については、概要に含める前に質問：

• このアイデアは同じソースから少なくとも 2 つの異なるコンテキストに現れるか？
• このフレームワークは新しい問題についてソースが何を言うか予測できるか？
• これはこのソースに固有か、それともフィールドのどの専門家も同じことを言うか？

一般的な知識は蒸留する価値がない。2 つまたは 3 つを通す：概要に属する。1 つを通す：背景材料。ゼロを通す：削除。

2 つのソースが事実上の主張で矛盾するとき、両方の立場と各々が与える証拠をメモ。黙って 1 つを選ばない。

Phase 3: 概要

記事の概要を書く。各セクションについて：それが引く出されるソース素材をメモ。セクションがソースを持たない場合、それは属さないか、最初にソースを見つける必要があるかのどちらか。

概要が堅実になるまで Phase 4 を開始しない。

Phase 4: 埋める

概要をセクションごとに作業。セクションが書きにくい場合、そこでのメンタルモデルはまだ弱い：そのサブトピックについて Phase 2 に戻る。概要は変わるかもしれず、それは構わない。

停滞信号（いずれかがこのセクションのメンタルモデルが不完全であることを意味する）：

• 開き方の文を 3 回以上書き直しても落ち着かない
• セクションが単一のソースに依存していて、主張をクロスチェックできない
• Phase 1 で収集されていない新しいソースが必要
• 段落が声に出して他の人に説明できない主張をしている

停滞したとき：記事全体ではなく、そのサブトピックについて Phase 2 に戻る。

Phase 5: 洗練

特定の指示でドラフトを通す：

• 意味や声を変えずに冗長で冗長な段落を削除
• 議論が流れない場所にフラグを付ける
• ギャップを特定：説明される前に使用される概念、ソースが必要な主張

ユーザーが書かなかったセクションを要約しない。ゼロから新しいセクションをドラフトしない。編集のみ。

その後、ドラフトから AI パターンを削除。/write がインストールされている場合、それを呼び出す。そうでない場合、手動で行う：フィラーフレーズ、二項対比、劇的な断片化、過度に使用された副詞をスキャン。意味を変えずにそれを削除。

Phase 6: 自己レビューと公開準備

ユーザーが公開する前に記事全体を線形に読む。AI ではなく。変に感じるすべてをマーク、修正、再読。最低 2 回のパス。

開始から終了まで読む時点で、ドラフトは公開準備ができている。

ユーザーが記事の公開準備ができたことを確認したら、停止。 明示的に頼まれない限り、アップロード、投稿、配布、または公開アクションを実行しない。

落とし穴

何が起こったか	ルール
一次ソースの代わりに 30 の二次解説を収集	Phase 1 は論文、公式ブログ、ビルダーによるリポジトリをターゲット。サマリーはソースではない。
/read がインストールされている間に WebFetch または curl を URL で使用	Phase 1 の取得はオプションではない。/read はプロキシカスケード、ペイウォール検出、プラットフォームルーティングを担当。それをバイパスすると有料サイト、JS 多用、中国プラットフォームサイトのカバレッジが黙って失われる。
説得力のある解説を基本真実として扱う	質問：これは同じソースから少なくとも 2 つの異なるコンテキストに現れるか？
Phase 2 が概念を教えるのではなく要約を書く	消化とはメンタルモデルの構築。要約することは消化ではない。
AI がユーザーが準備完了を言った後、ブログやソーシャルプラットフォームに記事をアップロードすることを申し出る	確認時に停止。公開はユーザーのアクション、あなたのアクションではない。