enrich

スキルの充実

外部ソースから人物や企業のページを充実させます。重要度に応じて作業量を調整します。

契約

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

• 充実させたすべてのページに、インライン引用付きの統合された事実（State セクション）がある
• 充実させたすべてのページに、日付付きの項目を含むタイムラインがある
• 双方向のバックリンクが作成される
• 重要度に基づく段階的な充実：Tier 1（完全）、Tier 2（中程度）、Tier 3（最小限）
• 雛形だけのページを作成しない：新しいページにはすべて、ウェブ検索または既存の brain コンテキストから得られた有意義な内容がある

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

規約： Iron Law のバックリンクに関する規則は、skills/conventions/quality.md を参照してください。

brain ページがある人物または企業に言及するたびに、そのエンティティのページから言及先のページへのバックリンクを作成する必要があります。リンクされていない言及は、brain の破損です。形式については、skills/_brain-filing-rules.md を参照してください。

基本方針

brain ページは、LinkedIn の情報をそのまま収集したものではなく、インテリジェンス資料のように読めるべきです。事実は最低限必要な要素です。価値を生むのは人物像の深みです。何を信じ、何を作り、何に突き動かされ、どこへ向かっているのかを記述します。

引用の要件（必須）

規約： 引用の形式とソースの優先順位については、skills/conventions/quality.md を参照してください。

ソース間に食い違いがある場合は、両方の引用を付けて矛盾を記載してください。

充実させるタイミング

主なきっかけ

• ユーザーが会話中にエンティティについて言及した
• エンティティが会議の文字起こしやメールに登場した
• 重要な背景情報を持つ新しい連絡先が現れた
• エンティティがニュースになった、または重大な出来事があった
• 取り込みパイプラインが注目すべきエンティティを検出した

充実させないケース

• 関係性を示す情報のない、偶発的な言及
• ボット／スパムアカウント
• ユーザーの仕事と実質的なつながりがないエンティティ
• 新たな兆候がない限り、過去1週間以内に同じページを充実させている場合

充実度の段階

重要度に応じて充実度を調整します。価値の低いエンティティに API 呼び出しを無駄遣いしないでください。

Tier	対象	作業量	ソース
1（主要）	中核となる人々、緊密な協力者、重要な連絡先	完全なプロセス	利用可能なすべての API ＋詳細なウェブ調査
2（注目）	時折やり取りする相手、業界の著名人	中程度	ウェブ調査＋ソーシャルメディア＋brain の相互参照
3（軽微）	追跡する価値はあるが、重要ではない対象	軽め	brain の相互参照＋ハンドルが分かる場合はソーシャルメディアで検索

充実化プロトコル（7 ステップ）

ステップ 1：エンティティを特定する

入力されたシグナルから人物、企業、概念を抽出します。

ステップ 2：brain の状態を確認する

各エンティティについて：

• gbrain search "name" -- すでにページが存在しますか？
• 存在する場合： UPDATE パス（新しいシグナルを追加し、重要な場合は統合された事実を更新）
• 存在しない場合： CREATE パス（まず注目度の基準を確認してから作成）

ステップ 3：ソースからシグナルを抽出する

事実を記録するだけではなく、その人物像を捉えてください。

シグナルの種類	抽出する内容
意見、信念	What They Believe セクション
現在のプロジェクト、リリースした機能	What They're Building セクション
志、キャリアの軌跡、動機	What Motivates Them セクション
何度も夢中になって取り上げる話題	Hobby Horses セクション
誰を支持し、議論し、尊敬しているか	Network / Relationships
上昇中、停滞中、方向転換中のどれか	Trajectory セクション
役職、企業、資金調達、所在地	State セクション（確定情報）

ステップ 4：外部データソースの照会

優先順位に従って進めます。エンティティのティアに必要な情報が十分に得られた時点で終了してください。

4a. Brain の相互参照（すべてのティアで必須）

• gbrain search "name" と gbrain query "what do we know about name" を実行します
• 関連ページを確認します。人物の情報を補完するには企業ページを、企業の情報を補完するには人物ページを確認します
• これは無料で、多くの場合、最も豊富な情報源です

4b. ウェブ調査（ティア 1 および 2）

• Perplexity、Brave Search、Exa、または同等のウェブ調査ツールを使用します
• 重要なパターン： 既存の Brain の情報をコンテキストとして渡し、検索結果が既知の情報を繰り返すのではなく、差分（既知の情報に対する新情報）を返すようにします
• ティア 1 の詳細調査には Opus クラスのモデルを、ティア 2 には軽量モデルを使用します

4c. ソーシャルメディアの照会（ハンドルが分かっている場合はすべてのティアで実施）

• 最近の投稿やツイートを取得して、語調、関心事、現在の注力分野を把握します
• ソーシャルメディアは、その人が実際に何を考えているかを知るうえで、最も情報量の豊富な情報源です

4d. 人物情報補完 API（ティア 1）

• LinkedIn のデータ、職歴、人脈、学歴

4e. 企業情報補完 API（ティア 1）

• 企業データ、財務情報、従業員数、主要な採用情報、最近のニュース

必要なデータ	情報源の例	ティア
ウェブ調査	Perplexity、Brave、Exa	1-2
LinkedIn／職歴	Crustdata、Proxycurl、People Data Labs	1
職歴	Happenstance、LinkedIn	1
資金調達／企業データ	Crunchbase、PitchBook、Clearbit	1
ソーシャルメディア	プラットフォーム API、ウェブスクレイピング	1-3
会議履歴	カレンダー／会議の文字起こしツール	1-2

ステップ 5：生データを保存する（出典情報を保持）

put_raw_data を使って、API の生の応答を gbrain に保存します：

{
  "source": "crustdata",
  "fetched_at": "2026-04-11T...",
  "query": "jane doe",
  "data": { ... }
}

生データを保存すると、出典情報が保持されます。編纂した情報の正確性に疑問が生じた場合、生データから API が返した内容を正確に確認できます。

ステップ 6：Brain に書き込む

作成パス

1. 注目度の判定基準を確認します（skills/_brain-filing-rules.md を参照）
2. エンティティのタイプ、ディレクトリ、サブタイプは、以下のテンプレートではなく、有効なスキーマパックから特定します。skills/brain-taxonomist/SKILL.md に従ってください（gbrain schema show --json または MCP get_active_schema_pack を使用します。単一のタイプには schema_explain_type を使用します）。パックで宣言されたエンティティタイプのうち、証拠に person や company より適したもの（投資会社、プロトコル財団など）があれば、そのタイプのディレクトリとサブタイプに記録します。該当する宣言済みタイプがなければ、その旨を伝えて確認を求めます。companies/ にフォールバックしてはいけません。
3. ステップ 2 で特定した type とディレクトリを使用し、以下のテンプレートからページを作成します。フロントマターには、そのタイプについてパックで宣言されているキー、または既存の同タイプのページですでに使用されているキーのみを、値が判明している場合に限り含めます。不明なフィールドは完全に省略し、null、空の値、プレースホルダーを記述してはいけません。
4. 引用を付けて、編纂した情報を記入します
5. タイムラインの最初の項目を追加します
6. 空のセクションは [No data yet] のままにします（定型文を記入しないでください）
7. 一括で作成する場合は、他のページからリンクされるページを先に作成します。まだ存在しないページへのリンクは未作成ページとして記録され、そのページの作成後にエッジになります（gbrain wanted で一覧を確認できます）。

更新パス

1. 新しいタイムライン項目を追加します（新しいものから古いものへ、追記のみ）
2. 新しい情報によって全体像が大きく変わる場合に限り、編纂した情報を更新します
3. 新しい事実を反映して「状態」セクションを更新します
4. 新しい情報と既存の編纂した情報の矛盾を明示します
5. API の定型文で、ユーザーが記述した評価を上書きしないでください

人物ページのテンプレート

---
title: Full Name
type: person
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags: []
company: Current Company
relationship: How the user knows them
# email, linkedin, twitter, location: add each only when you know it
---

# Full Name

> 1-paragraph executive summary: HOW do you know them, WHY do they matter,
> what's the current state of the relationship.

## State
Role, company, key context. Hard facts only.

## What They Believe
Ideology, first principles, worldview. What hills do they die on?

## What They're Building
Current projects, recent launches, what they're focused on.

## What Motivates Them
Ambition, career arc, what drives them.

## Communication Style
How they like to communicate, how they handle disagreement, what energizes
them in a conversation. Write only what you observed directly (meetings,
their emails or posts) or what they said about themselves; label each line
observed, self-described or inferred. One data point is a timeline entry,
not a pattern. Confidence follows interaction count: low after one, high
after five or more.

## Hobby Horses
Topics they return to obsessively. Recurring themes in their work/posts.

## Assessment
Your read on this person. Strengths, gaps, trajectory.

## Trajectory
Ascending, plateauing, pivoting, declining? Where are they headed?

## Relationship
History of interactions, shared context, relationship quality.

## Contact
Email, social handles, preferred communication channel.

## Network
Key connections, mutual contacts, organizational relationships.

## Open Threads
Active conversations, pending items, things to follow up on.

---

## Timeline
Reverse chronological. Every entry has a date and [Source: ...] citation.
- **YYYY-MM-DD** | Event description [Source: ...]

企業ページのテンプレート

---
title: Company Name
type: company
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags: []
---

# Company Name

> 1-paragraph executive summary.

## State
What they do, stage, key people, key metrics, your connection.

## Open Threads
Active items, pending decisions, things to track.

---

## Timeline
- **YYYY-MM-DD** | Event description [Source: ...]

ステップ 7：相互参照

• 人物情報の補完内容を会社ページに反映します（またはその逆を行います）。
• 関連するプロジェクト／取引ページにも、該当するコンテキストが見つかった場合は反映します。
• brain がインデックスファイルを使用している場合は、それらを確認します。

注（v0.10.1）： brain のページ間のリンクは、put_page を呼び出すたびに自動作成されます（自動リンクのポストフック）。ステップ 7 ではリンクの作成ではなく、コンテンツの相互参照（この情報補完で得た新たな情報をもとに、関連ページのまとめられた情報を更新すること）に重点を置きます。信頼できるローカル書き込みでは、put_page の応答に auto_links: { created, removed, errors } が含まれます。MCP 書き込み（stdio および HTTP）ではインライン自動リンクがスキップされます（auto_links.skipped: "remote"）。ただし、既存ページへの通常の mentions エッジはキューに追加されます（auto_links.mention_links: "queued"）。型付きエッジとフロントマターエッジ（works_at、invested_in、source など）は、メンテナンス処理まで作成されません。stdio の場合は serve スイープ、HTTP brain の場合はホスト上で gbrain sweep --once を実行します。すぐに必要な型付きエッジには add_link を使用します。 タイムラインのエントリには、引き続き明示的な gbrain timeline-add の呼び出しが必要です。

一括情報補完のルール

• まず 3〜5 件のエンティティでテストします。 実際の出力を読み、品質を確認します。
• テスト結果が品質基準を満たした場合にのみ、一括処理に進みます。
• 同じ情報源から 3 件以上のエンティティを扱う場合は、バッチ処理するか、サブエージェントを起動します。
• API 呼び出しを制限し、レート制限を遵守します。
• 一括処理では、5〜10 件ごとにコミットします。
• 情報補完の一括処理後にレポートを保存します（下記の「レポートの保存」を参照）。

検証ルール

• LinkedIn のコネクション数が 20 未満の場合は、別人の可能性が高いためスキップします。
• brain と API で名前が一致しない場合はスキップし、確認対象としてフラグを付けます。
• 冗談のプロフィールや明らかに誤ったデータは、生データとして保存し、ページは更新しません。
• API の定型文で、ユーザーが書いた評価を上書きしないでください。
• 判断に迷う場合は、生データを保存しますが、brain のページは更新しません。

レポートの保存

情報補完のスイープ後に、次の内容をレポートとして保存します。

• 処理したエンティティ数
• 新規作成ページ数と既存ページの更新数
• 呼び出したデータソースと結果の品質
• 注目すべき発見や矛盾
• 検証時のフラグや API エラー

これにより、brain の情報補完の監査記録を長期にわたって作成できます。

失敗した場合

gbrain の code エラー、終了コード、[AGENT] ブロック、または通知ブロックが発生した場合は、エージェント運用者プロトコルに従います。このスキルに固有の対応は次のとおりです。

• 外部の情報補完 API が rate_limited または認証エラーを返した場合は、指定された時間だけ待機します。認証エラーの場合は停止し、どのキーが不足しているかをユーザーに伝えます。推測した事実で不足分を補ってはいけません。
• put_page が revision_conflict を返した場合は、エンティティページを再読み込みし、変更を統合して、新しいリビジョンで保存します。
• 書き込み時に auto_links.errors が空でない場合、ページは保存されていますが、一部のリンクは作成されていません。レポートにそれらを記載し、スラッグを修正した後に add_link で追加します。

アンチパターン

• 内容のないスタブページを作成する
• brain を先に確認せずに情報を補完する
• ユーザーの直接の発言を API データで上書きする
• 重要でないエンティティのページを作成する

出力形式

情報補完済みの人物ページには、次の内容を含めます。

• フロントマター：type、tags、company、relationship、連絡先フィールド
• エグゼクティブサマリー（1 段落：その人物を知った経緯、重要な理由、関係の状態）
• State セクション：確かな事実とインラインの [Source: ...] 引用
• 人物像の各セクション（What They Believe、What They're Building、What Motivates Them、Hobby Horses）
• Assessment：今後の見通しに関する所見
• Relationship：これまでの経緯と連絡先情報
• Network：つながりと共通の知人
• Timeline：新しい順に並べ、各エントリに日付と出典の引用を記載

情報補完済みの会社ページには、次の内容を含めます。

• フロントマター：type と tags
• エグゼクティブサマリー（1 段落）
• State セクション（事業内容、段階、主要人物、指標、あなたとのつながり）
• Open Threads（進行中の項目、未決定事項）
• Timeline：日付と出典を記載したエントリを新しい順に並べたもの

どちらのページタイプでも、言及しているすべてのエンティティへの双方向バックリンクを設定します。

使用するツール

• gbrain からページを読み取る（get_page）
• gbrain にページを保存／更新する（put_page）
• gbrain にタイムラインエントリを追加する（add_timeline_entry）
• gbrain のページをタイプ別に一覧表示する（list_pages）
• 生の API データを gbrain に保存する（put_raw_data）
• gbrain から生のデータを取得する（get_raw_data）
• gbrain のエンティティをリンクする（add_link）
• gbrain のバックリンクを確認する（get_backlinks）