claude-memory

<core_principle> メモリファイルはコンテキストウィンドウのトークンを消費します。カスタマイズに使える指示スロットは約100～150個です。ファイルは最小限に抑え、エージェントが自力で把握できない情報だけを記載してください。

2つの方法：

• CLAUDE.md — 単一ファイル。小規模なプロジェクト（100行未満）に最適です
• .claude/rules/ — パス指定を任意で設定できるモジュール形式のファイル。大規模なプロジェクトに最適です </core_principle>

<quick_start> /init を実行して、CLAUDE.md を自動生成します。または、手動で作成します。

# Project Name

## Tech Stack
- [Primary framework]
- [Key non-obvious libraries]

## Commands
- `npm run dev` - Dev server
- `npm test` - Run tests
- `npm run build` - Build

## Rules
- [2-3 critical project-specific rules]

• セッション中に # を押すと、メモリ項目をすばやく追加できます
• /memory を使うと、エディターで CLAUDE.md を開けます </quick_start>

<file_hierarchy>

優先度	場所	適用範囲
1（最高）	エンタープライズポリシー（IT 管理）	組織内のすべてのユーザー
2	./CLAUDE.md または ./.claude/CLAUDE.md	git 経由でチームに適用
2	./.claude/rules/*.md	git 経由でチームに適用
3	~/.claude/CLAUDE.md	すべてのプロジェクト
3	~/.claude/rules/*.md	すべてのプロジェクト
4（最低）	./CLAUDE.local.md（自動的に gitignore に追加）	自分のみ

Claude は現在のディレクトリから上位へと再帰的にたどり、見つかったすべての CLAUDE.md ファイルを読み込みます。また、ディレクトリ内のファイルを読み込む際には、そのサブツリー内の CLAUDE.md も検出します。

モノレポの方針： ルートのファイルでは WHEN を、サブツリーのファイルでは HOW を定義します。

root/CLAUDE.md           # Universal: tech stack, git workflow
apps/web/CLAUDE.md       # Frontend-specific
apps/api/CLAUDE.md       # Backend-specific

</file_hierarchy>

<rules_directory> .claude/rules/ ディレクトリでは、指示を目的別の Markdown ファイルに分割できます。

.claude/rules/ を使う場合： 対象とする項目が多い、ファイルの種類ごとに異なるルールがある、チームが異なる領域を担当している場合。 CLAUDE.md を使う場合： 小規模なプロジェクト、共通のルール、単一の信頼できる情報源が必要な場合。

パスを指定するルールには YAML のフロントマターを使います。

---
paths:
  - "src/api/**/*.ts"
---
# API Rules
- All endpoints must include input validation

対応パターン：**/*.ts、src/**/*、src/**/*.{ts,tsx}、{src,lib}/**/*.ts

paths フロントマターがないルールは、常に読み込まれます。

シンボリックリンク、ユーザーレベルのルール、移行方法を含む完全なガイドについては、references/rules-directory-guide.md を参照してください。 </rules_directory>

<content_structure> CLAUDE.md は、次のセクションだけで構成してください。

1. プロジェクトの目的（1～3行）— プロジェクトの内容
2. 技術スタック（簡潔に）— 自明でない技術のみ
3. コマンド — 自明でない開発、ビルド、テストのコマンド
4. 重要なファイル — アーキテクチャ上重要で、自明でないファイルのみ
5. ルール — ミスを防ぐ禁止事項と制約（最も価値の高い項目）
6. ワークフロー（任意）— 標準的でない場合のみ

次の内容は含めないでください：

• リポジトリの概要（エージェントは構造を自分で把握できます）
• コードスタイルのルール（リンターで適用します）
• 一般的なベストプラクティス（「クリーンなコードを書く」「DRY」「SOLID」など）
• 冗長な仕様（設定ファイル、環境変数、スキーマの説明のコピー）
• マーケティングや目標（ビジョン、KPI、ロードマップ）
• 冗長な説明（1行で済む内容を段落で説明すること）

すぐに使えるテンプレートについては、references/section-templates.md を参照してください。 フレームワーク固有のパターンについては、references/project-patterns.md を参照してください。 </content_structure>

<writing_rules> 基本原則： プロジェクトの予備知識がまったくない人が CLAUDE.md を読んで混乱するなら、Claude も混乱します。

曖昧にせず、具体的に書いてください：

❌ "Format code properly" / "Write good tests" / "Follow best practices"
✅ "Run `pnpm lint` before committing" / "Tests in `__tests__/` using Vitest"

肯定的な指針より禁止事項を優先してください：

❌ "Try to use TanStack Form for forms"
✅ "NEVER use native form/useState for forms — ALWAYS use TanStack Form"

説明するより、例を示してください： 形式が重要な場合は、具体例を示します（最大3～5行）。

強調の優先順位： CRITICAL > NEVER > ALWAYS > IMPORTANT > YOU MUST

• 各セクションでは、重要なルールを最初に置きます
• 交渉の余地がないルールには、**CRITICAL**: Never commit secrets のように 太字とキーワードを使います

高度なテクニックについては、references/prompting-techniques.md を参照してください。 </writing_rules>

<size_limits>

• 理想： 100行未満
• 最大： パフォーマンスが低下する前の150行
• 200行超： 指示が抜け落ち始めます

制限を超える場合は、.claude/rules/ のファイルに分割するか、別のドキュメントへのリンクを記載してください。

- **API patterns**: See [docs/api-patterns.md](docs/api-patterns.md)
- **Testing guide**: See [docs/testing-guide.md](docs/testing-guide.md)

CLAUDE.md はインポートに対応しています：@docs/coding-standards.md（相対パス／絶対パス、~ の展開、最大 5 階層まで、コードブロック内では評価されません）。 </size_limits>

**必ず最初に確認する：ストレージ戦略**

メモリファイルを作成または更新する前に、AskUserQuestion を使用します：

• オプション 1：単一の CLAUDE.md — 100 行未満のシンプルなプロジェクトで、汎用的なルールを適用する場合
• オプション 2：モジュール化された .claude/rules/ — 100 行以上のプロジェクトで、ファイルごとに異なるルールを適用する場合

新しいメモリの作成：

1. /init または最小限のテンプレートから始めます
2. まず技術スタックとコマンドを追加します
3. 問題が発生したときにのみルールを追加します
4. 実際のタスクでテストし、Claude の動作に応じて反復します

メンテナンス：

1. 四半期ごと、またはプロジェクトに大きな変更があったときに見直します
2. 古くなった指示を削除します
3. 繰り返し説明が必要だったパターンを追加します
4. 作業中にすばやく追加するには # を使用します

トラブルシューティング：

問題	解決策
Claude が指示を無視する	ファイルサイズを小さくし、強調表現（CRITICAL、NEVER）を追加します
コンテキストのオーバーフロー	/clear を使用し、.claude/rules/ に分割します
指示が競合する	統合し、階層（ルートとサブツリー）を使用します
パスルールが適用されない	glob パターンが対象ファイルに一致することを確認します

<init_workflow>

/claude-memory init — 最小限の CLAUDE.md を作成

ユーザー引数に「init」が含まれる場合、このワークフローを実行して、必要最小限のセクションだけを含む CLAUDE.md を用意します。

ステップ 1：プロジェクトのコンテキストを検出

package.json（または pyproject.toml、Cargo.toml、go.mod などの同等ファイル）を読み取り、以下を検出します：

• プロジェクト名
• 技術スタック（フレームワーク、言語）
• 利用可能なスクリプト／コマンド（dev、build、test）

既存のリンター設定（ESLint、Biome、Prettier、tsconfig）も確認し、すでに適用されているルールは含めないでください。

ステップ 2：重要なファイルを特定

見つけにくい、アーキテクチャ上重要なファイルをスキャンします。以下を確認してください：

• 認証設定ファイル
• サーバーアクションのラッパー、API ヘルパー
• データベースのスキーマファイル
• カスタムミドルウェアや共有ユーティリティ
• 標準的なフレームワークファイル（package.json、tsconfig、next.config など）は除外します

ステップ 3：CLAUDE.md を生成

以下のセクションのみを含むファイルを作成します。各セクションは簡潔にし、ファイル全体を 50 行未満にしてください。

# [Project Name]
[One-line description of what this project is]

## Tech Stack
- [Only non-obvious technologies — skip deps detectable from config files]

## Commands
- `[dev command]` - Dev server
- `[build command]` - Build
- `[test command]` - Tests
- [Any non-obvious commands like db:push, seed, etc.]

## Important Files
- [Only files the agent wouldn't discover naturally]

## Rules
- [Leave empty with a comment: "Add project-specific rules as you encounter friction"]

ステップ 4：提示して書き込む

生成したファイルをユーザーに提示します。承認を得てから ./CLAUDE.md に書き込みます。

ルール：

• ディレクトリ構造、コードスタイルのルール、一般的なベストプラクティス、マーケティング文は絶対に含めないでください
• リンターや TypeScript がすでに適用している内容は絶対に含めないでください
• 目標は 20～50 行です。これを超える場合は、含めすぎています
• Rules セクションは空のままにします。ミスが発生したときに、時間をかけて内容を追加していきます </init_workflow>

<optimize_workflow>

/claude-memory optimize — CLAUDE.md の徹底的な整理

ユーザー引数に「optimize」が含まれる場合、このワークフローを実行します。

重要 — ステップ 0 は必須です。絶対に省略しないでください。最初にガイドを読まずに最適化を始めないでください。

ステップ 0：最適化ガイドを読む（最初に必ず実行）

ほかの作業を始める前に、必ず {SKILL_PATH}/references/optimize-guide.md に対して Read ツールを使用してください。 このファイルには、調査データ（ETH Zurich の研究）、具体例を含む 6 つの肥大化カテゴリ、目標指標、変更前後の例が記載されています。これを読まないと、削除基準を見落とし、最適化の品質が低下します。

ステップ 1：一覧を作成

プロジェクト内のすべての CLAUDE.md、CLAUDE.local.md、.claude/rules/*.md を読み取ります。総行数を数えます。

ステップ 2：リンター設定を読む

ESLint／Biome／Prettier／TypeScript の設定を読み取ります。適用済みのルールと重複する CLAUDE.md の行は削除します。

### Step 3: ガイドにある6つの冗長カテゴリを適用する

各行について、「エージェントがプロジェクトを読み取れば把握できるか、またはリンターが強制する内容か」と確認します。該当する場合は削除します。

以下に該当する内容をすべて削除します。

1. リンターが強制するルール（ESLint、Prettier、Biome、TypeScript strict）
2. マーケティング／目標／ビジョン（コード上の価値がないもの）
3. エージェントが自分で把握できる明白な情報（ディレクトリ構成、フレームワークのデフォルト設定、package.json に記載された依存関係）
4. 冗長な説明（1行で十分な段落、チュートリアル、歴史）
5. 重複した仕様（設定ファイルのコピー、スキーマの説明、環境変数の一覧）
6. 一般的なベストプラクティス（「クリーンなコードを書く」、「DRY」、「SOLID」）

Step 4: 必須事項だけを残す

• プロジェクトの目的（1～3行）
• 技術スタック（簡潔に、明白でないもののみ）
• 主要なコマンド（明白でないもののみ）
• テストコマンド
• 重要なファイル（明白でないもののみ）
• プロジェクト固有のルール（禁止事項と制約）
• ワークフロー（標準と異なる場合のみ）

Step 5: 簡潔にする

• 段落 → 箇条書き
• 3行のルール → 1行のルール
• 埋め草の言葉をなくす（「〜するために」、「なお重要なのは」など）
• 関連する項目をまとめる

Step 6: 差分を提示する

変更前と変更後を行数とともに表示します。削除項目ごとに、該当する冗長カテゴリを示します。 変更を適用する前に、ユーザーの承認を得てください。

目標： 100行未満が理想、最大150行 </optimize_workflow>

<reference_guides>

• 最適化ガイド：references/optimize-guide.md — 調査に基づく冗長性チェックリスト、6つの削除カテゴリ、変更前／変更後の例
• ルールディレクトリ：references/rules-directory-guide.md — パススコープ、YAML 構文、シンボリックリンク、移行を含む .claude/rules/ の完全ガイド
• プロンプト技法：references/prompting-techniques.md — 強調方法、明確化の技法、制約パターン
• セクションテンプレート：references/section-templates.md — 各セクションタイプ向けのコピー＆ペースト用テンプレート
• 包括的な例：references/comprehensive-example.md — 本番環境向け SaaS CLAUDE.md の完全な例
• プロジェクトパターン：references/project-patterns.md — Next.js、Express、Python、モノレポのパターン </reference_guides>