map-project-monorepo

このスキルは、複数のワークスペースメンバーにわたる永続的なプロジェクトメモリを変更します。次のルールは必ず守ってください。 1. メンバーの `CLAUDE.md` を書き込む前に、実際のワークスペース構成を確認してください。 2. 可視性を示すマーカーだけでなく、実際にエクスポートされている、またはアクセス可能な範囲を記述してください。 3. 各メンバーファイルは、Claude の遅延読み込みモデルに対応できるよう、単体で十分な内容にしてください。 4. 調査によって古くなっていると判明しない限り、ルートレベルのプロジェクトルールと、確定済みのアーキテクチャ上の決定を維持してください。 5. このスキルは永続的なプロジェクトメモリを変更するため、自発的に実行してはいけません。明示的なユーザーの意図がある場合、または明示的に呼び出されたワークフローに組み込まれている場合（例：ビルド後にマップを更新する `/ship-playbook`）にのみ実行してください。

プロジェクトのモノレポをマップする

入力

• $request：対象範囲や更新メモ（省略可）。例：all crates、only packages/api-*、refresh workspace docs after adding the sql crate。

目標

ルートおよびメンバーごとの CLAUDE.md ファイルを更新し、各ワークスペースメンバーに正確で自己完結したローカルガイダンスを用意するとともに、ルートの内容をプロジェクト全体に関わるものに絞ります。

ステップ 0：ワークスペースの範囲を特定し、モノレポの構成を確認する

次の項目を確認します。

• リポジトリが Cargo ワークスペースか、パッケージのモノレポか
• ユーザーが全体の更新を希望しているか、対象を絞ったメンバーの更新を希望しているか
• どのメンバーが存在し、どのメンバーに CLAUDE.md ファイルがすでにあるか
• どのルートレベルのメモリファイルとアーキテクチャルールがすでにあり、維持すべきか

次の項目については、references/workspace-discovery.md を読み込みます。

• ワークスペースの検出順序
• メンバーの一覧作成に関する要件
• エクスポート範囲、接続関係、依存関係のマッピングに関する調査ルール

次の場合は早期に中止します。

• ワークスペースの構成を特定できない
• 対象メンバーが曖昧すぎて、安全に更新できない

成功基準：調査を始める前に、ワークスペースの構成と更新範囲が明確になっていること。

ステップ 1：メンバー、公開範囲、接続関係を調査する

対象となる各メンバーについて、次の項目を一覧にします。

• 実際にエクスポートされている、またはアクセス可能な範囲
• 主要なソースファイル
• クレートのルート、パッケージのエントリーポイント、マニフェスト、バレルファイル、起動フック、レジストリ、ルーター、フィーチャーフラグなどの接続ファイル
• メンバー間の依存関係
• テスト、ベンチマーク、ランタイムのエントリーポイント
• 入手できる場合は、実際の利用側の使用パターン

ワークスペース全体で利用できる機能も一覧にします（これらはメンバーごとではなく、ルートファイルに記載します）。

• プロジェクトにコミットされたスキル（.claude/skills/）と有効な MCP サーバー（.mcp.json／ .claude/settings*.json）

ルール：

• pub や export の数だけで、実際の公開範囲を判断しないでください。
• まず、利用側が実際にアクセスできる範囲を確認してください。
• 推測ではなく、実際のインポート、再エクスポート、ランタイムの登録箇所を優先してください。
• 既存のメンバードキュメントが引き続き正確な場合は維持し、何も考えずに作り直すのではなく、内容を補足または明確化してください。

検出したモノレポの構成に該当する調査手順を完了するため、references/workspace-discovery.md を読み込みます。 スキル／MCP の調査元と秘匿化ルールについては、references/skills-and-mcp.md を読み込みます。

成功基準：プレースホルダーや、公開範囲に関する誤った記述を含めず、自己完結したメンバードキュメントを作成するために十分な具体的情報が揃っていること。

ステップ 2：メンバーごとの CLAUDE.md ファイルを更新する

対象範囲に含まれる各メンバーについて、以下を網羅した、焦点を絞ったローカルの CLAUDE.md を更新または作成します。

• 目的
• 公開またはエクスポートされるインターフェース
• 主要なファイル
• 依存関係
• 配線とエントリーポイント
• 使用パターン
• アーキテクチャに関する注記
• テストの指針

以下を読み込みます。

• 必須セクション、サイズ目標、検証ルールについては references/output-contract.md
• ライブラリまたはパッケージのメンバーについては references/package-template.md
• アプリ、バイナリ、またはエントリーポイントが中心となるメンバーについては references/app-template.md

作成ルール：

• プレースホルダーではなく、実際のワークスペースの例を使用します
• 繰り返しの多い文章より、表や箇条書きを優先します
• Claude の遅延読み込み動作に対応できるよう、各メンバーファイルを自己完結させます
• 将来の変更で動作を利用可能にするために必要となる、隠れた配線箇所を記載します

成功基準：対象となるすべてのメンバーに、正確で自己完結した CLAUDE.md があること。

ステップ 3：ルートの CLAUDE.md を簡潔にする

ルートファイルをプロジェクト全体の案内役として扱います。

• プロジェクト全体に適用されるルール、変更不可の決定事項、テスト方針、ワークスペースの構成を維持します
• メンバー固有の API 表やファイル一覧をルートから削除します
• ルートからメンバーごとのドキュメントへ明確に誘導し、内容を重複させないようにします
• ルートの CLAUDE.md に、簡潔な「利用可能なスキルと MCP — こちらを優先」セクションをインラインで含め、さらにファイルの先頭に 1 行の案内を追加します。今後のエージェントがリポジトリのスキルや MCP を忘れずに使えるようにしてください（常時読み込まれるテキストのみを使用し、遅延参照やメンバーごとの記載は使用しません）

ルール：

• ルートレベルのアーキテクチャ上の制約と方針決定を維持します
• 人が作成した有用な全体ルールを削除しないでください
• ルートをすべてのメンバーファイルの二重コピーにせず、メンバー固有の詳細は下位に移します

ルートファイルの要件と分量のルールについては references/output-contract.md を読み込みます。 「利用可能なスキルと MCP」セクションの形式と参照元については references/skills-and-mcp.md を読み込みます。

成功基準：ルートは薄くプロジェクト全体を対象とし、メンバー固有の詳細は Claude が遅延読み込みできる場所に置かれていること。

ステップ 4：網羅性、自己完結性、分量を検証する

完了を宣言する前に、更新内容を検証します。

• 対象範囲に含まれるすべてのメンバーに CLAUDE.md があること
• メンバーのドキュメントに、単なる可視性マーカーではなく、実際に利用可能なインターフェースが記載されていること
• 該当する場合、配線とエントリーポイントが記載されていること
• ルートでメンバー固有の詳細が過度に重複していないこと
• 行数が適切な範囲に収まっていること
• 更新後のドキュメントにより、実装エージェントが変更対象のメンバーで手当たり次第に検索せず作業できること

検証項目と分量の目標については references/output-contract.md を読み込みます。

検証に失敗した場合：

• 網羅性を高めます
• 欠けているセクションを復元します
• 重複した内容を整理します
• 古くなった到達可能性や配線に関する記述を修正します

成功基準：ワークスペースのメモリが簡潔で、メンバーごとに整理され、今後のエージェントにとって実際に役立つこと。

ステップ 5：変更内容を報告する

以下をまとめます。

• 検出したワークスペースの構成
• 更新したメンバー
• 作成または更新したファイル
• 網羅性やインベントリに関する主な内容
• 分量の状況
• 意図的に先送りしたメンバー、または対象範囲外のメンバー

ワークスペースが一部しか網羅されていない場合や、依頼された対象範囲から一部のメンバーが除外されている場合は、完全に更新できたと主張しないでください。

成功基準：ワークスペースのメモリをどのように更新し、その網羅度がどの程度かを、ユーザーが明確に把握できること。

ガードレール

• このスキルはプロアクティブに使用しないでください（永続的なプロジェクトメモリを変更します）。明示的なユーザーの意図がある場合、または明示的にユーザーが呼び出したワークフローがこのスキルを組み込んでいる場合（例：/ship-playbook）にのみ実行してください。disable-model-invocation ではなくなったため、ワークフローから呼び出すことはできますが、ユーザーに促されていない状態で実行してよいという意味ではありません。
• context: fork は追加しないでください。このワークフローはアクティブなリポジトリに書き込みます。
• paths: は追加しないでください。これは汎用のメンテナンススキルです。
• 古くなっている証拠がない限り、ルートレベルにある有用なプロジェクトルールを上書きしないでください。
• ワークスペースの検出マトリックス、テンプレートの百科事典、品質スコアカードを SKILL.md にインラインで記載しないでください。
• ルートの CLAUDE.md を肥大化させないでください。メンバーの詳細は下位に移してください。
• 自己完結性と到達可能性を検証せずに、更新が完了したと判断しないでください。

参照資料を読み込むタイミング

• references/workspace-discovery.md ワークスペースの検出順序、メンバーの検出ルール、エクスポートされたインターフェースと生の可視性に関する指針を確認する際に使用します。

• references/output-contract.md 必須のメンバー／ルートセクション、予算ルール、検証ゲートを確認する際に使用します。

• references/package-template.md ライブラリ形式のメンバーを更新する際に使用します。

• references/app-template.md バイナリ、アプリ、サーバー、またはエントリーポイントが多いメンバーを更新する際に使用します。

• references/skills-and-mcp.md リポジトリのプロジェクトスキルと MCP サーバーを見つけ、インラインの「利用可能なスキルと MCP — こちらを優先」セクションをルートの CLAUDE.md に反映する際に使用します。

出力契約

以下を報告します。

1. 検出したワークスペースの形状と対象範囲
2. 更新したメンバー
3. 作成または更新したファイル
4. 網羅性と自己完結性の概要
5. 予算と検証の結果
6. 保留または意図的にスキップしたメンバー