context-network

コンテキストネットワークのライフサイクル

ユーザーがコンテキストネットワークを構築・保守できるよう支援します。コンテキストネットワークとは、プロジェクトの知識を整理する構造化されたフレームワークであり、セッションをまたいで維持され、人間とエージェントの両方の作業を支えます。あなたの役割は、コンテキストネットワークの状態を診断し、適切な足場を生成し、コンテンツに関する判断をユーザーに助言することです。

基本原則

コンテキストネットワークは、関係を明示します。 暗黙の知識はセッションの境界を越えて残りません。構造があることで、情報を見つけやすくなります。目指すのは完全性ではなく、ナビゲーションのしやすさです。

クイックリファレンス

次の場合にこのスキルを使用します：

• 永続的なコンテキストが必要な新しいプロジェクトを始めるとき
• 既存のドキュメントが散在している、または見つけにくいと感じるとき
• コンテキスト不足により、エージェントの効果が低下しているとき
• コンテキストの振り返りで、対処すべきギャップが見つかったとき

主な状態：

• CN0： ネットワークなし — プロジェクトにコンテキストネットワークがありません
• CN1： ドキュメントが散在 — ドキュメントはありますが、ネットワークとして整理されていません
• CN2： サイロ化された構造 — 構造はありますが、つながりがありません
• CN3： ナビゲーションの不備 — つながりはありますが、たどるのが困難です
• CN4： ガイダンスが不明確 — 構造は機能していますが、エージェント向けの指示が不十分です
• CN5： 関係の欠落 — 影響や依存関係が文書化されていません
• CN6： 保守の不全 — ネットワークはありますが、現状とのずれが生じています

---

状態

状態 CN0：ネットワークなし

症状： .context-network.md ファイルがありません。context/ ディレクトリもありません。ドキュメントは README に散在しているか、まったく存在しません。エージェントがセッションごとに同じ質問をします。

主な質問：

• これはどのような種類のプロジェクトですか？（ソフトウェア、研究、創作、個人の知識管理）
• このコンテキストを誰が利用しますか？（個人、チーム、エージェント）
• 想定される存続期間はどのくらいですか？

対応策：

• ブートストラップモードを実行します（下記参照）
• 検出ファイルと初期構造を生成します
• 最小限の実用的なコンテンツについて助言します

状態 CN1：ドキュメントが散在

症状： README.md が肥大化しています。docs/ フォルダーはありますが、ファイル同士がつながっていません。アーキテクチャ上の決定が、コメントやコミットメッセージに埋もれています。エージェントは部分的な情報を見つけますが、関連性を見落とします。

主な質問：

• どのようなドキュメントがすでにありますか？
• どのドキュメントがまだ正確ですか？
• これらのドキュメント間にはどのような関係がありますか？

対応策：

• 既存のドキュメントを調査します
• コンテキストネットワーク構造への移行計画を提案します
• 移行したコンテンツの関係マッピングを生成します

状態 CN2：サイロ化された構造

症状： コンテキストネットワークがあり、ディレクトリ構造も明確です。ファイルは各ドメイン内で適切に整理されています。しかし、相互参照はほとんどありません。エージェントは各ドメイン内の情報を見つけますが、ドメインをまたぐ影響を見落とします。

主な質問：

• どのドメインが互いに影響しますか？
• A の変更に伴い、通常 B ではどのような変更が必要ですか？
• 異なるドメインで異なる名前が付けられている共通概念はありますか？

対応策：

• 関係性のテンプレートを生成します
• ドメインをまたぐつながりを特定できるよう助言します
• ドメイン間をつなぐハブドキュメントを作成します

状態 CN3：ナビゲーションの不備

症状： 情報は存在し、つながっていますが、見つけにくい状態です。status.md が古くなっています。一般的なタスクに対する明確な入口がありません。エージェントは必要な情報を見つけるために、多数のファイルを読みます。

主な質問：

• エージェントが最も頻繁に行うタスクは何ですか？
• 最もよく読まれるファイルと、最も読まれないファイルはどれですか？
• 誰も参照していない孤立したドキュメントはありますか？

対応策：

• ハブドキュメントを作成・更新します
• タスクベースのナビゲーションガイドを整備します
• 孤立したコンテンツを整理または統合します

状態 CN4：ガイダンスが不明確

症状： コンテキストネットワークは適切に構成されています。CLAUDE.md もありますが、エージェントは依然として誤った判断をします。指示はありますが、従われていません。エージェントの振る舞いが、文書化されたパターンと一貫していません。

主な質問：

• どのようなエージェントの振る舞いが問題ですか？
• 指示が曖昧、または矛盾していませんか？
• ガイダンスが抽象的すぎて、行動に移せない状態ではありませんか？

対応策：

• CLAUDE.md を具体的で実行可能な指示に見直します
• 抽象的なガイダンスに例を追加します
• よくある判断のための決定木を作成します

状態 CN5：関連性の欠如

症状： ある領域の変更が、別の領域に予期せぬ問題を引き起こします。タスクの途中で依存関係が判明します。判断の影響が実装後まで不明です。エージェントは、ほかに何を確認すべきかわかりません。

主な質問：

• 最近、予期せぬ波及効果があった変更は何ですか？
• データ、状態、インターフェースを共有しているコンポーネントはどれですか？
• 領域間にはどのような暗黙の契約がありますか？

対策：

• 依存関係マップを文書化する
• 影響関係のドキュメントを作成する
• 主要なノードに「影響する対象」と「影響を受ける対象」のセクションを追加する

状態 CN6：メンテナンスの停滞

症状： コンテキストネットワークは以前は役立っていましたが、現在は実態との乖離が進んでいます。status.mdには古い状態が記載されています。文書化された決定が更新されていません。エージェントは古い情報を参照しています。

主な質問：

• ネットワークが最後に実質的な更新を受けたのはいつですか？
• どのようなきっかけで更新すべきですか？
• メンテナンスの責任者は誰、または何ですか？

対策：

• メンテナンスの頻度を定める
• 更新のきっかけを定義する
• 継続的な改善のために、context-retrospective スキルと連携させる

---

運用モード

ブートストラップモード（CN0/CN1 → CN2）

新しく開始するときや、散在するドキュメントを整理するときに使用します。

プロセス：

1. 既存ドキュメントのスキャン

以下を自動的にスキャンします：

• README.md、docs/、documentation/
• アーキテクチャ決定記録（ADR、adr/、decisions/）
• 設計ドキュメント、計画ファイル
• プロジェクトのメタデータを確認するためのパッケージファイル（package.json、Cargo.toml、pyproject.toml）
• 既存の .claude/ またはメモリバンクの構造

調査結果を報告します：

Found existing documentation:
- README.md (2.3kb) - Project overview, setup instructions
- docs/architecture.md (5.1kb) - System design
- docs/api.md (3.2kb) - API reference

Recommendation: Migrate architecture.md to context/architecture/,
keep README.md in place as user-facing doc.

2. プロジェクトの確認事項

次の項目を確認します：

• プロジェクトの種類は？ ソフトウェア／研究／クリエイティブ／個人ナレッジ
• 主な領域は？（ソフトウェアの場合：フロントエンド、バックエンド、データ、インフラなど）
• 関係者は？ 個人／チーム／エージェント／混在
• 想定される存続期間は？ 短期／長期／無期限
• 見つかったドキュメントのうち、取り込むものと、そのまま残すものはどれですか？

3. 構造の生成

プロジェクトの種類に基づいて生成します：

ソフトウェアプロジェクトの場合：

context/
├── status.md           # Current state, active work
├── decisions.md        # Architecture decisions
├── glossary.md         # Domain vocabulary
├── architecture/       # System design docs
├── domains/            # Domain-specific context
│   ├── [domain-1]/
│   └── [domain-2]/
└── processes/          # Workflows, procedures

研究プロジェクトの場合：

context/
├── status.md           # Current research state
├── decisions.md        # Methodology decisions
├── glossary.md         # Technical vocabulary
├── sources/            # Source tracking
├── findings/           # Research discoveries
└── questions/          # Open questions, hypotheses

クリエイティブプロジェクトの場合：

context/
├── status.md           # Current project state
├── decisions.md        # Creative decisions
├── glossary.md         # World/project vocabulary
├── world/              # Worldbuilding, setting
├── characters/         # Character information
└── structure/          # Plot, outline, structure

個人ナレッジの場合：

context/
├── status.md           # Current focus areas
├── decisions.md        # System decisions
├── glossary.md         # Personal vocabulary
├── areas/              # Life areas (PARA-style)
├── projects/           # Active projects
└── resources/          # Reference material

さらに、以下も生成します：

• プロジェクトのルートに .context-network.md の探索用ファイル
• 基本的なエージェント向け指示を記載した CLAUDE.md（存在しない場合）

4. 移行の実行

ユーザーが取り込みを希望するドキュメントについて：

• 適切なコンテキストネットワークの場所にコピーまたは移動する
• 必要に応じて形式を変換する（例：ADRを decisions.md の項目にまとめる）
• 内部の相互参照を更新する
• 関係性のメタデータを追加する

5. コンテンツ作成の支援

ユーザーが以下を記入できるよう支援します：

• status.md：現在の状態、最近の変更、進行中の作業
• decisions.md：下された重要な決定、その根拠、日付
• glossary.md：プロジェクト固有の用語、略語
• 移行したコンテンツ間の関係性

---

メンテナンスモード（CN2-CN6 → 改善された状態）

ネットワークが存在するものの、改善が必要な場合に使用します。

プロセス：

1. 状態の診断

以下を分析します：

• 構造の完全性：必須ファイルが揃っているか？各領域が網羅されているか？
• 関係性の密度：ドキュメントごとの相互参照数は？孤立したファイルはあるか？
• ナビゲーション経路：明確な入口があるか？タスク別の経路があるか？
• ガイダンスの明確さ：CLAUDE.mdは実行可能な内容か？指示は守られているか？
• 情報の鮮度：最終更新日はいつか？古くなったコンテンツはないか？

診断結果を作成します：

Current State: CN3 (Navigation Broken)

Findings:
- 23 context files, 8 with no incoming links (orphans)
- status.md last updated 3 weeks ago
- No task-based entry points defined
- Cross-domain relationships sparse (avg 1.2 per file)

Priority Issues:
1. [Critical] status.md is stale - blocks agent orientation
2. [High] 8 orphan files - content exists but undiscoverable
3. [Medium] Missing hub for API-related context

2. 不足項目の特定

優先度を設定します：

• 重大：エージェントの有効性を妨げている（必要な情報を見つけられない）
• 高：リアルタイムでの探索が必要（エージェントが検索しなければならない）
• 中：効率を向上できる（ナビゲーションに余分な手順が必要）
• 低：あると便利（改善効果はわずか）

3. 介入

診断された状態に基づきます。

状態	生成	コーチング
CN2	関係性のテンプレート	つながりを特定する方法
CN3	ハブドキュメント、ナビゲーションガイド	タスクに基づく整理
CN4	CLAUDE.md の改善	実行可能な指示の書き方
CN5	依存関係マップのテンプレート	影響分析のプロセス
CN6	メンテナンス頻度のドキュメント	更新のきっかけ、責任

---

振り返りの統合

context-retrospective スキルからの出力を受け入れます。

1. 所見を取り込む：ナレッジの不足、ナビゲーションの問題、ガイダンスの評価
2. 状態に対応付ける：これらの所見が示す CN の状態はどれですか？
3. 優先順位を付ける：振り返りの優先度レベル（Critical／High／Medium／Low）を使用します
4. 実行する：適切なメンテナンスモードの介入を実施します

---

アンチパターン

空の足場

パターン： ディレクトリ構造全体を生成する一方で、ファイルを空のままにするか、プレースホルダーの内容だけを入れます。 問題： 内容のない構造は、構造がない場合よりも悪いものです。コンテキストが存在するという誤った安心感を生みます。 対策： ユーザーが内容を追加すると決めた構造だけを生成します。status.md と1つのドメインから始めます。内容が蓄積するにつれて拡張します。

あれもこれも詰め込む

パターン： 初期ネットワークで、あらゆる可能なニーズを予測しようとします。複雑な分類体系、深い階層、精巧なメタデータを作成します。 問題： メンテナンスの負担が価値を上回ります。ネットワークが威圧的になり、ユーザーは更新を避けるようになります。 対策： 最小限から始めます。不足による不便が生じてから構造を追加します。最初は階層を最大2段階にします。

孤立したネットワーク

パターン： 最初の熱意でネットワークを作成した後、更新を一切しません。status.md が作成時点のままになります。 問題： 古くなったコンテキストは、コンテキストがない場合よりも悪いものです。エージェントが古い情報に基づいて動作します。 対策： 最小限のメンテナンスのきっかけを設定します。セッションの開始時と終了時に status.md を更新します。定期的な振り返りを予定に入れます。

テンプレートの罠

パターン： テンプレートを調整せずに使用します。関連性にかかわらず、すべてのファイルに同じセクションを設けます。 問題： 定型文が実際の内容を覆い隠します。テンプレートが読み飛ばされるノイズになります。 対策： テンプレートは出発点であり、必須要件ではありません。不要なセクションは削除し、プロジェクト固有のセクションを追加します。

完全性の錯覚

パターン： ネットワークですべてを記録できる、または記録すべきだと考えます。あらゆる不足を防ごうとして、詳細を次々と追加します。 問題： シグナル対ノイズ比が低下します。ナビゲーションが不可能になります。メンテナンスを継続できなくなります。 対策： 影響の大きい不足に焦点を当てます。エージェントが実際に必要とする情報を記録します。リアルタイムでの発見が常に一部残ることを受け入れます。

---

検証（オラクル）

このスキルで検証できること

• 構造の完全性：必須ファイルが存在し、ディレクトリが揃っていること
• リンクの有効性：相互参照が存在する対象を指していること
• 鮮度の指標：最終更新日、更新頻度
• 孤立の検出：参照元のないファイル

人間の判断が必要なこと

• 内容の品質：情報は正確で有用ですか？
• 関係性の正確さ：記録されたつながりは実態を反映していますか？
• 適切な範囲：ネットワークの規模はプロジェクトに見合っていますか？
• ナビゲーションの有効性：経路は実際の使用パターンに合っていますか？

---

設計上の制約

このスキルが想定すること

• プロジェクトがセッションをまたいだ永続的なコンテキストから恩恵を受ける
• ユーザーがエージェントからアクセス可能なドキュメントを求めている
• 完全に自由形式のメモよりも、ある程度の構造が望ましい

このスキルでは扱わないこと

• リアルタイムのプロジェクト作業 - domain-specific skills に振り分けます
• エージェントのセッションに関する振り返り分析 - context-retrospective に振り分けます
• フレームワークの開発 - skill-builder に振り分けます

適合性低下の兆候

• ユーザーが「README だけでいい」と希望している - 完全なネットワークは不要かもしれません
• プロジェクトの期間が1週間未満 - オーバーヘッドがメリットを上回る可能性があります
• 純粋なスパイク／実験 - 自由形式のメモのほうが適している可能性があります

---

出力の永続化

出力の検出

構造を生成する前に、以下を行います。

1. 既存の .context-network.md を確認します
2. 既存の context/ ディレクトリを確認します
3. 新規に開始する場合は、ユーザーに対象の場所を確認します

主な出力

このスキルで生成するもの：

• .context-network.md - 検出ファイル
• context/ ディレクトリ構造
• テンプレートファイル（status.md、decisions.md、glossary.md）
• CLAUDE.md の更新（必要な場合）

保存先

ファイルに保存	会話内に残す
ディレクトリ構造	診断に関する議論
テンプレートファイル	コーチングの質疑応答
検出ファイル	移行に関する決定
CLAUDE.md の更新	優先順位付けの理由

---

統合グラフ

インバウンド（他のスキルから）

ソーススキル	トリガー	アクション
context-retrospective	ギャップの発見	メンテナンスモードを実行
skill-builder	新しいスキルでコンテキストが必要	ブートストラップモードを実行

アウトバウンド（他のスキルへ）

トリガー	対象スキル	理由
CN4 による介入後もエージェントの動作問題が続く	CLAUDE.md のパターンを確認	スキルレベルの変更が必要な場合があります
ネットワークが成熟し、継続的な改善を望む	context-retrospective	定期的なヘルスチェック

補完的なスキル

スキル	関係
context-retrospective	事後分析をメンテナンスモードに活用
skill-builder	スキルでコンテキストネットワークの基盤が必要になる場合があります

---

やり取りの例

ユーザー：「新しい TypeScript プロジェクトを始めるので、コンテキストネットワークを設定したいです。」

進め方：

1. 既存のドキュメント（package.json、README など）をスキャンします
2. 次のように尋ねます。「主な領域は何ですか？（例：API、CLI、ライブラリ、フルスタックアプリ）」
3. 回答に基づいて、ソフトウェアプロジェクトのひな形を生成します
4. .context-network.md と context/ 構造を作成します
5. 次のように案内します。「まず status.md から始めましょう。プロジェクトの現在の状態はどうなっていますか？」