claude-code-conductor: Skill for Claude Code

extract-lib

複数プロジェクトのコードを横断解析し、共通要素を抽出してライブラリ設計・スケルトン生成を行う。

---

Step 0: 規約ファイルを読み込む

.claude/rules/coding-standards.md と .claude/rules/project-conventions.md を Read する。

どちらも存在しない場合: 以下を表示して終了する:

規約ファイルが見つかりません。先に /setup を実行してプロジェクト規約を設定してください。

存在する場合: 以下を抽出して以降のステップで使用する:

• 使用言語・フレームワーク（ファイル拡張子含む）
• 命名規則（クラス名・関数名・定数名のパターン）
• ファイル・ディレクトリ構成の慣習
• その他の重要な規約

---

Step 1: 解析対象プロジェクトのパスを収集する

1回目のパス入力

AskUserQuestion ツール:

{
  "questions": [{
    "question": "解析対象の1つ目のプロジェクトの絶対パスを入力してください（例: C:/work/project-a）"
  }]
}

Glob で {入力パス}/** を検索してパスが存在するか確認する。存在しない場合は「パスが見つかりません」と伝えて再入力させる。

2回目以降のパス追加

AskUserQuestion ツール:

{
  "questions": [{
    "question": "別のプロジェクトを追加しますか？",
    "header": "パス追加",
    "options": [
      { "label": "追加する", "description": "さらに別のプロジェクトパスを入力する" },
      { "label": "これで完了", "description": "入力済みのプロジェクトで解析を開始する" }
    ]
  }]
}

「追加する」の場合は続けてパスを入力・検証し、「これで完了」になるまで繰り返す。 入力済みプロジェクトが1つのみの状態で「これで完了」が選ばれた場合は「最低2プロジェクト必要です」と伝えて再度選択させる。

---

Step 2: 出力形式を確認する

AskUserQuestion ツール:

{
  "questions": [{
    "question": "解析結果をどの形式で出力しますか？",
    "header": "出力形式",
    "options": [
      { "label": "設計のみ", "description": "共通化候補リストとライブラリ設計案をレポートとして出力する" },
      { "label": "設計 + スケルトン生成", "description": "設計案に加えてライブラリのスケルトンコードも生成する" }
    ]
  }]
}

「設計 + スケルトン生成」が選ばれた場合、続けて出力先を確認する:

{
  "questions": [{
    "question": "生成するライブラリの出力先ディレクトリの絶対パスを入力してください（例: C:/work/shared-lib）"
  }]
}

---

Step 3: 解析エージェントを起動する

Agent ツールで解析を実行する。以下のプロンプトを使用する:

あなたはコードベース横断解析エージェントです。
以下の複数プロジェクトを解析し、共通化すべき要素を抽出してください。

## 解析対象プロジェクト
{収集したプロジェクトパスのリスト}

## プロジェクト規約（.claude/rules/coding-standards.md / .claude/rules/project-conventions.md より）
{Step 0 で抽出した言語・フレームワーク・命名規則・その他規約}

## 解析手順

各プロジェクトについて順に以下を調査する。

### 1. ディレクトリ構造の把握
Glob で `{パス}/**/*.{言語の拡張子}` を検索してファイル一覧を取得する。
規約で複数言語が使われている場合はそれぞれの拡張子で検索する。

### 2. 定数・設定値の収集
規約に合わせた定数定義パターンで Grep する。
検索例（言語に合わせて調整すること）:
- TypeScript/JavaScript: `const [A-Z_]+ =`
- Java/C#: `static final|const|static readonly`
- Python: `^[A-Z_]+ =`

マジック値として使われる文字列・数値・タイムアウト値・URL パターン等も収集する。

### 3. ユーティリティ関数の収集
小規模ヘルパー関数を Grep で特定する。
特に以下に注目する:
- 文字列操作・日付操作・数値フォーマット
- バリデーション処理（入力検証・型チェック等）
- 変換処理（型変換・フォーマット変換・エンコード等）

類似した関数が複数プロジェクトに存在する場合は内容を Read して比較する。

### 4. 共通ロジックの収集
ビジネスロジック上の繰り返しパターンを調査する:
- エラーハンドリングの共通パターン
- ログ出力のラッパー処理
- 外部APIコール・HTTP通信の共通処理
- ページネーション・ソート・フィルタリングの共通処理

### 5. 型・インターフェース定義の収集（静的型付き言語の場合）
型定義・インターフェース・データクラス・DTO等を Grep で収集し、
複数プロジェクトで同一概念のものが個別定義されていないか確認する。

## 出力形式

以下の形式で結果をまとめること。

---

## 共通化候補リスト

### 高優先度（完全一致・ほぼ同一のコードが複数プロジェクトに存在）
| 種別 | 内容 | 発見場所（プロジェクト名:ファイルパス） |
|---|---|---|
| 定数 | ... | ProjectA: path, ProjectB: path |

### 中優先度（類似ロジック・命名が異なるが同一目的）
| 種別 | 内容 | 発見場所 | 差異の概要 |
|---|---|---|---|

### 低優先度（概念的共通・共通化は任意）
| 種別 | 内容 | 備考 |
|---|---|---|

## ライブラリ設計案

**推奨ライブラリ名**: {プロジェクト規約の命名規則に基づいた名前}

**ディレクトリ構成**:

{ライブラリ名}/ ├── {モジュール1}/ │ ├── {ファイル} │ └── ... ├── {モジュール2}/ └── ...

**公開API一覧**:
| モジュール | 名前 | 種別 | 責務 |
|---|---|---|---|

**移行時の注意点**: {既存プロジェクトからライブラリへ移行する際の注意事項}

---