Memory.md Management

プロジェクトメモリファイルの包括的な管理機能を提供します。監査、品質評価、および対象の改善を含みます。このスキルは、CLAUDE.md などの高品質なドキュメントファイルを維持することで、コーディングエージェントが最適なプロジェクトコンテキストを持つようにします。

概要

CLAUDE.md などのプロジェクトメモリファイルは、コーディングエージェントセッションにプロジェクト固有のコンテキストを提供するための主要なメカニズムです。このスキルはそのライフサイクル全体を管理します：発見、品質評価、レポート出力、改善。5段階のワークフローに従い、ドキュメントが最新で実行可能で簡潔であることを保証します。

このスキルは CLAUDE.md ファイルを 6 つの側面に基づいて標準化された品質基準に対して評価します：コマンド/ワークフロー、アーキテクチャの明確性、非自明なパターン、簡潔性、最新性、実行可能性。各ファイルはスコア（0-100）と成績（A-F）、および具体的な改善推奨事項を受け取ります。

使用時機

以下の場合にこのスキルを使用します：

• ユーザーが「チェック」「監査」「更新」「改善」「修正」または「保守」を明示的に指示している
• ユーザーが「CLAUDE.md の品質」「ドキュメントレビュー」または「プロジェクトメモリ最適化」について言及している
• 新しいプロジェクトのためにプロジェクトメモリファイルをゼロから作成する必要がある
• ユーザーが Claude のコードベース理解の向上について尋ねている
• ドキュメントが古いまたは時代遅れになっている
• 新しいコードベースで作業を開始し、既存のドキュメントを理解する必要がある
• ユーザーがセッション中に # を押してメモリファイルに学習を組み込む

トリガーフレーズ： 「audit CLAUDE.md」「documentation quality を確認」「improve project context」「review CLAUDE.md」「validate documentation」

指示

Phase 1: 発見

リポジトリ内のすべての CLAUDE.md ファイルを見つけます：

find . -name "CLAUDE.md" -o -name ".claude.md" -o -name ".claude.local.md" 2>/dev/null | head -50

ファイルタイプと場所：

タイプ	場所	目的
プロジェクトルート	./CLAUDE.md	プライマリプロジェクトコンテキスト（git にチェックイン、チーム共有）
ローカルオーバーライド	./.claude.local.md	個人/ローカル設定（gitignore 対象、非共有）
グローバルデフォルト	~/.claude/CLAUDE.md	全プロジェクト共通のユーザーワイドデフォルト
パッケージ固有	./packages/*/CLAUDE.md	モノレポ内のモジュールレベルコンテキスト
サブディレクトリ	ネストされた任意の場所	機能/ドメイン固有のコンテキスト

Phase 2: 品質評価

各 CLAUDE.md ファイルについて、references/quality-criteria.md を読み、以下の基準に対して評価します：

基準	配点	チェック項目
コマンド/ワークフロー	20点	ビルド/テスト/デプロイコマンドが存在し機能しているか？
アーキテクチャの明確性	20点	Claude がコードベース構造を理解できるか？
非自明なパターン	15点	落とし穴と独特な点が記載されているか？
簡潔性	15点	コンテンツが詰まっていて無駄がないか？
最新性	15点	現在のコードベース状態を反映しているか？
実行可能性	15点	指示が実行可能でコピー＆ペースト可能か？

品質スコア： A（90-100）、B（70-89）、C（50-69）、D（30-49）、F（0-29）

Phase 3: 品質レポート出力

重要：更新を行う前に、常に品質レポートを出力してください。

フォーマット：

## CLAUDE.md Quality Report

### Summary
- Files found: X
- Average score: X/100
- Files needing update: X

### File-by-File Assessment
#### 1. ./CLAUDE.md (Project Root)
**Score: XX/100 (Grade: X)**

| Criterion | Score | Notes |
|-----------|-------|-------|
| Commands/workflows | X/20 | ... |
| Architecture clarity | X/20 | ... |
| Non-obvious patterns | X/15 | ... |
| Conciseness | X/15 | ... |
| Currency | X/15 | ... |
| Actionability | X/15 | ... |

**Issues:**
- [具体的な問題をリスト]

**Recommended additions:**
- [追加すべき内容をリスト]

Phase 4: 対象的な更新

レポート出力後、更新前にユーザーに確認を求めます。

詳細な更新原則については references/update-guidelines.md を読んでください。

主要な原則：

1. 対象的な追加のみを提案 - コマンド、落とし穴、パターン、設定
2. 最小限に保つ - 明らかな情報、一般的なアドバイス、一度限りの修正は避ける
3. diff を表示 - ファイル、変更（diff フォーマット）、説明

Diff フォーマット：

### Update: ./CLAUDE.md
**Why:** [この変更が役立つ理由の簡潔な説明]

```diff
+ ## Quick Start
+
+ ```bash
+ npm install
+ npm run dev
+ ```

### Phase 5: 更新の適用

ユーザーの承認後、Edit ツールを使用して変更を適用します。既存のコンテンツ構造を保持します。

## 例

### 例 1: 品質評価

**ユーザーリクエスト：** 「CLAUDE.md が良いかチェックして」

**レスポンス：**
~~~markdown
## CLAUDE.md Quality Report

### Summary
- Files found: 1
- Average score: 65/100
- Files needing update: 1

### File-by-File Assessment

#### 1. ./CLAUDE.md
**Score: 65/100 (Grade: C)**

| Criterion | Score | Notes |
|-----------|-------|-------|
| Commands/workflows | 10/20 | npm install のみドキュメント化 |
| Architecture clarity | 15/20 | 基本的なツリーのみ、モジュール関係が欠落 |
| Non-obvious patterns | 5/15 | 落とし穴がドキュメント化されていない |
| Conciseness | 15/15 | 簡潔で密度が高い |
| Currency | 10/15 | 古いパスへの参照がある |
| Actionability | 10/15 | 曖昧な指示がある |

**Issues:**
- テストコマンドが欠落
- ビルドコマンドが欠落
- 認証フロー複雑性がドキュメント化されていない
- 古い src/structure への参照

**Recommended additions:**
- test/build コマンド付きの Commands セクションを追加
- 認証モジュールの落とし穴をドキュメント化
- アーキテクチャパスを更新

例 2: ゼロから作成

ユーザーリクエスト： 「この React プロジェクト用に CLAUDE.md を作成して」

レスポンス：

React プロジェクト用の CLAUDE.md を作成します。まずコードベース構造を分析します。

[package.json、src/、主要な設定ファイルをスキャン]

## CLAUDE.md Quality Report

### Summary
- Files found: 0
- プロジェクトルートに新しい CLAUDE.md を作成

### 提案される CLAUDE.md コンテンツ：

# Project Name

## Commands

| Command | Description |
|---------|-------------|
| `npm install` | 依存関係をインストール |
| `npm run dev` | 開発サーバーを起動（Vite ポート 5173） |
| `npm run build` | 本番ビルド |
| `npm run test` | Vitest テストを実行 |
| `npm run lint` | ESLint チェック |

## Architecture

src/ ├── components/ # 再利用可能な UI コンポーネント ├── pages/ # ルートページ ├── hooks/ # カスタム React フック ├── lib/ # ユーティリティと API クライアント └── main.tsx # エントリーポイント

## Gotchas

- Vite は静的資産に対して `public/` 内のファイルが必要
- `useEffect` の状態更新には適切な依存配列が必要

このファイルを作成してもよろしいですか？

例 3: 更新提案

ユーザーリクエスト： 「学んだ内容で CLAUDE.md を更新して」

レスポンス：

### Update: ./CLAUDE.md

**Why:** テストがドキュメント化されていなかったデータベースセットアップを必要とすることが判明しました。

```diff
## Testing

+ **前提条件：** まず `docker-compose up -d test-db` でテストデータベースを起動
+ `npm run test` - すべてのテストを実行
+ `npm run test:unit` - ユニットテストのみ（DB 不要）

また API_BASE_URL の問題も見つかりました：

## Environment

- `API_BASE_URL` - API エンドポイント（デフォルト：localhost:3000）
+ `API_BASE_URL` - API エンドポイント（本番環境に必須、開発環境ではデフォルト http://localhost:3000）

この変更を適用しますか？

## ベストプラクティス

1. **動作前に参考資料を読む**：品質基準、テンプレート、更新ガイドラインに重要な詳細が含まれています
2. **編集前にレポート**：品質レポートを提示せずに CLAUDE.md を修正しないでください
3. **既存の構造を保持**：更新時は既存の組織とスタイルを維持します
4. **プロジェクト固有の情報**：一般的なアドバイスではなく、このコードベース固有の情報のみを追加してください
5. **コマンドが機能することを確認**：コマンドを提案する前に、精神的に、または実際に実行可能であることを確認してください
6. **段階的な情報開示を使用**：SKILL.md は簡潔に、詳細なルーブリックは別ファイルで参照してください
7. **一貫して採点**：すべてのファイルで同じ採点基準を適用し、不完全なドキュメントに対してスコアを膨らませないでください

## 制約と警告

1. **承認なしに変更しない**：CLAUDE.md ファイルを編集する前に常にユーザー確認を取得してください
2. **確認なしにコンテンツを削除しない**：削除を提案する場合は、明確にマークして承認を取得してください
3. **`.claude.local.md` を尊重**：これらは個人設定です。共有ドキュメントでの修正を提案しないでください
4. **一般的なアドバイスを避ける**：「良いコードを書く」というタイプのコンテンツは追加しないでください。プロジェクト固有のパターンに焦点を当ててください
5. **diff を簡潔に保つ**：実際の変更のみを表示し、ファイル全体の内容は表示しないでください
6. **ファイルパスを確認**：ドキュメント化する前に、すべての参照ファイルが存在することを確認してください
7. **客観的に採点**：ルーブリックを一貫して使用してください。不完全なドキュメントでスコアを膨らませないでください