rules-create-global

ルールの作成：プロジェクト全体のルールを設定する

入力：まず引数を確認する

このスキルは最大2つの任意のパスを受け取り、それを使って進め方を決めます。渡されたパスがあれば内容を確認し、それぞれを分類してください。

• $path1：最初のパス（指定されている場合）。
• $path2：2番目のパス（指定されている場合）。

渡されたパスの内容	進め方	用途
PRD（意図、何を／なぜ、plan-create-prd からのもの）	グリーンフィールド	プロダクトの背景情報（「これは何か」）。技術的なルールの根拠にはしません
アーキテクチャ／仕様書（方法、plan-architecture からのもの）	グリーンフィールド	ルールの根拠となる技術的な決定事項（アーキテクチャが ## Architecture セクションにまとめられている場合は、PRD と同じファイルでもかまいません）
コードベース分析ドキュメント（大規模リポジトリを対象とした /prime-codebase とサブエージェントへの作業分担によるもの）	ブラウンフィールド	「現状」の根拠

渡された内容に基づいて進め方を選びます。

• グリーンフィールド：PRD またはアーキテクチャのパスが渡された場合、あるいはワークスペースが空のひな形の場合。アーキテクチャ上の決定事項（$path2、またはそこに記載されている場合は $path1）をもとに、「こうあるべき」という姿を導き出します。
• ブラウンフィールド：パスが渡されていない場合、またはコードベース分析のパスが渡された場合。分析ドキュメントが渡されていればそこから、そうでなければこの会話で事前調査済みのコードベースから「現状」を導き出します。

ブラウンフィールドで、まだ事前調査をしていない場合：パスが渡されておらず、この会話でコードを事前調査していないなら、まず /prime-codebase を実行する（または実行を提案する）ことで、実際のファイルに基づいてルールを導き出してから先に進んでください。根拠のないルールを決して作らないでください。

グローバルルールとは（30秒でわかる概要）

グローバルルール（Claude ネイティブの CLAUDE.md またはツール間で使えるオープンスタンダードの AGENTS.md）は、すべてのタスクで読み込まれる常時適用の指針ドキュメントです。常時適用する価値がある内容は、次の4種類です。

1. コードベースの案内図 — 重要なディレクトリやファイルと、それぞれが「何であり、なぜそこにあるのか」を1行で説明します。
2. 基本ルール — このプロジェクトが採用する具体的な規約（型安全性の確保方法、エラーに対する考え方、Git のワークフローなど）です。スローガンではなく、選択した内容を明記します。
3. エージェント自身が実行するコマンド — エージェントが自分の作業を確認できるよう、実際の lint／型チェック／テスト／ツールの CLI とそのフラグを記載します。（スラッシュコマンドではありません。それらはスキルです。）
4. 作業の原則（エージェントへの指針） — エージェントにここでどのように動作してほしいかを示します。考え方や推論の姿勢（重要な作業の前に計画する、曖昧な場合は推測せず確認する、範囲を絞る）と、重視するエンジニアリングの基本（早期に失敗させる、エラーを明示する、単一責任、機能する最もシンプルな方法）です。**これらはコードには含まれません。自分で記述する必要があります。**コードベースの分析だけでは決して導き出せない内容であり、明示しない限りエージェントが一貫して従うとは限らない部分です。

すべては組み合わせて構成できます。ルール、参照資料、スキルはいずれも、必要に応じてエージェントが読み込む Markdown です。上記の内容は常時適用にすることも、オンデマンドの references/ ドキュメントやスキルに置くこともできます。それぞれの配置を選んでください。すべてのタスクで必要ではないものは必要に応じて読み込むか、タスクごとの計画に含めます。ここには含めません。

2 つの状況、1 つの目的

グローバルルールは技術的な真実を表すため、プロダクト仕様ではなく技術的な決定から導き出します。

状況	ルールの導出元	「真実」とは
グリーンフィールド。新規プロジェクトで、ほとんどがひな型の場合	AI と合意した技術的な「方法」である、あなたのアーキテクチャ上の決定（$path2 として渡します）	あるべき姿
ブラウンフィールド。AI レイヤーのない既存のコードベースの場合	事前に把握したコードベース（/prime-codebase）、または大規模リポジトリ向けにパスとして渡すコードベース分析ドキュメント	現状

グリーンフィールドの場合：ルールは PRD ではなく、あなたのアーキテクチャ上の決定（仕様）から導き出します。手順は次のとおりです。AI と構築するものについて話し合い、その内容を PRD（plan-create-prd）として記録します。次に plan-architecture でアーキテクチャ（スタック、パターン、ディレクトリ構成、規約）を確定します。このスキルがルールを導き出すのは、そうした決定からです。PRD が記録するのはプロダクト（何を、なぜ）です。有用なコンテキストではありますが、技術ルールはそこにはありません。

ブラウンフィールドの場合：このスキルがコードベースを調査することはありません。まず、/prime-codebase を実行して、構造、主要ファイル、規約をこの会話に読み込ませてから、パスを指定せずにこのスキルを実行します。（大規模なリポジトリの場合は、組み込みのサブエージェントをいくつか並行して実行し、各領域を調査してもかまいません。短い codebase-analysis.md に結果をまとめ、そのパスを渡します。）このスキルがまとめるのは、導出 → 抽出 → 境界の特定 → 削除 → 確認の手順であり、調査そのものではありません。

実行する前に、既存のルールを保護してください。プロジェクトに既存の CLAUDE.md／AGENTS.md がある場合、このスキルが残しておきたい内容を上書きしないよう、まずコピーするか名前を変更してください（例：CLAUDE.md.bak）。さらによい方法は、入力として渡すことです。スキルに（「既存の CLAUDE.md を先に読んでください」と）指示すれば、最初からやり直すのではなく、既存の内容を踏まえて導出できます。

必読（最初に実行）— 使用するファイルを選択

**まず、このプロジェクトではどのルールファイルを使用していますか？**該当するファイルを特定し、対応するガイダンスを読んでください（スナップショットに頼らないでください）。

• CLAUDE.md（Claude Code のネイティブファイル）→ Anthropic のメモリとベストプラクティス： https://code.claude.com/docs/en/memory · https://code.claude.com/docs/en/best-practices
• AGENTS.md（数十種類のエージェントが読み込む、ツール間で共通のオープン標準）→ AGENTS.md の仕様：https://agents.md
• 両方ある場合：通常、共通の内容は AGENTS.md にあり、CLAUDE.md は 1 行の @AGENTS.md だけです。これにより Claude Code は AGENTS.md を自動で読み込み、信頼できる情報源が 1 つになります。この場合は、AGENTS.md に書き込みます。
• どちらもまだない場合：Claude Code 専用のプロジェクトなら CLAUDE.md、チームで複数のツールを使うなら AGENTS.md を使用します。

どちらを使っても、内容と構成は約 90％同じです。以下はベンダー固有のものではなく、**「あなたのルールファイル」**に関する内容です。 以下に示す構成を使ってください（AGENTS.md にも同様に適用できます）。

手法（これを組み込む）

• 常時有効にするもの： マップ＋基本ルール（具体的な規約）＋作業原則 （エージェントの指針）。プロジェクト全体、すべてのタスクに当てはまる内容です。
• 作業原則は導き出すのではなく、引き出します。 マップと基本ルールはコードや決定事項から導き出しますが、作業原則はあなたが決めるものです。だから、次のように尋ねてください。「ここではエージェントにどう作業してほしいですか？ まず計画を立てる？ コーディング前に確認する？ スコープを厳守する？ どのようなエンジニアリングの基本原則を重視していますか？」実際に振る舞いを変えるもの、そしてあなたの考えを反映するものだけを残してください。モデルがすでに従っている一般論は含めません。
• 4つの配置先 — 候補となる記述をすべて分類します。
  • 常時有効にする → マップ／基本ルール。
  • 必要に応じて参照する場所へ移す → 繰り返し登場するが、タスクの種類に固有のパターン → 必要に応じて参照するドキュメント （Claude Code では .claude/references/<topic>.md。使用するツールが参照する場所ならどこでも構いません。例：.agent/。通常の Markdown です）またはスキル。
  • 計画に移す → 次に何を作るかというタスク固有の内容 → そもそもルールではありません。
  • 削除する → 重複しているもの、またはモデルがすでに従うスローガン（「きれいなコードを書く」「KISS/DRY」）。
• スローガンではなく、選択した内容を書く： 「型は z.infer から導出する」とし、「型安全性は非常に重要」とは書きません。
• 既存のコードベースでは「現状」を書き、「あるべき姿」は書かない： すべてのルールについて、それを裏付けるファイルを示してください。示せない場合は記載しません。願望に基づくルールは、エージェントをコードベースと衝突させます。
• 簡潔に保つ： コンテキストを圧迫したり、エージェントが自らのルールを無視し始めたりするほど膨らませないでください。行数に決まった基準はありません。削除しても間違いにつながらない記述はすべて削ってください。

ワークフロー

1. 入力を読む

• グリーンフィールド： $path2（アーキテクチャが記載されている場所が $path1 ならそちら）として渡されたアーキテクチャ／仕様書を読みます。技術スタック、パターン、ディレクトリ構成、規約、セキュリティ上の選択、およびスキャフォールドのファイルを確認します。（$path1 として渡された PRD は製品の背景情報です。何を、なぜ作るのかを把握するために読み、技術ルールの根拠にはしません。） パスが渡されておらず、ワークスペースが新しいスキャフォールドの場合は、アーキテクチャ文書を求めるか、まず plan-architecture を使って決定を固めます。
• 既存のコードベース： この会話ですでに読み込まれている準備済みのコードベース（/prime-codebase による）から導き出すか、codebase-analysis.md のパスが渡されている場合は、ファイルと行の引用を含むそのファイルを読みます。どちらの場合も、実際のコードを抜き取り確認します。準備済みのコードベースがなく、パスも渡されていない場合は、まず /prime-codebase を実行します。
• ルールファイルがすでに存在する場合： まずそれを読み、出発点として扱います。また、手作業で書かれた内容を失わないよう、必ずバックアップを取ってください（上記の「既存のルールを保護する」を参照）。
• 上記のベストプラクティス文書を読みます。このスキルで定められた構成に従ってください。

2. ルートの CLAUDE.md を導き出す

入力をもとに、テンプレートの各セクションを埋めます。

• これは何か — 1段落と、技術スタックを1行で記載します。
• アーキテクチャマップ — 重要なディレクトリ／ファイルのツリーを作り、それぞれの役割や目的を1行で説明します。
• 基本ルール — 具体的な規約を記載します（グリーンフィールド：PRD ではなくアーキテクチャ仕様で決定した内容。既存のコードベース：コードで確認できる内容。それぞれファイルを根拠として示します）。
• 作業原則（エージェントの指針） — コードからは導き出せないため、ユーザーに尋ねます。エージェントにどのように動いてほしいかを確認します。思考や推論の進め方（まず計画を立てる、推測せずに確認する、スコープを厳守する、実際のテストスイートで検証する）と、重視するエンジニアリングの基本原則（早期に失敗させる、エラーを明示する、単一責任、動作する最もシンプルな方法）を記録します。プロジェクトの実際の方針を明記し、簡潔に保ちます。
• コマンド — 実際に使うものをいくつか記載します（インストール／テスト／型チェック／リント／実行）。
• 必要に応じて参照する場所 — 必要なときに詳細を読み込む場所を示します。 PRD や分析内容をそのまま書き込まないでください。それらへのリンクを記載します。

3. 必要に応じてコンテキストを抽出する

繰り返し使うタスク種別固有のパターンを .claude/references/<topic>.md のスタブ（それぞれ1段落。完全なドキュメントにはしません）に切り出します。判断基準：その領域に触れるたびに繰り返し使いますか？ → ガイドにします。1回限りの情報 → 元のドキュメントに残します。

4. 接続点を見つける

新しい作業をつなぎ込むインターフェースやフォルダーを示す、短い**「新しいコードの配置場所」**セクションを追加します。これにより、エージェントはコードベースに機能を付け足すのではなく、拡張できるようになります。（グリーンフィールドの場合、接続点は発見するのではなく、アーキテクチャに基づいて設計します。）

5. 必要最低限まで削る

最初の草稿は、必ず大きくなりすぎます。一般的なアドバイス、既定の内容を言い換えただけのもの、根拠を示せないものを削除します。行ごとに確認します：これを削除すると間違いが起きますか？ 起きないなら、削除します。

6. 報告する

• 作成・変更したファイル。
• CLAUDE.md に何を記載したか、その理由を3～5行でまとめます。
• オンデマンドのコンテキストに移した内容と、その保存場所。
• 次のステップ：ルールの準備ができたら、最初のPIVループを開始します。

品質チェック

• ✅ ルートの CLAUDE.md はマップと基本ルールであり、ドキュメントやPRD／分析のコピーではありません。
• ✅ すべての基本ルールが具体的な選択です（ブラウンフィールドの場合は、ファイルまで追跡できます）。スローガンは含めません。
• ✅ 作業原則／エージェントの誘導セクションがあります。内容はユーザーから引き出したもの（計画／明確化／スコープに対する姿勢＋エンジニアリングの基本要素）で、簡潔かつ行動を変えるものであり、一般論で埋めません。
• ✅ 繰り返し使うタスク種別固有の詳細は、常時読み込むのではなく .claude/references/ に置かれています。
• ✅ 何もがその場所を占める価値に見合うだけの役割を果たさない限り、掲載されない程度に簡潔です。

メモ

• ルールは進化します。プロジェクトの成長に合わせて、また主要なモデルのリリース後に CLAUDE.md を見直し、マップが現状とずれないよう、マージ前に /rules-check-drift を実行します。
• グリーンフィールドの場合、plan-architecture でアーキテクチャを確定した後（製品のPRDを作成した場合は plan-create-prd の後も）に実行します。パスを $path1（PRD）、$path2（アーキテクチャ）として渡します。ブラウンフィールドの場合は、/prime-codebase の後、または大規模リポジトリのファンアウト分析によって codebase-analysis.md が生成され、それを渡した後に実行します。