map-project

このスキルは、永続的なプロジェクトメモリを変更します。以下のルールは必ず守ってください。 1. 何かを書く前に、実際のフレームワーク構成を特定します。 2. `CLAUDE.md` やリファレンスドキュメントを更新する前に、実際のコードベースを調査します。 3. 既存のプロジェクトドキュメントを全面的に置き換えるのではなく、更新することを優先します。 4. 生成するメモリは、Claude のコンテキスト予算内で有用な状態を保てるよう、簡潔にします。 5. このスキルを自発的に実行してはいけません（永続的なプロジェクトメモリを変更するためです）。明示的にユーザーから依頼された場合、または明示的にユーザーが実行したワークフローに含まれる場合（例：ビルド後にマップを更新する `/ship-playbook`）に限り実行します。

プロジェクトのマップを作成する

入力

• $request：対象範囲や更新内容に関する任意のメモ。例：api only、after auth refactor、update the docs for the Next.js app。

目標

CLAUDE.md とインポートされたリファレンスドキュメントを更新し、古くなった汎用的なパターンや不完全なパターンではなく、実際のプロジェクトの内容が反映されるようにします。

ステップ 0：対象範囲を決め、プロジェクト構成を特定する

以下を判断します。

• ユーザーが全体の更新を求めているのか、範囲を限定した更新を求めているのか
• 主要なフレームワークまたはプロジェクト構成として、現在どれが使われているか
• リポジトリが単一のアプリなのか、主要なアプリの機能領域を 1 つ持つモノレポなのか
• 既存のメモリファイルのうち、新規作成ではなく更新すべきものはどれか

references/framework-discovery.md を読み、以下を確認します。

• フレームワークの特定手順
• フレームワーク固有の調査要件
• インベントリの要件

次の場合は、早い段階で処理を中止します。

• リポジトリの構成を特定できない場合
• どのメモリファイルを更新すべきか判断できるほど、依頼の対象範囲が明確でない場合

成功基準：調査を始める前に、プロジェクトの構成とドキュメントの対象範囲が明確になっていること。

ステップ 1：書き込み前に徹底的な調査を行う

プロジェクトに適した方法で、実際のコードベースを調査してインベントリを作成します。

• ルート、画面、またはハンドラー
• エクスポート、モデル、サービス、フック、モジュール、パッケージ
• 状態を持つエンティティとライフサイクルのフロー
• API ルート、CLI のエントリーポイント、パッケージのエクスポートなどの公開インターフェース
• 主要なサブシステムとその統合境界
• リポジトリ自体が提供する機能：プロジェクトにコミットされたスキル（.claude/skills/）と有効な MCP サーバー（.mcp.json / .claude/settings*.json）

ルール：

• メモリや古いドキュメントを鵜呑みにせず、コードで確認します。
• リファレンスの要件で網羅性が求められる箇所は、件数を収集します。
• ガイドの根拠となる実際の実装例を検索します。
• リポジトリに既存のドキュメントがある程度ある場合は、やみくもに書き換えず、検証して拡充します。

references/framework-discovery.md を読み、特定したプロジェクト構成に応じた調査手順を完了します。 references/skills-and-mcp.md を読み、スキル／MCP の調査元と秘匿情報のマスキングルールを確認します。

成功基準：プレースホルダーや推測に頼らずプロジェクトを記述できるだけの、具体的なインベントリが揃っていること。

ステップ 2：まずリファレンスファイルを更新する

調査結果に基づいて、インポートされたリファレンスファイルを更新または作成します。

• エクスポートまたは API インターフェースのリファレンス
• 開発ガイド
• アーキテクチャのリファレンス

references/output-contract.md を読み、以下を確認します。

• 必須ファイル
• ファイルごとに必須のセクション
• フレームワーク固有のセクション要件
• 行数の目安

執筆ルール：

• 汎用テンプレートではなく、実際のプロジェクトの例を使います。
• 繰り返しの多い文章より、簡潔な表を優先します。
• 実装時にエージェントが実際に必要とするパターンを記述します。
• 各ファイルの対象を絞り、同じ内容を複数のファイルに重複して記載しないようにします。

成功基準：リファレンスファイルに実際のコードベースが反映され、役立つ分量に収まっていること。

ステップ 3：薄いエントリーポイントとして CLAUDE.md を更新する

CLAUDE.md は簡潔なルーターとして扱います。

• 詳細なリファレンスファイルをインポートする
• 要点を絞ったクイックリファレンスとプロジェクトレベルのガイダンスだけをインラインに残す
• インポートしたファイルに移した大きな表や手順ガイドを重複させない
• 簡潔なインラインの「Available Skills & MCP — prefer these」セクションを含め、さらに CLAUDE.md の最上部に一行のポインターを記載して、将来のエージェントがリポジトリのスキルと MCP サーバーを使い、存在を忘れないようにする — 動作を変えるのは常に読み込まれるテキストだけなので、この内容はインポートするリファレンスではなく、CLAUDE.md 自体に記載します

ルール：

• 発見によって古い、または誤りだと判明しない限り、既存のチェックイン済みプロジェクトガイダンスを維持する
• 生成された構造に含まれないという理由だけで、役立つ人間が作成した規約を削除しない
• クイックリファレンスを、エージェントが適切なインポート済みファイルを選べるよう実際に役立つものにする

期待される CLAUDE.md の形式については、references/output-contract.md を読み込んでください。 「Available Skills & MCP」セクションの形式と発見元については、references/skills-and-mcp.md を読み込んでください。

成功基準：CLAUDE.md が、更新されたプロジェクトメモリへの簡潔で正確なエントリーポイントになること。

ステップ 4：網羅性、予算、有用性を検証する

完了を宣言する前に、更新内容を検証してください。

• 必須ファイルが存在する
• 必須セクションが含まれている
• 選択したプロジェクト構成に対して、文書化された網羅性が十分に高い
• 行数の予算が妥当な範囲に収まっている
• CLAUDE.md とインポート済みファイルの間に明らかな重複がない
• 実装エージェントが、更新されたドキュメントからルート、エクスポート、ワークフローのガイダンスを見つけられる

検証ゲートと予算ルールについては、references/output-contract.md を読み込んでください。

検証に失敗した場合：

• ドキュメントを簡潔にする
• 不足しているセクションを復元する
• 重複を削除する
• 発見時に作成したインベントリを使って網羅性を改善する

成功基準：更新されたメモリが簡潔で、根拠に基づき、将来のエージェントにとって本当に役立つこと。

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

以下を要約してください。

• 検出したプロジェクト構成
• 作成または更新したファイル
• 網羅性やインベントリの主な内容
• 予算の状況
• 意図的に文書化を見送った、または先送りした領域

リポジトリに大きな盲点がある場合や、複数フレームワークの複雑さを意図的に対象外とした場合は、完全な更新ができたと主張しないでください。

成功基準：ユーザーが、どのプロジェクトメモリを更新したのか、またその網羅性がどの程度かを明確に把握できること。

ガードレール

• このスキルを先回りして使わないでください（永続的なプロジェクトメモリを変更します）。明示的なユーザーの意図がある場合、または明示的にユーザーが呼び出したワークフロー（例：/ship-playbook）に組み込まれている場合にのみ実行してください。これは disable-model-invocation ではなくなったため、ワークフローから呼び出すことはできますが、それをユーザーに促されていないのに実行してよいという意味ではありません。
• context: fork を追加しないでください。このワークフローはアクティブなリポジトリに書き込みます。
• paths: を追加しないでください。これは汎用的なメンテナンススキルです。
• 古いという根拠がない限り、役立つ人間が作成したプロジェクトルールを上書きしないでください。
• フレームワーク発見マトリクスやファイル契約の百科事典を SKILL.md にインラインで残さないでください。
• CLAUDE.md を肥大化させないでください。詳細はインポートするリファレンスに記載してください。
• 検証せずに更新完了としないでください。

リファレンスを読み込むタイミング

• references/framework-discovery.md フレームワークの検出順序、フレームワーク固有の発見手順、インベントリに求められる内容に使用します。

• references/output-contract.md 必須の出力ファイル、必須セクション、行数の予算、検証ルールに使用します。

• references/skills-and-mcp.md リポジトリのプロジェクトスキルと MCP サーバーを発見し、インラインの「Available Skills & MCP — prefer these」セクションを CLAUDE.md に記載するために使用します。

出力仕様

以下を報告してください。

1. 検出したプロジェクト構成と対象範囲
2. 作成または更新したファイル
3. 網羅性またはインベントリの概要
4. 予算と検証結果
5. 先送りまたは意図的に省略した領域