copilot-history-ingest

Copilot 履歴の取り込み — 会話の分析

ユーザーの過去の GitHub Copilot CLI の会話から知識を抽出し、Obsidian のウィキにまとめます。会話には豊富な情報がありますが、雑然としています。重要な情報を見つけて整理するのがあなたの役目です。

このスキルは直接呼び出すことも、wiki-history-ingest ルーター経由で呼び出すこともできます（/wiki-history-ingest copilot）。

開始する前に

執筆プロファイル： 自然言語の Markdown を新規作成または書き換える前に、llm-wiki/SKILL.md の「Writing Profile Resolution」セクションを読み、その内容を適用してください。フレームワークのスキーマ、出典情報、安全性、および操作固有の要件を優先してください。 WRITING.md の設定は、新規作成または書き換える自然言語の Markdown にのみ適用します。ソースの内容と構造化レコードはそのまま保持してください。

1. 設定を解決する — llm-wiki/SKILL.md の Config Resolution Protocol に従います（インラインの @name による上書き → CWD から上位階層をたどって .env を検索 → グローバル設定 → プロンプトによるセットアップ）。これにより、OBSIDIAN_VAULT_PATH、COPILOT_HISTORY_PATH（既定値は ~/.copilot/session-state）、および COPILOT_VSCODE_STORAGE_PATH（VS Code の workspaceStorage。プラットフォームによって異なります。不明な場合はユーザーに尋ねます）が得られます
2. Vault のルートにある .manifest.json を読み、すでに取り込まれたデータを確認します
3. Vault のルートにある index.md を読み、ウィキに含まれる内容を確認します

取り込みモード

追記モード（既定）

ソースファイルごとに .manifest.json を確認します（events JSONL、transcript JSONL、checkpoint、session-store DB）。次のものだけを処理します。

• マニフェストにないセッション（新規セッション）
• マニフェストの ingested_at より updated_at が新しいセッション

通常はこのモードを使用します。ユーザーが新しいセッションをいくつか実行し、その差分を取り込みたい場合に適しています。

全件モード

マニフェストに関係なく、すべてを処理します。wiki-rebuild の実行後、またはユーザーから明示的に依頼された場合に使用します。

GitHub Copilot のデータ構成

Copilot はデータを 3 か所に保存します。3 か所すべてをスキャンしてください。

ソース 1：~/.copilot/session-state/（CLI セッション）

~/.copilot/session-state/
├── <session-uuid>/
│   ├── workspace.yaml           # Session metadata (id, cwd, summary_count, created_at, updated_at)
│   ├── vscode.metadata.json     # VS Code context (workspaceFolder, repositoryProperties, customTitle)
│   ├── events.jsonl             # Full event log — all turns, tool calls, reasoning
│   ├── session.db               # Per-session SQLite (todos/todo_deps only — skip for ingestion)
│   ├── index.md                 # Session summary written at session end
│   ├── checkpoints/             # Checkpoint JSON files (mid-session summaries)
│   │   └── <uuid>.json          # title, overview, history, work_done, technical_details,
│   │                            #   important_files, next_steps
│   ├── files/                   # Artifacts produced during session (plans, diagrams, etc.)
│   └── research/                # Research artifacts
└── ...

ソース 2：~/.copilot/session-store.db（グローバル SQLite）

セッションをまたいで使われる正規のデータベースです。構造化され、クエリ可能で、事前に要約されているため、最も価値の高いソースです。

sessions       — id, cwd, repository, branch, summary, created_at, updated_at, host_type
turns          — session_id, turn_index, user_message, assistant_response, timestamp
checkpoints    — session_id, checkpoint_number, title, overview, history, work_done,
                 technical_details, important_files, next_steps, created_at
session_files  — session_id, file_path, tool_name, turn_index, first_seen_at
session_refs   — session_id, ref_type (commit/pr/issue), ref_value, turn_index, created_at
search_index   — FTS5 virtual table (content, session_id, source_type, source_id)

ソース 3：VS Code Workspace Storage（<workspaceStorage>/<hash>/GitHub.copilot-chat/）

VS Code 拡張機能のデータで、ワークスペースのハッシュをキーとしています。パスはプラットフォームによって異なるため、.env またはユーザーの入力から取得する必要があります。

<hash>/GitHub.copilot-chat/
├── transcripts/
│   └── <session-uuid>.jsonl     # Conversation transcripts (same JSONL format as events.jsonl)
├── memory-tool/
│   └── memories/
│       └── <base64-session-id>/ # Per-session saved artifacts (plan.md, etc.)
│           └── plan.md
└── codebase-external.sqlite     # Codebase index (skip — no conversation knowledge)

主なデータソースの価値順：

1. チェックポイント（session-store.db の checkpoints テーブルと、セッションごとの checkpoints/*.json） — overview、work_done、technical_details、important_files、next_steps を含む、事前に整理された要約です。非常に価値があります。
2. セッションの要約（session-store.db の sessions.summary と index.md） — セッションごとの 1 段落の概要です。
3. ターン（session-store.db の turns テーブルと events.jsonl / transcript JSONL） — 会話全体です。情報は豊富ですが、冗長です。
4. メモリアーティファクト（memory-tool/memories/<id>/plan.md など） — ユーザーが明示的に保存した、あらかじめ作成された計画や構造化されたメモです。そのまま（または軽く要約して）取り込む価値があります。
5. ファイルアクセスパターン（session_files テーブルと tool.execution_* イベント） — エージェントが繰り返し操作したファイルを示し、価値の高いプロジェクトファイルを見つける手掛かりになります。
6. セッション参照（session_refs テーブル） — セッションに関連付けられたコミット、PR、課題です。
7. vscode.metadata.json — ワークスペースのフォルダーパス、ブランチ、customTitle（ユーザーが設定したセッション名）が含まれます。グループ分けや命名に役立ちます。

ステップ 1：調査して差分を算出する

3 か所すべてのデータをスキャンし、.manifest.json と照合します。

# --- Source 1: per-session directories ---
# Find all session directories (each has workspace.yaml)
ls ~/.copilot/session-state/

# For each session, read workspace.yaml for id/cwd/updated_at
# and vscode.metadata.json for customTitle / repositoryProperties

# --- Source 2: global database ---
# Query session-store.db with sqlite3 (or Python sqlite3)
SELECT s.id, s.cwd, s.repository, s.branch, s.summary, s.updated_at,
       COUNT(DISTINCT t.turn_index) AS turn_count,
       COUNT(DISTINCT c.id)         AS checkpoint_count
FROM sessions s
LEFT JOIN turns t ON t.session_id = s.id
LEFT JOIN checkpoints c ON c.session_id = s.id
GROUP BY s.id
ORDER BY s.updated_at DESC;

# --- Source 3: VS Code workspace storage ---
# For each <hash> directory under workspaceStorage, check for GitHub.copilot-chat/
# Find transcript files
ls <workspaceStorage>/<hash>/GitHub.copilot-chat/transcripts/

セッション UUID ごとに 1 件のエントリーをまとめた統合インベントリを作成し、次のように分類します。

• 新規 — マニフェストにないため、取り込みが必要
• 変更あり — マニフェストにはあるが、updated_at がより新しいため、再取り込みが必要
• 変更なし — マニフェストにあり、変更されていないため、追記モードではスキップ

ユーザーに次のように報告します。「session-state で X 件、session-store.db で Y 件、VS Code の transcript ファイルで Z 件のセッションが見つかりました。チェックポイント：A 件。差分：新規 B 件、変更あり C 件。」

ステップ 2：まずチェックポイントと要約を取り込む

チェックポイントはすでに要点がまとめられているため、生のターンに触れる前に処理してください。

session-store.db から：

SELECT s.id, s.cwd, s.repository, s.branch, s.summary,
       c.checkpoint_number, c.title, c.overview, c.work_done,
       c.technical_details, c.important_files, c.next_steps,
       c.created_at
FROM checkpoints c
JOIN sessions s ON c.session_id = s.id
ORDER BY s.updated_at DESC, c.checkpoint_number ASC;

セッションごとの checkpoints/*.json から：

各チェックポイントファイルには、title、overview、history、work_done、technical_details、important_files、next_steps が含まれています。

index.md（存在する場合）はセッション単位の要約として読み込みます。通常はセッション終了時に作成されており、すでに簡潔にまとめられています。

抽出する内容：

• overview → セッションで達成したことの概要
• work_done → 完了した具体的なタスク（スキル／プロジェクトのページに適しています）
• technical_details → 実装の詳細（コンセプトのページに適しています）
• important_files → プロジェクト内の重要度の高いファイル（プロジェクトのページに適しています）
• next_steps → 未完了の作業（進行中のプロジェクト作業へのリンクに適しています）

ステップ 3：セッションのターンを解析する

session-store.db（推奨。すでに解析済み）または events.jsonl／トランスクリプト JSONL からターンを読み込みます。

session-store.db から：

SELECT turn_index, user_message, assistant_response, timestamp
FROM turns
WHERE session_id = '<uuid>'
ORDER BY turn_index ASC;

events.jsonl／トランスクリプト JSONL から：

各ファイルは 1 つのセッションを表します。各行は JSON イベントです。スキーマ全体については references/copilot-data-format.md を参照してください。

関連するイベントタイプ：

type	内容	読む価値はありますか？
session.start	セッションのメタデータ（cwd、ブランチ、バージョン）	はい — プロジェクトのコンテキストを把握できます
user.message	ユーザーのターン	はい — data.content
assistant.message	アシスタントのターン	はい — data.content（テキスト）＋ data.toolRequests
tool.execution_start	ツールの呼び出し	ざっと確認 — 使用されたファイル／コマンドがわかります
tool.execution_end	ツールの結果	いいえ — 通常はノイズです

assistant.message の抽出戦略：

• data.content はアシスタントのテキスト応答です — これを抽出します
• data.reasoningText は内部推論です — スキップします（展開された reasoningOpaque フィールドです）
• data.toolRequests にはツール呼び出しが記載されています — ファイルアクセスのパターンを把握するため、ツール名と引数をざっと確認します
• type: "tool.execution_end" はすべてスキップします

ステップ 3b：メモリーアーティファクトを処理する

VS Code のワークスペースストレージに memory-tool/memories/<base64-id>/ ディレクトリがある各セッションについて、そこに保存された Markdown ファイル（通常は plan.md）を読み込みます。これらはユーザーが明示的に保存したドキュメントです — 品質の高いユーザー作成コンテンツとして扱ってください。

base64 のディレクトリ名をデコードして、セッション UUID を取得します：

import base64
session_id = base64.b64decode(dir_name).decode('utf-8')

メモリーアーティファクトは、コンテンツの種類に応じて、プロジェクトの skills/ または concepts/ ページに対応付けます。

ステップ 3c：ファイルと参照のパターンを抽出する

session-store.db から：

-- Most-touched files per project
SELECT repository, file_path, COUNT(*) AS touch_count
FROM session_files
GROUP BY repository, file_path
ORDER BY touch_count DESC;

-- Linked commits/PRs/issues per session
SELECT session_id, ref_type, ref_value, turn_index
FROM session_refs
ORDER BY session_id, turn_index;

ファイルアクセスのパターンから、アーキテクチャ上重要なファイルがわかります — プロジェクトのページに記録してください。

セッション参照は Copilot のセッションを Git の履歴に結び付けます — Wiki の知識を具体的なコード変更に関連付けるのに役立ちます。

ステップ 4：トピックごとに分類する

セッションごとに Wiki ページを 1 つ作成しないでください。代わりに：

• 抽出した知識を、複数のセッションにわたってトピックごとにまとめます
• 「認証のデバッグ＋CI のセットアップ」に関する 1 つのセッション → 2 つの別々のトピック
• 数日間にわたる「React のパフォーマンス」に関する 3 つのセッション → 1 つに統合したトピック
• cwd／repository は自然な第 1 階層の分類として使えます。vscode.metadata.json の customTitle からは、人が読みやすいセッション名を取得できます

ステップ 5：Wiki ページに要点をまとめる

各 Copilot プロジェクトは、Vault 内のプロジェクトディレクトリに対応します。cwd または repository からプロジェクト名を特定します：

C:\Users\name\git\my-project   → my-project
/Users/name/code/another-app   → another-app

利用できる場合は、生の cwd よりも session-store.db の repository（例：owner/repo）を優先してください。

プロジェクト固有の知識とグローバルな知識

見つけたもの	配置場所	例
プロジェクトのアーキテクチャ上の決定	projects/<name>/concepts/	projects/my-project/concepts/main-architecture.md
プロジェクト固有のデバッグパターン	projects/<name>/skills/	projects/my-project/skills/api-rate-limiting.md
ユーザーが学んだ一般的な概念	concepts/ (グローバル)	concepts/react-server-components.md
プロジェクトをまたぐ再発する問題	skills/ (グローバル)	skills/debugging-hydration-errors.md
使用したツール/サービス	entities/ (グローバル)	entities/vercel-functions.md
多くのセッションをまたぐパターン	synthesis/ (グローバル)	synthesis/common-debugging-patterns.md

内容のある各プロジェクトについて、projects/<name>/<name>.md にあるプロジェクト概要ページを作成または更新してください — _project.md ではなく、プロジェクト名にちなんだ名前を付けます。Obsidian のグラフビューはファイル名をノードラベルとして使用するため、_project.md だとすべてのプロジェクトがグラフ上で _project として表示されてしまいます。<name>.md と名付けることで、各プロジェクトに固有で読みやすいノード名が付きます。

重要: 会話ではなく、知識 を抽出してください。「3月15日のセッションで、ユーザーは X について尋ねました」とは書かないでください。セッションを出典の帰属として示しつつ、知識そのものを書いてください。

すべての新規/更新ページに summary: frontmatter フィールドを書いてください — 1〜2文、200文字以内で、ページを開いていない読者に向けて「このページは何についてのものか?」に答えるものです。wiki-query の低コストな検索パスは、このフィールドを読んでページ本文を開くのを避けます。

すべての新規ページの frontmatter に confidence フィールドと lifecycle フィールドを追加してください:

base_confidence: 0.42
lifecycle: draft
lifecycle_changed: <obsidian-wiki memory now --date>

更新時は lifecycle を変更しないでください。

llm-wiki の規約 (Provenance Markers セクション) に従って出所をマークしてください:

• チェックポイントと index.md はシステムによって事前に抽出されています — チェックポイント由来の主張は抽出済みとして扱ってください (システムが観測されたアクションからそれらを書きました)。
• メモリアーティファクト はユーザーが作成したものです — 抽出済みとして扱ってください。
• 会話ターンの抽出 はほとんどが推論です。あなたは多くのターンから一貫した主張を合成しています。合成されたパターン、セッションをまたぐ一般化、そして「ユーザーが本当に意図していたこと」の解釈には、^[inferred] を惜しみなく適用してください。
• ユーザーがセッションの途中で方向転換した場合や、セッションが未解決のまま終了した場合は、^[ambiguous] を使用してください。
• すべての新規/更新ページに provenance: frontmatter ブロックを書き、おおよその内訳を要約してください。

ステップ6: マニフェスト、ジャーナル、特別なファイルを更新する

.manifest.json を更新する

処理した各セッションについて、そのエントリを追加/更新してください:

• ingested_at、session_id、updated_at
• source_type: "copilot_session"、"copilot_checkpoint"、"copilot_transcript"、"copilot_memory_artifact" のいずれか
• project: デコードされたプロジェクト名
• pages_created と pages_updated のリスト

マニフェストの projects セクションも更新してください:

{
  "project-name": {
    "repository": "owner/repo",
    "cwd": "C:\\Users\\name\\git\\project-name",
    "vault_path": "projects/project-name",
    "last_ingested": "TIMESTAMP",
    "sessions_ingested": 5,
    "sessions_total": 8,
    "checkpoints_ingested": 12,
    "memory_artifacts_ingested": 3
  }
}

ジャーナルエントリを作成し、特別なファイルを更新する

index.md、log.md、hot.md を1回のロックされた呼び出しで更新してください:

obsidian-wiki memory sync COPILOT_HISTORY_INGEST \
  projects=<projects> sessions=<sessions> checkpoints=<checkpoints> \
  pages_updated=<pages_updated> pages_created=<pages_created> \
  mode=<mode> \
  --takeaways "Ingested 5 Copilot sessions across 2 projects; surfaced patterns in API design and testing strategy."

index.md、log.md、hot.md を手動で編集しないでください — このコマンドは、並行して書き込むライターがあなたの更新を失わないようにするロックを取得します。--takeaways は、以前は Recent Activity に記載されていた1行の概念的な要約です。 省略すると、以前の takeaways はそのまま残ります。

進行中のプロジェクトについて、よりよく理解できた場合は、次のセッションが引き継げるようにスレッドを記録してください: obsidian-wiki memory todo add "<thread>" --origin projects/<name>.md。

完全な手順については .skills/llm-wiki/references/MEMORY.md を参照してください。

プライバシー

• 要点を抽出して統合し、会話の生テキストをそのままコピーしないでください
• シークレット、API キー、パスワード、トークンと思われるものは除外してください
• アシスタントのイベントに含まれる data.reasoningOpaque / data.reasoningText は内部推論です。完全に除外し、Wiki にコピーしないでください
• 個人情報や機密情報にあたる内容が含まれている場合は、記載する前にユーザーに確認してください
• ユーザーの会話で他の人に言及している場合があります。Wiki に何を記載するか慎重に判断してください

参照

詳細なデータ構造のドキュメントについては、references/copilot-data-format.md を参照してください。

Vault への書き込み後の QMD 更新

QMD は検索インデックスであり、信頼できる唯一の情報源ではありません。$QMD_WIKI_COLLECTION が空または未設定の場合は、この手順を省略してください。このスキルが Vault の Markdown を書き込みまたは書き換えた後にのみ実行してください。QMD の更新に失敗しても、Vault の変更をロールバックしないでください。QMD の状態は別途報告してください。

$QMD_CLI が設定されている場合はそれを使用し、設定されていない場合は qmd を使用してください。

${QMD_CLI:-qmd} update

出力にベクトルが必要、または埋め込みが古い可能性があると表示された場合は、次を実行してください。

${QMD_CLI:-qmd} embed

次のいずれかでコレクションを検証してください。

${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"

または、特定のページパスが分かっている場合は、次を使用してください。

${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5

次のいずれかを記録してください。

• QMD refreshed: update + embed + verified
• QMD refreshed: update only + verified
• QMD skipped: QMD_WIKI_COLLECTION unset
• QMD skipped: qmd CLI unavailable
• QMD failed: <short error summary>