ナレッジトランスファーは何をしますか？

プロジェクトの知識を同僚間で引き継ぎます：短い非技術的なオンボーディングドキュメントと、AIが蓄積したプロジェクトメモリを、プロジェクトリポジトリ内にパッケージ化します。これにより、新規参加者はすぐに状況を把握でき、そのAIも情報を得た状態で作業を開始できます。

使用方法

Claude Code スタンドアロンスキル：

/knowledge-transfer            # 自動検出モード（下記参照）
/knowledge-transfer export     # 離脱者：引き継ぎパッケージを構築
/knowledge-transfer import     # 新規参加者：メモリを検証してインストール、ドキュメントを読む

Claude Code プラグインインストール：

/knowledge-transfer:knowledge-transfer
/knowledge-transfer:knowledge-transfer export
/knowledge-transfer:knowledge-transfer import

Codex または SKILL.md を読み取る他のエージェント：

$knowledge-transfer            # 自動検出モード
$knowledge-transfer export     # 離脱者
$knowledge-transfer import     # 新規参加者

モード検出（引数なし）

プロジェクトルートに handover/manifest.json が存在する → インポートモードを通知。
それ以外 → エクスポートモードを通知。

検出されたモードを1行で表示し、処理を進めます。ユーザーはいつでも上書きできます。

契約書

以下のものを生成する前に読んでください：

references/package-format.md — パッケージ構造とマニフェストスキーマ
references/privacy-filter.md — エクスポートしてよいものとそうでないもの
references/onboarding-template.md — ドキュメントの構造、トーン、長さ
references/agent-memory.md — Claude、Codex、または他のエージェントでメモリを特定してインストールする方法

エクスポートフェーズ

プロジェクトを離れる同僚がプロジェクトルートから実行します。

1. プロジェクトを分析する

README、エージェントガイダンスファイル（CLAUDE.md、AGENTS.md、GEMINI.md、.cursor/rules/ など、存在する場合）、トップレベルの構造、エントリポイント、および主要な設定ファイルを読みます。大規模なコードベースの場合は、すべてをインラインで読むのではなく、サブエージェントを使用します。
以下の項目を特定します：プロジェクトの目的、3～7の主要コンポーネント、および説明する価値のある2～3のエンドツーエンドの論理フロー。
プロジェクトの主要言語（README、ドキュメント、最近のコミットメッセージ）を検出します。オンボーディングドキュメントはその言語で記述されます。不明瞭または混合の場合は英語にします。

2. メモリを読む

references/agent-memory.md を使用して、現在のエージェントのプロジェクトメモリソースを見つけます。
このプロジェクトまたはリポジトリにスコープされたメモリのみを読みます。グローバルユーザー設定や無関係なプロジェクト履歴はエクスポートしないでください。
メモリディレクトリがない、またはメモリがない → ドキュメントのみで処理を進め、マニフェストに memories: {"exported": 0, "excluded": 0} を設定し、パッケージにメモリが含まれていないことをユーザーに伝えます。

3. メモリをフィルタリングする

references/privacy-filter.md をすべてのメモリに厳密に適用します。ポータブルバージョン（書き換え済み、中立的）と、メモリごとの除外リストとその理由を作成します。

4. パッケージを書く

handover/ がすでに存在する場合は、停止して上書きする前に確認を求めます。
references/onboarding-template.md に従って handover/ONBOARDING.md を書きます。
残った各メモリをポータブル形式で handover/memories/<slug>.md に書きます。
handover/manifest.json をスキーマに従って書きます（コミットSHAは git rev-parse HEAD から取得。gitリポジトリでない場合は commit を省略、git configに名前がない場合は author を省略）。

5. 最終チェックリスト — 完了を宣言する前に検証する

handover/ ツリー全体を同僚の名前、メールアドレス、ユーザー名で grep：ヒット数0。
handover/memories/ に user タイプのメモリがない。
ONBOARDING.md が600～1000語（wc -w）で、テンプレートの6つのセクションを含んでいる。
エクスポートされたメモリで引用されているすべてのファイル/パスがプロジェクトに存在する。
manifest.json が解析でき、カウントが実際のファイルと一致する。

ユーザーに報告する：パッケージの内容、除外リストとその理由、および handover/ をリポジトリにコミットすることを提案します。確認なしにコミットしないでください。

インポートフェーズ

クローン後、新しい同僚がプロジェクトルートから実行します。

1. パッケージを読む

handover/manifest.json、handover/ONBOARDING.md、および handover/memories/ 内のすべてのファイルを読みます。
handover/ がない → 停止：離脱する同僚が最初に /knowledge-transfer export を実行し、その結果をコミットする必要があることを説明します。
manifest.version が不明 → 停止し、このパッケージにはスキルが古すぎると伝えます。

2. 各メモリを現在のコードに対して検証する

リポジトリがgitで、マニフェストに commit がある場合、git diff --stat <commit>..HEAD を実行して、エクスポート以降にどの領域が変更されたかを確認します。
各メモリについて、それが引用するファイル、パス、識別子がまだ存在するかを確認します（Glob/Grepを使用し、推測はしません）。分類します：
- 有効 — すべて問題なし → そのままインストール。
- 古い、明らかな修正可能 — 例えば、引用されたファイル名が変更され、新しいパスが明確である場合（git log --follow、または一意の検索ヒット）→ メモリ本文を更新し、インストール。
- 古い、明らかな修正不可 — 破棄し、理由を1行で記録。

3. インストール

受け入れられた各メモリを、現在のエージェントのメモリメカニズム（references/agent-memory.md を参照）を通じてインストールします。ポータブルなメモリコンテンツはそのまま保持し、ターゲットエージェントが必要とする場合にのみストレージラッパー/インデックスを適応させます。
既存のメモリとのスラッグ衝突：上書きしないでください。衝突を報告し、ユーザーにどちらを保持するか尋ねます。
ターゲットメモリストアにインデックスファイルがある場合、インストールされたメモリごとに1行のインデックスを追加します（存在しない場合は作成します）。現在のエージェントがメモリへの直接書き込みを禁止している場合、代わりに承認されたメモリ更新アーティファクトを作成するか提示します。

4. 報告

以下の順序でユーザーに提示します：

ONBOARDING.md の全文（設計上短いです）。
インポートサマリー：インストール済み / 更新済み / 破棄、それぞれ1行の理由。
締めくくりのメモ：技術的な質問は、インポートされたメモリを活用できるようになりました。

エッジケース

状況	動作
エクスポート時にメモリがない	ドキュメントのみのパッケージ。明示的にその旨を伝える。
プロジェクトがgitリポジトリではない	`commit` なしのマニフェスト。インポート検証は存在確認のみにフォールバック。
エクスポート時に `handover/` が存在する	上書き前に確認を求める。
インポート時に `handover/` がない	離脱者向けの指示を表示して停止。
インポート時にスラッグ衝突	絶対に上書きしない。表示してユーザーに尋ねる。
`manifest.version` が不明	停止。ユーザーにスキルの更新を依頼する。

ナレッジトランスファー