codex-history-ingest

Codex 履歴の取り込み — 会話のマイニング

ユーザーの過去の Codex セッションから知識を抽出し、Obsidian のウィキにまとめます。セッションログには豊富な情報が含まれますが、ノイズも多いため、運用テレメトリーではなく、長期的に役立つ知識に注目してください。

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

開始前

執筆スタイル： 自然言語の 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 と CODEX_HISTORY_PATH（デフォルトは ~/.codex）が決まります
2. ボルトのルートにある .manifest.json を読み込み、すでに取り込まれている内容を確認します
3. ボルトのルートにある index.md を読み込み、ウィキにすでに含まれている内容を把握します

取り込みモード

追記モード（デフォルト）

ソースファイルごとに .manifest.json を確認します。次のファイルのみを処理します。

• マニフェストにないファイル（新しいセッションのロールアウト、新しいインデックスファイル）
• マニフェスト内の ingested_at より更新日時が新しいファイル

通常の同期では、このモードを使用します。

フルモード

マニフェストの内容にかかわらず、すべてを処理します。wiki-rebuild の後、またはユーザーが明示的に全件の再取り込みを求めた場合に使用します。

Codex のデータ構成

Codex はローカルのアーティファクトを ~/.codex/ に保存します。

~/.codex/
├── sessions/                          # Session rollout logs by date
│   └── YYYY/MM/DD/
│       └── rollout-<timestamp>-<id>.jsonl
├── archived_sessions/                 # Archived rollout logs
├── session_index.jsonl                # Lightweight index of thread id/name/updated_at
├── history.jsonl                      # Local transcript history (if persistence enabled)
├── config.toml                        # User config (contains history settings)
└── state_*.sqlite / logs_*.sqlite     # Runtime DBs (usually skip)

価値の高い主なデータソース

1. session_index.jsonl — ID、タイトル、鮮度を確認するための最適なインベントリソース
2. sessions/**/rollout-*.jsonl — 構造化されたトランスクリプトイベントを豊富に含みます
3. history.jsonl — 有効な場合に役立つフォールバックおよびタイムライン補助情報

ユーザーが明示的に求めない限り、SQLite の内部データの取り込みは避けてください。

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

CODEX_HISTORY_PATH をスキャンし、.manifest.json と照合します。

• ~/.codex/session_index.jsonl
• ~/.codex/sessions/**/rollout-*.jsonl
• ~/.codex/archived_sessions/**（任意。ユーザーがアーカイブ履歴を求めた場合のみ）
• ~/.codex/history.jsonl（任意のフォールバック）

各ファイルを次のように分類します。

• 新規 — マニフェストにない
• 変更済み — マニフェストにあるが、ファイルの更新日時が ingested_at より新しい
• 変更なし — すでに取り込み済みで、変更されていない

詳細な解析に入る前に、差分の概要を簡潔に報告します。

ステップ 2：まずセッションインデックスを解析する

session_index.jsonl には通常、次のようなエントリーが含まれています。

{"id":"...","thread_name":"...","updated_at":"..."}

次の目的で使用します。

• 正規のセッションインベントリを作成する
• 最近のセッションや重要度の高いセッションを優先する
• ロールアウト ID を人が読めるスレッド名に対応付ける

ステップ 3：ロールアウト JSONL を安全に解析する

各 rollout-*.jsonl の行は、次の内容を持つイベントエンベロープです。

{
  "timestamp": "...",
  "type": "session_meta|turn_context|event_msg|response_item",
  "payload": { ... }
}

抽出ルール

• ユーザーの意図と、アシスタントに表示された出力を優先します
• ユーザーまたはアシスタントのメッセージ内容を含む response_item レコードを優先します
• 重要な節目については event_msg を選択的に使用し、純粋なテレメトリーは無視します
• session_meta はユーザーの知識ではなく、メタデータ（cwd、モデル、ID）として扱います

除外／ノイズのフィルター

• トークン使用量の記録イベント
• 意味のある内容を含まないツール連携情報
• 再利用可能な判断やパターンを含まない生のコマンド出力
• 新しい判断が追加されていない、繰り返しの計画スナップショット

重要なプライバシーフィルター

ロールアウトログには、挿入された指示、ツールのペイロード、機密情報が含まれる場合があります。システム／開発者プロンプトや秘密情報をそのまま取り込まないでください。

• API キー、トークン、パスワード、認証情報を削除します
• 関連性があり、承認されている場合を除き、個人を特定できる情報を伏せます
• 生のトランスクリプトを引用する代わりに要約します

ステップ 4：トピックごとにまとめる

セッションごとにウィキページを作成しないでください。

• 多数のセッションに共通する安定したトピックごとにまとめます
• 複数のテーマが混在するセッションは、別々のテーマに分けます
• 日付やプロジェクトをまたいで繰り返される概念を統合します
• メタデータの cwd からプロジェクトの範囲を推測します

ステップ 5: Wiki ページに蒸留する

抽出したナレッジを、既存の Wiki の慣習に従って振り分けます:

• プロジェクト固有のアーキテクチャ/プロセス → projects/<name>/...
• 一般的な概念 → concepts/
• 繰り返し発生するテクニック/デバッグプレイブック → skills/
• ツール/サービス → entities/
• セッションをまたぐパターン → synthesis/

影響を受ける各プロジェクトについて、projects/<name>/<name>.md を作成/更新します（ファイル名にはプロジェクト名を使用し、_project.md は決して使用しません）。

記述ルール

• 時系列ではなくナレッジを蒸留する
• 日付の文脈が不可欠でない限り、「日付 X に私たちは…について議論した」という表現は避ける
• 新規/更新する各ページに summary: フロントマターを追加する（1〜2 文、200 文字以内）
• すべての新規ページに confidence フィールドと lifecycle フィールドを追加する:

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

  更新時は lifecycle を変更しない。
• 出典マーカーを追加する:
  • ^[extracted] — セッションの明示的な内容に直接根拠がある場合
  • ^[inferred] — イベント/セッションをまたいでパターンを総合した場合
  • ^[ambiguous] — セッション間で矛盾がある場合
• 変更した各ページに provenance: フロントマターの内訳を追加/更新する

ステップ 6: マニフェスト、ログ、インデックスを更新する

.manifest.json を更新する

処理した各ソースファイルについて:

• ingested_at、size_bytes、modified_at
• source_type: codex_rollout | codex_index | codex_history
• project: 推定されたプロジェクト名（該当する場合）
• pages_created、pages_updated

トップレベルのプロジェクト/セッション概要ブロックを追加/更新する:

{
  "project-name": {
    "source_path": "~/.codex/sessions/...",
    "last_ingested": "TIMESTAMP",
    "sessions_ingested": 12,
    "sessions_total": 40,
    "index_updated_at": "TIMESTAMP"
  }
}

特殊ファイルを更新する

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

obsidian-wiki memory sync CODEX_HISTORY_INGEST \
  sessions=<sessions> pages_updated=<pages_updated> \
  pages_created=<pages_created> mode=<mode> \
  --takeaways "Ingested 12 Codex sessions; surfaced recurring patterns in CLI tooling and shell scripting."

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

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

プライバシーとコンプライアンス

• 蒸留して総合する。生のトランスクリプトのダンプは避ける
• 機密と思われるものはデフォルトで伏せ字にする
• 個人情報/機密情報を保存する前にユーザーに確認する
• 他者への言及は最小限かつ目的に沿ったものにする

リファレンス

フィールドレベルの解析ノートと抽出ガイダンスについては references/codex-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>