idea-ingest

アイデア取り込みスキル

ファイリング規則： 新しいページを作成する前に、skills/_brain-filing-rules.md を読んでください。

契約

このスキルでは、以下を保証します。

• 取り込んだすべての項目に、単なる要約ではなく、実質的な分析を含むブレインページが作成されます
• 作成者は必ずクレジットされます。既存の people/ ページから相互リンクする（タイムラインを更新する）か、ページが存在しない場合は取り込み先ページにインラインで記載します（**Author:** {Author}, {role}）。新しい people/ ページを作成するのは、作成者が重要性の基準を満たし、この項目以外に独立した永続的な事実が少なくとも2つある場合に限ります。スタブは作成しません（skills/_brain-filing-rules.md §Notability Gate）
• 相互リンクを双方向に作成します（ソース ↔ 作成者、ソース ↔ 言及されたエンティティ）
• 出所を記録するため、元のソースを gbrain files upload-raw で保存します
• すべての事実にインラインの [Source: ...] 引用を付けます
• ファイリングでは形式ではなく、主要な主題の規則に従います

戻り値（別のスキルまたはサブエージェントから呼び出された場合）：

• page_path：取り込んだ項目のブレインページのパス（例：concepts/flywheel-effects）
• author_path：作成者のブレインページのパス（例：people/alice-example）。重要性の基準を適用せず、代わりに作成者をインラインでクレジットした場合は null
• cross_links：作成したすべての相互リンクのリスト
• status：ingested | updated | fetch_failed

規約： Iron Law の相互リンクについては、skills/conventions/quality.md を参照してください。

ブレインページがある人物または企業に言及するたびに、必ず相互リンクを作成してください。 形式：- **YYYY-MM-DD** | [page title](path) で言及 — 簡潔な文脈

フェーズ

1. コンテンツを取得します。 コンテンツの種類に適したツールを使用します（記事にはウェブ取得、ツイートには API、ドキュメントには PDF リーダー）。

2. 元のソースをアップロードします。 出所を記録するため、取得したコンテンツを保存します：gbrain files upload-raw <file> --page <slug>

3. 作成者を特定します（重要性の基準を適用）。 まず、ブレイン内で既存の作成者ページを検索します。

   • ページが存在する場合 → この新しい出版物をタイムラインに追加してから、双方向に相互リンクします
   • ページが存在しない場合 → 作成者が重要性の基準（skills/_brain-filing-rules.md §Notability Gate、skills/conventions/quality.md）を満たし、さらにこの項目以外に独立した永続的な事実が少なくとも2つある場合に限り、ページを作成します。情報を補完して完全なページを作成し、スタブにはしません。単一の取り込み項目だけでは、ページを作成する価値のあるエンティティとはいえません。
   • それ以外の場合は、取り込み先ページに作成者をインラインでクレジットし（**Author:** {Author}, {role}）、返信で情報が不足していることを伝えます。判断に迷う場合は、作成しないでください。ページがなくても、後から作成できます。

4. ブレインに保存します。 主要な主題に基づいてファイリングします（skills/_brain-filing-rules.md を参照）。

   • 人物について → people/
   • 企業について → companies/
   • 再利用可能なフレームワーク → concepts/
   • 生データのダンプ → sources/

5. ユーザーのために分析します。 コンテンツとブレインの既知情報を結び付けて分析を返信します。以下を考慮してください。

   • 進行中のプロジェクト — 関連性はありますか？
   • 矛盾 — ブレイン内の既存の知識に異議を唱えますか？
   • つながり — 既知の人物や企業が関係していますか？
   • 単に要約するだけではなく、ユーザーが気づいていなかった点を伝えてください。

6. 同期します。 gbrain sync を実行して、インデックスを更新します。

出力形式

# {Title} — {Author}

**Source:** {URL}
**Author:** {Author}, {role}
**Published:** {date}
**Ingested:** {date}

## Context
{Why this matters now, connected to brain knowledge}

## Summary
{3-5 bullet core arguments}

## Key Data / Claims
{Specific facts, numbers, quotes}

## Analysis
{How this connects to existing brain knowledge. What's new. What contradicts.}

エッジケース

• 取得に失敗した場合（ペイウォール、404、タイムアウト）： URL、メタデータ、失敗理由を含むスタブページを保存します。コンテンツを取得できなかったことをユーザーに伝え、貼り付けてもらえるか尋ねます。
• URLが重複している場合： 取り込み前に brain で URL を検索します。見つかった場合は、新しいページを作成せず既存のページを更新します。すでに取り込まれていたことをユーザーに伝えます。
• 著者を特定できない場合： sources/ に分類します。人物ページは作成せず、情報が不足していることを記録します。
• ツイートのスレッドと単独のツイート： スレッド全体を取得します。スレッドをひとまとまりとして扱います。
• 動画／ポッドキャストのリンク： トランスクリプトがない場合、取り込めるのはメタデータのみであることを伝えます。ユーザーにトランスクリプトを求めます。
• 生のファイルのアップロード： エージェントとして操作する場合は、CLI の gbrain files upload-raw ではなく、file_upload ツールを使用します。

失敗した場合

gbrain のエラー code、終了コード、[AGENT] ブロック、または通知ブロックについては、エージェントオペレータープロトコルに従ってください。このスキルに固有の対応は次のとおりです。

• 取得に失敗した場合（ペイウォール、404、タイムアウト）：URL、メタデータ、失敗理由（status: fetch_failed）を含むスタブを保存し、ユーザーにコンテンツを貼り付けるよう依頼します。
• gbrain files upload-raw／file_upload が拒否された場合（許可されたルート外のパス、ペイロードが大きすぎる）：制限をユーザーに伝え、代わりにリンクまたは抜粋を提示するよう提案します。
• ページの書き込みで write_pending（終了コード 10）が発生した場合：ingested と報告する前に、gbrain write-request <request_id> を使って状態を確認します。

避けるべきパターン

• brain の知識と関連付けずに、単に要約する
• すべてを sources/ に分類する（sources は生データのダンプ専用です）
• 著者のクレジットを完全に省略する。既存の著者ページへのバックリンクも、取り込み先ページ内の **Author:** 行も付けない
• skills/_brain-filing-rules.md の注目度基準を満たさない、またはこの項目ひとつだけを基にしたスタブの people/ ページを作成する
• 言及されているエンティティへの相互リンクを追加しない
• 既存の情報があるかどうかを最初に brain で確認せずに取り込む
• 新しい内容を統合する代わりに、既存の brain ページを上書きする
• brain の知識との関連を捏造する。検索／クエリで確認した関連のみを挙げる
• concepts/strategy のような汎用スラッグを作成する。concepts/flywheel-effects のように具体的にする
• コンテンツを実際に取得できたか確認せず、取得に成功したと思い込む