Learn

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

概要

このスキルは Orchestrator として機能し、2エージェントアーキテクチャ内で全体的なワークフローを調整します。プロジェクトコンテキストの収集、深い分析を learn-analyst サブエージェントへの委譲、結果のフィルタリングと順位付け、ユーザーへの検出結果の提示、承認されたルールの .claude/rules/ への永続化を管理します。

関心の分離により、アナリストは焦点を絞ったフォレンジックプロンプトで操作でき、オーケストレーターはユーザーとの対話とファイルの永続化を管理します。

使用時期

以下の場合にこのスキルを使用してください：

• ユーザーが「このプロジェクトから学びたい」または「プロジェクトの慣例を理解したい」と尋ねる
• ユーザーが既存のコードベースから .claude/rules/ ファイルを自動生成したい
• ユーザーが「プロジェクトルールを抽出したい」または「パターンを発見したい」と尋ねる
• ユーザーが Claude Code にプロジェクトのコーディング標準を学ばせたい
• 新しいプロジェクトに参加した後、既存の慣例を体系化したい
• 大きな機能を開始する前に、Claude がプロジェクトパターンに従うことを確認したい

トリガーフレーズ: "learn from project"、"extract rules"、"analyze conventions"、"discover patterns"、"generate project rules"、"learn codebase"、"auto-generate rules"

説明

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

アナリストに委譲する前に、高レベルのプロジェクトコンテキストを収集します：

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

2. 既存ルールの確認: 既に文書化されているものを理解するために、既存のルールファイルをスキャンします：

# 既存ルールを確認
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. プロジェクトサイズを評価: プロジェクトスコープの概要を取得します：

# プロジェクトの簡単な概要
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 ツール を使用して、分析を learn-analyst エージェントに委譲します：

• Agent: learn-analyst
• Prompt: "Analyze the codebase in the current working directory. Follow your full process: discovery, pattern extraction, classification, and prioritization. Return your findings as a JSON report."
• 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 プロジェクトから学習

ユーザーリクエスト: 「Learn from this project」

フェーズ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：既存ルールを持つプロジェクト

ユーザーリクエスト: 「Discover project patterns」

フェーズ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]