opencontext

OpenContext

「次のエージェントが読み込み、検索し、または残すべきプロジェクトメモリのパケットは何か？」が本当の問いである場合に、このスキルを使用します。

目的は、oc CLI の全機能を一度に提示することではありません。 目的は次のとおりです。

1. メモリのニーズを正直に分類する
2. 主要なパケットを1つ選ぶ
3. 役に立つ最小限のコンテキストを読み込む
4. 必要な場合にのみ過去の決定を検索する
5. 意味のある作業の後、再利用可能な結論を保存する
6. wiki／グラフ／ボルト／リポジトリパッカーに関する依頼は、すぐに適切な別の手段へ案内する

慣れていないメモリに関する依頼に対応する前に、references/intake-packets-and-route-outs.md を読んでください。 最初に検討すべきことが、どのメモリレイヤーに作業を担わせるかである場合は、references/memory-layer-decision-guide.md を読んでください。 プロジェクトメモリを実際に操作する作業の場合は、references/load-search-store-playbook.md を読んでください。 複数のメモリアーティファクトに食い違いがある場合や、ブランチの鮮度が不明な場合は、references/trust-precedence-and-freshness.md を読んでください。 実際のタスクが OpenContext のインストールや接続設定である場合は、references/setup-and-integration.md を読んでください。

このスキルを使用する場合

• 次のエージェントが何も知らない状態から始めないよう、作業開始前に簡潔なプロジェクトメモリパケットが必要な場合
• リポジトリやプロジェクトの決定事項、落とし穴、受け入れ時の注意点、制約をセッションをまたいで検索できるようにしたい場合
• 巨大なトランスクリプトを貼り付けるのではなく、適切なドキュメントを示す、永続的なエージェント間ハンドオフがチームに必要な場合
• 今読むべき内容を示すマニフェストや安定したリンクが必要な場合
• OpenContext 自体のセットアップ、リポジトリの初期化、統合に関するガイダンスが必要な場合
• OpenContext、wiki、グラフレイヤー、ボルト、リポジトリパッカーのワークフローから選ぶ場合

このスキルを使用しない場合

• 主なタスクが、長期にわたって使用する Markdown ナレッジベースや調査用 wiki の構築である → llm-wiki を使用してください
• 主なタスクが、コード／ドキュメント／メディアの構造のマッピング、GRAPH_REPORT.md の生成、関係性の追跡である → graphify を使用してください
• 主なタスクが、人が作成したメモやボルトのワークフローの整理である → 該当するメモ／ボルトスキルを使用してください
• 主なタスクが、単発でモデルに渡すコンテキストとして、リポジトリを1つのプロンプト／ダイジェストに平坦化することである → そのフローを担当するリポジトリパッカーツールまたはスキルを使用してください
• 主なタスクが、リポジトリの自動化、スクリプト、フック、定期実行コマンドである → deployment-automation を使用してください

手順

ステップ1：すでに手元にあるパケットから始める

references/intake-packets-and-route-outs.md を使用してください。

依頼を次のパケット形式のいずれかに整理します。

• memory-layer-choice-packet — ユーザーが OpenContext、wiki、グラフ、ボルト、リポジトリパッカーの各レイヤーから選択している
• load-context-packet — 次のエージェントが作業開始前に、最小限で正確なコンテキストを読む必要がある
• search-context-packet — 現在のタスクに過去の決定事項、制約、落とし穴、受け入れ時の注意点が必要である
• store-conclusions-packet — 意味のある作業が完了し、再利用可能な成果を保存する必要がある
• setup-integration-packet — OpenContext 自体のインストール／初期化／統合に関するガイダンスが必要である
• repo-packer-route-out-packet — 依頼の実際の内容が、継続的なプロジェクトメモリではなく、単発のリポジトリからプロンプトへのパッキングである

役に立つ最小限の枠組みを記録します。

Packet: load-context-packet
Project scope: active repo
Goal: prepare the next coding agent
Current pain: repeated background + cold starts
Artifact preference: manifest + stable links

ルール：ユーザーがすでに持っているパケットから始めます。すべての依頼に、メモリ分類の全体を詳しく説明する必要はありません。

ステップ2：主要なモードを1つ選ぶ

実行ごとに、主要なモードを必ず1つ選びます。

• memory-layer-choice
• load-context
• search-context
• store-conclusions
• setup-integration
• route-out

任意：副次的なモードを1つ挙げてもかまいません。ただし、load／search／store／setup を1つの巨大な回答にまとめないでください。

Step 3: OpenContext がこの役割を担うべきかどうかを判断する

次の簡易チェックで担当範囲を判断します。

• OpenContext が担当するもの：エージェント向けの進行中プロジェクト／リポジトリのメモリが主なニーズである場合。読み込み優先の小さなパケット、検索可能な決定事項、引き継ぎメモ、マニフェスト、安定したリンクなど
• llm-wiki が担当するもの：長期的に維持する、要約・統合された Markdown のナレッジが主なニーズである場合
• graphify が担当するもの：構造グラフ、関係性の追跡、グラフ成果物が主なニーズである場合
• Vault ／ノートツールが担当するもの：人が作成するノートと編集管理が主なワークフローである場合
• リポジトリパッカーが担当するもの：実際の要望が「今すぐこのリポジトリを単一のプロンプト／ダイジェストにまとめる」ことである場合

OpenContext が適切な担当ではない場合は、万能のメモリレイヤーとして説明するのではなく、すぐに別のツールへ案内してください。

Step 4: 作成する前に読み込む

OpenContext がすでにある場合は、まず状況を把握します。

oc folder ls --all
oc doc ls <folder>
oc search "<topic>" --mode keyword --format json
oc context manifest <folder> --limit 10

次の項目を確認します。

• プロジェクト／トピックのメモリをすでに管理しているフォルダー
• 既存の決定ログ、注意点、受け入れメモ、引き継ぎドキュメント
• 次のエージェントが最初に読むべき、必要最小限のファイル一式
• 複数のノートが重複する場合に、最も信頼できる情報源

さらに読み込んだり検索したりする前に、次の信頼性チェックを一度行います。

• 優先順位：古い要約より、正式なリポジトリドキュメントと最新の決定ログを優先します
• 出所：ノートが人の手で管理されたドキュメント、最新の引き継ぎ、以前のエージェントによる要約、推定に基づくヒューリスティックのどれに由来するかを明記します
• 鮮度：ブランチ、リリース、移行、インシデントの状態によって、ノートが無効になっていないか確認します

デフォルトのルール：同じ目的の別ドキュメントを並行して作成する前に、既存のメモリドキュメントを更新します。

Step 5: 読み込み → 検索 → 保存のループを実行する

references/load-search-store-playbook.md を使用します。

A. load-context

次のエージェントに、必要最小限で正確な初期コンテキストが必要な場合に使用します。

一般的な出力：

• マニフェストコマンド、または読み込み優先のパケットを1つ
• 推奨フォルダーを1つ
• 最初に読むべきドキュメントの短いリストを1つ
• 最も信頼性の高い情報源と、古くなっている可能性への警告を示す信頼性メモを1つ

次の質問に答えます。

• プロジェクトメモリのホームとなるフォルダーはどれですか？
• 最初に読むべきドキュメントはどの3〜10件ですか？
• 既存の制約や注意点は何ですか？
• ドキュメント間で食い違いがある場合、現時点でどの情報源を優先しますか？
• ブランチまたはリリースの状態によって、保存済みのノートが危険になっていませんか？

B. search-context

現在の作業で推測に頼ることになる場合に使用します。

一般的な検索対象：

• 過去の決定事項
• 受け入れ基準
• 環境固有の問題
• アーキテクチャ上の制約
• リリースノートやインシデントから得た教訓

デフォルトでは、まずキーワード検索とマニフェストを試します。コーパスと失敗モードから必要性が明らかでない限り、埋め込みやインデックスの構築にすぐ着手しないでください。

C. store-conclusions

意味のある作業の後に使用し、細かな編集のたびには使用しないでください。

適切なドキュメントの形式：

• decision-log.md
• pitfalls.md
• acceptance-criteria.md
• release-notes.md
• handoff-YYYY-MM-DD.md

有用な保存ノートには、通常、次の内容が含まれます。

• 何を変更したか
• なぜその選択をしたか
• 次に何を検証するか
• 後で必要になる、最小限の証拠へのリンク／引用
• 成果物間で食い違いがあった場合にどの情報源を優先したか、および次のセッション向けのブランチ／鮮度に関する警告

Step 6: セットアップと連携を適切に扱う

references/setup-and-integration.md を使用します。

提示しておく価値のある基本コマンド：

npm install -g @aicontextlab/cli
# or
npx @aicontextlab/cli <command>

cd your-project
oc init
oc folder ls --all
oc doc create <folder> <doc>.md -d "Description"
oc search "query" --mode keyword --format json
oc context manifest <folder> --limit 10
oc doc link <doc_path>

キーワード検索とマニフェストだけでは不十分で、インデックス作成のコストに見合う場合にのみ、埋め込み／インデックス作成へ進みます。

ステップ 7：適切な場合は正直に別のツールへ案内する

よくある案内先：

• llm-wiki — 物語的な統合、エンティティ／概念ページ、インデックス／ログ／スキーマの管理
• graphify — グラフ成果物、リポジトリ／コーパスの構造マッピング、関係の追跡
• Vault／ノートのスキル — 人間を第一に考えたノートの整理と編集
• リポジトリパッカー（Repomix／Gitingest／Code2Prompt 形式のワークフロー） — リポジトリを一度でプロンプト用のコンテキストにまとめる
• deployment-automation — メモリの管理が本来の目的ではない、定期実行スクリプト、リポジトリフック、自動化

ユーザーが「このリポジトリを 1 つのモデル用プロンプトにまとめて」と言うなら、それは opencontext の仕事ではありません。 「次のエージェントが、何を読み込むべきか、すでに何を決定したか、タスクの後に何を保存すべきかを把握できるようにして」と言うなら、そうです。

ステップ 8：簡潔なプロジェクトメモリ概要を 1 つ返す

推奨形式：

# Project Memory Brief

## Packet
- Packet:
- Primary mode:
- Project horizon:
- Why OpenContext owns this (or route-out):

## Do now
1. ...
2. ...
3. ...

## Read / search / store targets
- Folder:
- Docs to read first:
- Search terms:
- Note to update or create:

## Trust check
- Highest-confidence source:
- Provenance:
- Freshness / branch warning:

## Route-outs
- ...

巨大な CLI 百科事典より、短く確定的なパケットのほうが優れています。

出力形式

常に プロジェクトメモリ概要、メモリレイヤー選択メモ、または OpenContext セットアップノートを返します。

必須の要件：

• 手元にあるパケットを特定する
• 主モードを 1 つ選ぶ
• OpenContext がその仕事を担うのか、別のツールへ案内すべきかを説明する
• 最小限で正確なマニフェスト／検索／保存パケットに焦点を絞る
• ノートが重複している場合に、最も信頼度の高い情報源を示す
• 保存済みメモリが無効になりうる場合は、鮮度やブランチのリスクに触れる
• 埋め込み／インデックス構築は、エスカレーション手段としてのみ触れる
• 別のメモリレイヤーやツールのほうが適切な場合は、次の担当を明示する

例

例 1：コーディング前にプロジェクトメモリを読み込む

入力

エージェントのセッション間でリポジトリの背景情報が失われ続けています。次のコーディングエージェントが、このリポジトリに手を加える前に適切なドキュメントを読み込めるようにしたいです。

出力の概要

• パケット：load-context-packet
• 主モード：load-context
• 必要なのは稼働中のリポジトリメモリの起動パケットなので、OpenContext が適しています
• 対応：フォルダーを特定し、マニフェストを生成し、最初に読むべき 3～10 件のドキュメントを列挙して、タスク後に引き継ぎノートを残す

例 2：メモリレイヤーの選択

入力

このプロダクトの作業には、OpenContext、Wiki、Obsidian、グラフツールのどれを使うべきでしょうか？

出力の概要

• パケット：memory-layer-choice-packet
• 主モード：memory-layer-choice
• プロジェクトメモリ、Wiki、グラフ、人間向け Vault の役割を区別する
• OpenContext は、稼働中のプロジェクト／リポジトリのメモリと引き継ぎパケットにのみ使用する

例 3：作業中に過去の決定を検索する

入力

このリリースフローを変更する前に、デプロイの制約やロールバックに関するメモをすでに記録していないか検索してください。

出力の概要

• パケット：search-context-packet
• 主モード：search-context
• まず既存の決定ログ／リリースノートを検索する
• インデックス作成へエスカレーションする前に、キーワード検索とマニフェストを優先する

例 4：本当のタスクはリポジトリを一度でまとめること

入力

今すぐモデルに貼り付けられるよう、このリポジトリを 1 つのプロンプトにまとめてください。

出力の概要

• パケット：repo-packer-route-out-packet
• 主モード：route-out
• OpenContext が適切なツールであるかのように装うのではなく、Repomix／Gitingest／Code2Prompt 形式のワークフローに案内する

例 5：リリースブランチ上でメモリアーティファクトが競合している

入力

README.md にはデプロイ手順が 1 つ書かれていますが、CLAUDE.md には別の手順があります。さらに、今リリースブランチに切り替えたところです。次のエージェントはどちらを信頼すべきでしょうか？

出力の概要

• パケット：load-context-packet または search-context-packet
• 両方のノートを混ぜてしまわず、最も信頼度の高い情報源を示す
• 出所を説明し、ブランチ／リリースの状態によって古い指示が無効になっている可能性に触れる
• どちらの情報源を採用したか、何を引き続き確認する必要があるかを説明した簡潔な引き継ぎノートを保存する

ベストプラクティス

1. 「memory」という単語が出てきたからではなく、ワークフローにアクティブなプロジェクト／リポジトリのメモリが必要だから、OpenContext を選びます。
2. 重複するものを作成するより、既存のドキュメントを更新することを優先します。
3. まず役立つ最小限のコンテキストを読み込みます。大量の情報を無差別に読み込むより、マニフェストを活用します。
4. メモリアーティファクトが重複する場合は、どの情報源を優先するか、その理由とともに明示します。
5. ブランチ／リリース／インシデントの状態は、背景情報ではなく鮮度確認として扱います。
6. 意味のある作業の後に決定事項を記録し、次のセッションでの曖昧さを減らします。
7. ドキュメントの形式を統一します（decision-log、pitfalls、handoff、acceptance-criteria、release-notes）。
8. 埋め込み／インデックスの構築は、デフォルトではなく、必要に応じた対応として扱います。
9. wiki、グラフ、vault、repo-packer に関する依頼は、ひとつのスキルにまとめず、早い段階で適切な担当先に振り分けます。

参考資料

• インテークパケットと適切な担当先への振り分け
• メモリレイヤーの選択ガイド
• 読み込み／検索／保存の手引き
• 信頼性、優先順位、鮮度
• セットアップと統合に関する注意事項
• OpenContext README
• OpenContext の使用方法に関するドキュメント
• Karpathy の LLM Wiki gist
• Graphify README