learn

学習

プロジェクトのコードベースを自律的に分析して、開発パターン、規約、アーキテクチャ上の決定を見つけ出し、Claude Code が従うプロジェクトルールファイルを .claude/rules/ に生成します。

概要

このスキルは、2つのエージェントで構成されるアーキテクチャにおいて オーケストレーター として機能します。プロジェクトのコンテキスト収集、詳細な分析の learn-analyst サブエージェントへの委任、結果のフィルタリングと順位付け、調査結果のユーザーへの提示、承認済みルールの .claude/rules/ への保存という、ワークフロー全体を調整します。

関心事を分離することで、アナリストは焦点を絞ったフォレンジック用プロンプトに基づいて動作し、オーケストレーターはユーザーとのやり取りとファイルの保存を管理できます。

使用するタイミング

次の場合にこのスキルを使用します。

• ユーザーが「このプロジェクトから学習して」または「プロジェクトの規約を理解して」と依頼した場合
• ユーザーが既存のコードベースから .claude/rules/ ファイルを自動生成したい場合
• ユーザーが「プロジェクトルールを抽出して」または「パターンを見つけて」と依頼した場合
• ユーザーが Claude Code にプロジェクトのコーディング標準を学習させたい場合
• 新しいプロジェクトに参加した後、既存の規約をルールとして明文化したい場合
• Claude がプロジェクトのパターンに従うよう、大規模な機能の開発を始める前

トリガーフレーズ：「プロジェクトから学習」「ルールを抽出」「規約を分析」「パターンを見つける」「プロジェクトルールを生成」「コードベースを学習」「ルールを自動生成」

手順

フェーズ 1：プロジェクトのコンテキスト評価

アナリストに委任する前に、プロジェクトの概要を把握します。

1. プロジェクトルートを確認する：現在の作業ディレクトリがプロジェクトルートであることを確認します（package.json、pom.xml、pyproject.toml、go.mod、.git/ などの目印があること）。

2. 既存のルールを確認する：既存のルールファイルをスキャンし、すでに文書化されている内容を把握します。

# Check for existing rules
ls -la .claude/rules/ 2>/dev/null || echo "No .claude/rules/ directory found"
cat CLAUDE.md 2>/dev/null || echo "No CLAUDE.md found"
cat AGENTS.md 2>/dev/null || echo "No AGENTS.md found"
ls -la .cursorrules 2>/dev/null || echo "No .cursorrules found"

3. プロジェクトの規模を評価する：プロジェクトの範囲を簡単に把握します。

# Quick project overview
find . -maxdepth 1 -type f -name "*.json" -o -name "*.toml" -o -name "*.xml" -o -name "*.gradle*" -o -name "Makefile" -o -name "*.yaml" -o -name "*.yml" | head -20
find . -type f -name "*.ts" -o -name "*.js" -o -name "*.java" -o -name "*.py" -o -name "*.go" -o -name "*.php" | wc -l

4. ユーザーに知らせる：見つかった内容と、これから分析を開始することを簡潔に伝えます。
   • 「[TypeScript/NestJS] プロジェクトが見つかりました。ソースファイルは [N] 個、既存のルールは [M] 個です。詳細な分析を開始します……」

フェーズ 2：アナリストのサブエージェントへの委任

learn-analyst サブエージェントを呼び出して、コードベースの詳細な分析を行います。

Task tool を使用して、分析を learn-analyst エージェントに委任します。

• Agent：learn-analyst
• Prompt：「現在の作業ディレクトリにあるコードベースを分析してください。検出、パターン抽出、分類、優先順位付けの全手順に従ってください。調査結果は JSON レポートとして返してください。」
• Mode：JSON レポートを直接受け取れるよう、同期実行します。

アナリストは、分類済みの調査結果を含む構造化された JSON レポートを返します。

フェーズ 3：結果の確認とフィルタリング

アナリストのレポートを処理します。

1. アナリストが返した JSON レポートを解析します。
2. 調査結果を検証する：各調査結果に以下が含まれていることを確認します。
   • 明確なタイトル
   • 2つ以上のファイルから得られた証拠
   • 影響度スコア ≥ 4（影響度の低い調査結果は破棄）
   • 正しく整形された Markdown コンテンツ
3. 既存のルールと重複しないか確認する：各調査結果のタイトルと内容を既存の .claude/rules/ ファイルと比較します。既存のルールと重複する調査結果はスキップします。
4. 上位3件を選択する：残った調査結果から、影響度スコアの上位3件を選択します。フィルタリング後に3件未満しか残らなかった場合は、残った分を提示します。
5. 調査結果が残らなかった場合：プロジェクトがすでに十分に文書化されているか、文書化されていない重要なパターンが見つからなかったことをユーザーに伝えます。

フェーズ 4：ユーザーへの提示

フィルタリングした調査結果を、分かりやすく構造化された形式でユーザーに提示します。

I analyzed your codebase and found N patterns worth documenting as project rules:

1. **[RULE]** <Title> (Impact: X/10)
   <One-line explanation>

2. **[RULE]** <Title> (Impact: X/10)
   <One-line explanation>

3. **[RULE]** <Title> (Impact: X/10)
   <One-line explanation>

続いて、AskUserQuestion を使用してユーザーに確認します。

• 選択肢を提示します：「N 件のルールをすべて保存」「保存するルールを選択」「キャンセル — 何も保存しない」
• ユーザーが個別に選択したい場合は、各ルールを1件ずつ提示し、「保存／スキップ」の選択肢を表示します。
• 自動で保存してはいけません。必ずユーザーの明示的な承認を得てください。

フェーズ 5：承認済みルールを保存する

承認されたルールごとに、以下を行います。

1. ディレクトリが存在することを確認する：

mkdir -p .claude/rules

2. ファイル名を生成する：調査結果の title フィールドをケバブケースに変換して使用します。

   • 例："API Response Envelope Convention" → api-response-envelope-convention.md
   • rule-1.md や learned-pattern.md のような汎用的な名前は避けてください。

3. 競合を確認する：書き込む前に、同じ名前のファイルがすでに存在するか確認します。

   • 存在する場合は、差分をユーザーに提示し、置き換えるか、マージするか、スキップするかを尋ねます。

4. ルールファイルを書き込む：アナリストが事前にフォーマットした内容で、.claude/rules/ にファイルを作成します。

5. ユーザーに確認する：保存後、作成したファイルをすべて一覧表示します。

✅ Rules saved successfully:

  .claude/rules/api-response-envelope-convention.md
  .claude/rules/feature-based-module-organization.md
  .claude/rules/test-factory-pattern.md

These rules will be automatically applied by Claude Code in future sessions.

ベストプラクティス

1. プロジェクトの早い段階で実行する：新しいプロジェクトに参加した際、このスキルを使って規約をすばやく明文化します。
2. 保存前にレビューする：生成されたルールがプロジェクトに適していることを必ず確認します。
3. 繰り返し実行する：プロジェクトの進化に合わせて定期的にこのスキルを実行します。新しいパターンが見つかる可能性があります。
4. 保存後に編集する：生成されたルールは出発点です。自分の正確な好みに合うよう調整してください。
5. ルールを git にコミットする：.claude/rules/ ファイルはプロジェクト固有のため、チーム全体で活用できるようバージョン管理してください。

制約と警告

重要な制約

1. 確認なしに保存しない：ファイルを書き込む前に、必ずユーザーに確認してください。
2. プロジェクト内のみ：現在のプロジェクトディレクトリ内の .claude/rules/ にのみ書き込みます。グローバルパスには書き込まないでください。
3. 読み取り専用の分析：アナリストのサブエージェントは、プロジェクトファイルを変更してはなりません。
4. 証拠に基づく：すべてのルールは、コードベース内の具体的な証拠に裏付けられている必要があります。
5. 幻覚を避ける：コードベースに実際に存在しないパターンを作り出さないでください。
6. 既存のルールを尊重する：ユーザーの明示的な承認なしに、既存のルールを上書きしないでください。
7. ルールを絞り込む：各ルールファイルでは、特定の規約またはパターンを 1 つ扱います。

制限事項

• 大規模なモノレポ：非常に大きなコードベースでは、分析に時間がかかる場合があります。アナリストはすべてのファイルではなく、代表的なサンプルをスキャンします。
• 複数言語のプロジェクト：複数の言語を使用するプロジェクトでは、言語ごとにルールが生成されます。ルールのタイトルに対象言語を明記してください。
• 既存のルールとの競合：プロジェクトにすでに包括的な .claude/rules/ がある場合、このスキルで新しいパターンがほとんど見つからない、またはまったく見つからないことがあります。これは想定どおりです。
• 動的なパターン：ミドルウェアの順序など、実行時にのみ明らかになるパターンもあります。このスキルでは静的なコードベース分析に重点を置いています。

例

例 1：NestJS プロジェクトから学習する

ユーザーのリクエスト：「このプロジェクトから学習して」

フェーズ 1 — コンテキストの評価：

Found: TypeScript/NestJS project with 142 source files
Existing rules: 0 files in .claude/rules/
Starting deep analysis...

フェーズ 4 — 提示：

I analyzed your codebase and found 3 patterns worth documenting as project rules:

1. **[RULE]** Feature-Based Module Organization (Impact: 9/10)
   All modules follow src/modules/<feature>/ with controller, service, dto, entity subdirectories.

2. **[RULE]** DTO Validation Convention (Impact: 8/10)
   All DTOs use class-validator decorators and follow Create/Update naming pattern.

3. **[RULE]** Error Response Envelope (Impact: 7/10)
   All API errors return { statusCode, message, error } consistent envelope format.

Save all 3 rules? [Save all / Let me choose / Cancel]

フェーズ 5 — 保存：

✅ Rules saved successfully:

  .claude/rules/feature-based-module-organization.md
  .claude/rules/dto-validation-convention.md
  .claude/rules/error-response-envelope.md

These rules will be automatically applied by Claude Code in future sessions.

例 2：既存のルールがあるプロジェクト

ユーザーのリクエスト：「プロジェクトのパターンを見つけて」

フェーズ 1 — コンテキストの評価：

Found: Java/Spring Boot project with 87 source files
Existing rules: 4 files in .claude/rules/
Starting deep analysis...

フェーズ 3 — 絞り込み後：

The analyst found 6 patterns, but 4 overlap with your existing rules.
After deduplication, 2 new patterns remain:

1. **[RULE]** Repository Method Naming (Impact: 7/10)
   All custom repository methods use findBy/existsBy/countBy prefix convention.

2. **[RULE]** Integration Test Database Strategy (Impact: 6/10)
   Integration tests use @Testcontainers with PostgreSQL and @Sql for fixtures.

Save these 2 rules? [Save all / Let me choose / Cancel]