second-brain

/second-brain — Karpathy LLM Wiki ワークフロー

Obsidian（または Markdown ベースの任意の保管庫）にある既存の Second Brain をラップします。Wiki 保管庫のスキーマ文書（CLAUDE.md または AGENTS.md）が正式なスキーマです。このスキルは、ユーザーが手作業で行っていた操作を調整します。

メンタルモデル

それぞれ明確な役割を持つ、3 つのレイヤーです。

raw/      →  wiki/         →  outputs/
sources      compiled         generated
                              artifacts

• raw/ — 未処理のソース資料です。記事、ハイライト、アイデア、思考の書き出し、ツイートなどが含まれます。種類を表す接頭辞（article-、idea-、highlights-、braindump-、note-、resource-、tweet-）を付けます。削除はしません。ここが信頼できる唯一の情報源です。
• wiki/ — AI が編集・整理したトピックページです。ソースごとではなく、概念ごとに 1 ページ作成します。[[wikilinks]] で相互にリンクします。ルートに INDEX.md を置きます。
• outputs/ — クエリから生成された成果物です。調査の要約、分析、スライドデッキなどが含まれます。内容がわかる名前を付けます。

Wiki の操作中に変更しないフォルダー：Projects/、Daily/、Templates/、Inbox/、Notes/、Tasks.md、Kanban.md、Home.md。

ステップ 1 — 保管庫の設定とスキーマを読み込む

1. 保管庫のパスについて references/vault-config.md を読みます（デフォルト：${SECOND_BRAIN_VAULT:-$HOME/Documents/SecondBrain}/）。
2. 正式なスキーマを確認するため、保管庫のスキーマ文書（<vault>/CLAUDE.md または <vault>/AGENTS.md。存在する方。両方ある場合は両方）を読みます。存在する場合は、references/schema.md よりも優先します。ユーザーの保管庫が信頼できる唯一の情報源です。
3. どちらも存在しない場合は、references/schema.md を使用します。

ステップ 2 — モードを判定する

呼び出し	モード
/sb capture / /second-brain capture / 「これを取り込んで」 / 「これを自分の脳に保存して」	capture
/sb compile / 「Wiki を編集・整理して」 / 「未処理のメモを処理して」	compile
/sb query <question> / 「自分の脳に X について聞いて」 / 「自分の脳は Y について何と言っている？」	query
/sb lint / 「Wiki を検査して」 / 「自分の脳のヘルスチェックをして」	lint
/sb connect / 「つながりを見つけて」 / 「Wiki リンクを提案して」	connect
/sb search <term> / 「メモから X を検索して」	search

ステップ 3 — モードを実行する

capture

入力：URL、貼り付けたテキスト、ファイルパス、またはスクリーンショット。

1. コンテンツから種類を判定します。
   • URL → article-
   • 引用したハイライトを含む貼り付けテキスト → highlights-
   • ユーザー自身の考えやブレインストーミング → braindump- または idea-
   • 単一のツイート／X の投稿 → tweet-
   • PDF、動画、ポッドキャスト → resource-
   • 簡易リファレンス（レシピ、コマンド、事実） → note-
   • 判別できない場合は、ユーザーに確認します。
2. 内容がわかるファイル名を生成します：<type>-<kebab-case-topic>.md（例：article-andrew-wilkinson-tiny-manual.md）。URL のスラッグではなく、ソースのタイトルまたはトピックを使います。
3. 先頭にメタデータを追加します。

   source: <URL if applicable>
   captured: YYYY-MM-DD
   

4. <vault>/raw/ に保存します。
5. ソースが URL の場合は、記事の内容を取得し（エージェントの URL 取得機能、または認証が必要なページには agent-browser を使用）、URL だけでなく読みやすいテキストを保存します。
6. 保存先のパスと、保存内容を一文で要約したものを報告します。

ここでは Wiki に編集・整理しないでください。capture は素早く取り込むためのものであり、編集・整理は別途、意図的に行う作業です。

compile

コストはかかりますが、価値のある処理です。未処理の生ファイルを wiki ページに変換します。

1. 未処理の生ファイルを見つける：wiki/*.md 内の Sources セクションを grep します。記載されていない生ファイルが未処理です。
2. 未処理の生ファイルをそれぞれ読み込む＋既存の wiki/INDEX.md を読み込みます。
3. 各生ファイルについて：
   • 重要な概念、事実、知見を抽出します
   • **基本方針：**トピックが重複する場合は、既存の wiki ページに統合します。どのページにも当てはまらない場合に限り、新しいページを作成します。
   • ソースごとではなく、概念ごとに 1 ページを作成します。
   • 関連するすべての概念に [[wikilinks]] を使用します
   • wiki ページの ## Sources セクションに生ファイルを追加し、そこから何を引用したかを 1 行で記します
4. wiki/INDEX.md を更新します：
   • 新しいページを該当するカテゴリ（Creative / Health & Longevity / Faith & Personal Growth / Business / Personal Growth / Tech / Hobbies / Sci-Fi / Pets、または必要に応じて新しいカテゴリ）の下に追加します
   • エントリーは 1 行につき 1 件：- [[Page Name]] — brief description
5. **すべての wiki ページに Connections セクションが必須です。**新しいページに接続先がない場合は、保存する前に接続先を見つけてください。
6. **量より質を優先します。**ページが 100 語未満になる場合は、ひとまず生ファイルを保留し、隣接するページに統合するかユーザーに確認してください。

出力：作成・更新したページの一覧、統合した内容と統合先、確認が必要なため保留した項目。

query

wiki／生ファイルのコーパスのみを使用して質問に回答します。外部情報を使う deep-research とは異なります。

1. wiki/INDEX.md を読み、関連する可能性のあるページを特定します
2. 該当するページを読み、[[wikilinks]] を 1～2 段階たどります
3. 回答を作成します：
   • wiki ページ名を引用します：「[[Microplastics Detox]] によると……」
   • wiki 内に矛盾がある場合は、両方の見解を示します
   • wiki に回答が含まれていない場合は、その旨を伝え、範囲を広げるために /deep-research を実行することを提案します
4. 次の内容を含めて outputs/<YYYY-MM-DD>-<question-slug>.md に保存します：
   • 元の質問
   • 回答
   • 参照した wiki ページの一覧
5. チャットに回答を表示し、保存先のパスを示します
6. 任意のレンダリング：--render pdf または --render html が指定された場合は、共有スタイルシートを使用して出力を pandoc に渡します。コマンドについては references/schema.md →「Publishing alternatives」を参照してください。

lint

wiki のヘルスチェックを行います。

次を確認します：

1. 孤立ページ — INDEX.md に記載されていない wiki/*.md
2. 接続の孤立 — 他のページへの [[wikilinks]] がないページ
3. 未処理の生ファイル — どの wiki ページの Sources にも記載されていない生ファイル
4. 古いページ — 最も新しいソースが 6 か月以上前で、トピックが変化しやすいもの（AI、マーケティング、金融、健康プロトコル）
5. トピックの不足 — 3 ページ以上で言及されているのに、専用ページがない概念
6. 矛盾 — 相反する主張をしているのに、その旨が示されていない wiki ページ
7. 接続の不足 — 明らかに関連するトピックのページ間に [[wikilink]] がないもの（/sb connect を提案します）

出力：優先度順の一覧。重要度の高いものを先にします（構造の破損はコンテンツの古さより優先）。

connect

リンクされていない、リンクすべきページを見つけます。

1. INDEX.md とページの要約からトピックマップを作成します
2. 各ページについて、テーマが重複する他のページを 2～5 件見つけます
3. 候補の各ページがすでにリンクされているか確認します
4. 不足しているリンクを提案します。ユーザーが承認した場合は、各ページの ## Connections セクションに追加します

search

wiki/ と raw/ 全体を対象に、指定語をすばやく grep します。一致したファイルと、該当箇所の前後 2 行を返します。探しているページが分かっている場合は、query より高速です。

複数ライターによる git 同期（リモートエージェント）

Vault がホスト型リモート（GitHub/GitLab）に接続された Git リポジトリの場合、リモートはファイルシステムにアクセスできないエージェント向けのキャプチャ APIになります。クラウドエージェント、スケジュール実行ジョブ、ほかのマシンなどが対象です。Git ホストの API に直接、または Executor のような MCP 統合レイヤーを介してアクセスできるエージェントなら、Wiki を読み取り、デフォルトブランチにコミットすることで raw/ に情報を取り込めます。

ライター間の分岐を防ぐためのルールは次のとおりです。

1. ローカルセッションでは書き込み前に pull する：Vault で作業を始めるときに git pull --rebase --autostash を実行し、コミット後に push します。ローカルが最新だと思い込まないでください。前回のセッション以降にリモートエージェントがコミットしている可能性があります。
2. Obsidian ユーザーの場合：コミュニティ製の Git プラグインをインストールし、一定間隔（約 10 分）での自動 pull と起動時の pull を有効にします。ただし、自動コミットと自動 push はオフにしてください。コミットはセッションとエージェントが担当することで、「vault backup」の雑多な記録ではなく、意味のある履歴を保てます。
3. リモートエージェントは追記を中心にコミットする：raw/ に新しいファイルを追加し、内容がわかるコミットメッセージを付けます。異なるファイルへの追記を中心とした書き込みなら競合はまれで、リベースによって書き込みが交互に行われても問題なく取り込めます。

セットアップ時に、リモートから API 経由でコミット → ローカルで pull → Vault にファイルが表示される、という一連の流れを最初に最後まで確認してください。

組み合わせて使うもの

• deep-research — query で Wiki の不足が見つかった場合、外部ソースから情報を補うために deep-research に回します。deep-research の出力は、今後の編集に備えて raw/ に取り込めます。
• paste — コンテンツを raw/ にきれいに取り込みます（特にターミナルや CLI から取り込む場合）。
• business-brainstorm — ブレインストーミングの前に、関連する背景情報がないか Portfolio of Businesses と Entrepreneurship & Startups の Wiki ページを確認します。
• decide — 原則に基づいて Q34（「どの原則を曲げているか」）を評価する際、Personal Philosophy / Productivity & Systems の Wiki から情報を取得します。新機能として、Decision Log の Wiki ページには、時間の経過とともに意思決定の物語形式の記録が蓄積されます（decide のアーカイブは構造化された形式で、Wiki ページはストーリー形式です）。
• jab-hook — Content Ideas の Wiki ページには、フック、フレームワーク、ストーリーが集められています。/jab-hook はそこから候補を取得して下書きを作成します。
• slide-deck — outputs/ で作成したコンテンツはデッキのソースになります。スピーカーノートから関連する Wiki ページを参照できます。
• pm — Vault 内の Projects/ フォルダーは second-brain の対象外で、pm が管理します。ただし、複数のプロジェクトに共通する運用パターンは、Workflow Docs の Wiki ページに記録します。

類似実装（参考）

raw → wiki → outputs と同じパターンに従う、ほかの 2 つのシステムです。どちらも、アップグレード先の候補として注目する価値があります。

• Hermes の llm-wiki スキル — 3 フォルダー構成のパターンをすぐに使える形で実装しています。compile / query / lint 用のワークフローがあらかじめ用意されています。スキーマ設計の比較に役立ちます。
• Garry Tan による Gbrain — はるかに高度なシステムです。脳をデータベース（Postgres または PGLite）として扱い、統合、グラフ探索、ギャップ分析、cron による定期メンテナンス、MCP 統合を備えています。14 万 6,000 ページ、2 万 4,000 人のエンティティを持つデプロイ環境を支えています。ユーザーの Vault が Markdown のみのパターンでは手狭になった場合、Gbrain がアップグレード先になります。移行しなくても今すぐ取り入れられる点は、人をエンティティとして扱うこと（person- raw タイプと People Wiki ページ）と、定期メンテナンス（loop または compound-engineering:schedule スキルを使い、定期実行されるように compile と lint を設定すること）です。

品質に関する注意事項

• 量より質を重視してください。 薄いページを大量に作るより、相互につながったページを少数作るほうが有効です。コンパイルすると薄いページになる場合は、内容を明確にするために元ファイルを保管してください。
• 細かなニュアンスを平坦化しないでください。 2つの元ソースに矛盾がある場合は、どちらか一方を黙って選ぶのではなく、Wiki ページに意見の相違を記載してください。
• 「関連ページ」セクションは必須です — すべての Wiki ページで、少なくとも1つの別ページにリンクしてください。
• コンパイル後も、元ファイルを削除しないでください。元ファイルが信頼できる情報源です。
• セカンドブレインの操作中に、Projects/、Daily/、Templates/、Notes/、Tasks.md、Kanban.md、Home.md、Inbox/ 内のファイルを変更しないでください。これらは別のワークフローに属します。