---
name: skill-migrator
description: |
  既存のスキル（ユーザースコープまたは他プロジェクトスコープ）を、指定したプロジェクト・リポジトリ向けに移行・特化するスキル。
  移行先プロジェクト固有の技術スタック、コーディング規約、ディレクトリ構成などを分析し、
  移行元スキルの内容を対話的に拡張・カスタマイズして独立コピーとして配置する。

  以下の状況で使用:
  (1) ユーザーが「このスキルをプロジェクトXに移行して」「スキルをこのリポジトリ向けに特化して」と依頼した時
  (2) ユーザーが「汎用スキルをプロジェクト固有にカスタマイズして」と依頼した時
  (3) ユーザーが明示的に「/skill-migrator」を実行した時
  (4) ユーザーが「このスキルをローカライズして」「スキルをフォークして拡張して」と依頼した時
  (5) 既存スキルをベースに新プロジェクト用の派生スキルを作りたい場合
  汎用スキルのプロジェクト特化、スキルの移植、スキルのフォーク＆拡張に関する依頼全般でトリガーすべき。
---

# Skill Migrator

既存スキルを指定プロジェクト向けに移行・特化させるスキル。
移行元スキルをベースに、移行先プロジェクトの文脈を織り込んだ独立コピーを作成する。

## ワークフロー概要

```
1. 入力の確認     → 移行元スキル・移行先プロジェクトの特定
2. プロジェクト分析 → 技術スタック・規約・構成の自動検出
3. 分析結果の確認   → ユーザーと対話して分析結果を補正
4. 拡張方針の策定   → どの部分をどう特化するか提案・確認
5. スキル生成      → 移行元をベースに拡張した新スキルを生成
6. レビュー・調整   → ユーザーの確認を受けて微調整
```

## ステップ1: 入力の確認

ユーザーから以下を確認する。会話の文脈から読み取れる場合は確認を省略してよい。

### 必須情報
- **移行元スキルのパス**: SKILL.mdが存在するディレクトリパス
  - ユーザースコープ: `~/.claude/skills/<skill-name>/`
  - プロジェクトスコープ: `<project>/.claude/skills/<skill-name>/`
- **移行先プロジェクトのパス**: ルートディレクトリのパス
  - 移行先は `<project>/.claude/skills/<skill-name>/` に配置

### 任意情報
- **スキル名の変更**: 移行先で別名にしたい場合（デフォルトは元の名前を維持）
- **特に特化したい領域**: ユーザーが明確な拡張意図を持っている場合

## ステップ2: プロジェクト分析

移行先プロジェクトを自動分析し、スキル拡張に活かせるコンテキストを収集する。

### 分析対象

以下のファイル・ディレクトリを順に探索する:

#### コンテキストファイル（最優先）
- `CLAUDE.md` — AI向けプロジェクト指示（コーディング規約、アーキテクチャなど）
- `AGENTS.md` — エージェント向け指示
- `.claude/rules/` 配下のルールファイル
- `.cursorrules`, `.windsurfrules` など他AIツール向け設定

#### 技術スタック検出
- `package.json` → Node.js/フロントエンド技術、スクリプト、依存関係
- `go.mod` → Go言語、モジュール構成
- `Cargo.toml` → Rust
- `pyproject.toml`, `setup.py`, `requirements.txt` → Python
- `Gemfile` → Ruby
- `pom.xml`, `build.gradle` → Java/Kotlin
- `Makefile` → ビルド構成
- `docker-compose.yml`, `Dockerfile` → コンテナ構成
- `terraform/`, `*.tf` → IaC
- `tsconfig.json` → TypeScript設定
- `.eslintrc*`, `.prettierrc*` → Lint/フォーマッタ設定

#### プロジェクト構成
- ディレクトリ構造の概要（`ls -la`, 主要ディレクトリの役割）
- テストフレームワーク（`jest.config.*`, `vitest.config.*`, `pytest.ini` など）
- CI/CD設定（`.github/workflows/`, `.gitlab-ci.yml` など）
- README.md — プロジェクト概要

### 分析結果の構造化

収集した情報を以下のカテゴリに整理する:

```
プロジェクトコンテキスト:
├── 技術スタック（言語、フレームワーク、主要ライブラリ）
├── コーディング規約（命名規則、ファイル構成、スタイル）
├── アーキテクチャパターン（レイヤー構成、モジュール分割）
├── テスト方針（フレームワーク、カバレッジ要件）
├── 既存のAIコンテキスト（CLAUDE.md等から抽出した指示）
└── プロジェクト固有の用語・概念
```

## ステップ3: 分析結果の確認

分析結果をユーザーに提示し、対話的に補正する。
AskUserQuestionツールを活用して効率的に確認を取る。

### 提示する内容
1. 検出した技術スタックの一覧
2. 検出したコーディング規約のサマリ
3. スキル拡張に関連しそうなプロジェクト固有の特徴

### ユーザーに確認する内容
- 検出結果に誤りや不足がないか
- スキルに反映すべき追加のプロジェクト規約があるか
- 特に重視したい拡張ポイント

## ステップ4: 拡張方針の策定

移行元スキルの各セクションについて、プロジェクトコンテキストをどう反映するか方針を立てる。

### 拡張の観点

#### 4.1 description（トリガー条件）の拡張
- プロジェクト固有のユースケースをトリガー例に追加
- プロジェクト名やドメイン用語を含めた具体的なトリガー文を追加
- **プロジェクトの実際のブランチ戦略を反映する**（例: GitLab Flowなら`main`、Git Flowなら`develop`など。CLAUDE.mdやgit branchコマンドで確認し、存在しないブランチ名を例に使わない）

#### 4.2 ワークフロー・手順の特化
- プロジェクトの技術スタックに合わせた具体的な手順の追加
- 汎用的な記述をプロジェクト固有のツール・コマンドに置き換え
- プロジェクトのディレクトリ構成を前提とした操作の具体化

#### 4.3 品質基準・規約の統合
- CLAUDE.mdやlint設定から抽出した規約の組み込み
- プロジェクト固有のコーディングスタイルへの適合
- テスト要件やレビュー基準の反映

#### 4.4 CLAUDE.mdとの情報重複を避ける（重要）

移行先プロジェクトにCLAUDE.mdが存在する場合、SKILL.mdとの情報重複を意識的に管理する。

**SKILL.mdに複製しないもの（CLAUDE.md参照で済ませる）:**
- 技術スタックの一覧や概要説明（「このプロジェクトはKotlin/Ktorで...」といった背景情報）
- アーキテクチャの全体構成図やディレクトリ構成の説明
- コーディングスタイルの一般的な規約説明

**SKILL.mdに明示的に記載すべきもの（参照に置き換えない）:**
- **アクション可能なチェック項目**: 「`@Serializable`の新規フィールドにデフォルト値があるか確認」のような具体的な検証ステップ
- **禁止事項・CRITICAL RULESのチェックリスト**: 「`components/ui/`の編集禁止」「`any`型の使用禁止」等、スキル実行時に直接確認すべき項目
- **プロジェクト固有の判断基準や閾値**: 「200行以上のモーダルはディレクトリ分割」「テストが必須（バックエンド）」等
- **スキルの責務に直接関わるプロジェクト固有知識**: scope推定ルール、レビュー観点の具体例、分類基準など

つまり、**「背景情報」はCLAUDE.md参照に任せ、「実行時のチェックリスト」は必ずSKILL.mdに含める**。「CLAUDE.mdを参照」と書くだけでは、スキル実行時に具体的に何をチェックすべきか不明確になるため、チェック項目自体は省略しない。

補足:
- `context: fork` で別プロセスとして実行されるスキルの場合、CLAUDE.mdが自動的にコンテキストに含まれるかをユーザーに確認し、含まれない場合は背景情報も必要最小限をSKILL.mdに埋め込む
- 情報の二重管理が気になる場合は、CLAUDE.mdのセクション名を参照しつつチェック項目は具体的に記載する（例: 「CLAUDE.mdの『セキュリティ規約』に基づき、以下を確認: ...」）

#### 4.5 移行元スキルの観点を漏らさない（重要）

移行元スキルが持つ観点・チェック項目・ワークフローステップは、プロジェクトに適用可能な限り**すべて維持する**。プロジェクト固有の観点を追加する際に、移行元の汎用的な観点を削ってはならない。

具体的には:
- 移行元の各セクション・チェック項目を一つずつ確認し、プロジェクトに該当するものはすべて残す
- 「プロジェクトで使っていない技術」に関する記述のみ削除する（例: Go固有の記述をKotlinプロジェクトに移行する場合）
- 汎用的だが有用な観点（セキュリティ、エラーハンドリング、パフォーマンス等）は削除せず、プロジェクト固有の具体例で補強する
- without_skill版（スキルなしでの移行結果）の網羅性を下回らないことを目標とする

#### 4.6 コンテキスト情報の追加
- プロジェクト固有のファイルパス、設定パスの具体例
- 頻出パターンやアンチパターンの記述
- 既存コードベースから抽出した具体例の追加

#### 4.7 bundled resourcesの拡張
- プロジェクト固有のスクリプトやテンプレートの追加
- referenceファイルの追加（技術スタック固有のガイドなど）

### 方針の提示

拡張方針を箇条書きでユーザーに提示し、確認を取る:

```
拡張方針:
1. [セクション名]: [具体的な拡張内容]
2. [セクション名]: [具体的な拡張内容]
...
追加予定のセクション:
- [新規セクション名]: [目的と内容の概要]
```

## ステップ5: スキル生成

確認された方針に基づいて、移行元スキルをベースに拡張版を生成する。

### 生成ルール

1. **移行元の構造を尊重**: セクション構成は基本的に維持し、拡張・追記する形で変更
2. **frontmatterの更新**:
   - `name`: ユーザーが変更を希望しない限り維持
   - `description`: プロジェクト固有のトリガー条件を追加
   - 移行元への参照は含めない（独立コピーのため）
3. **プロジェクトコンテキストの埋め込み**: 分析結果を自然な形でスキル本文に統合
4. **具体例の追加**: 抽象的な記述をプロジェクト固有の具体例で補強
5. **不要な汎用記述の削除**: プロジェクトに該当しない技術スタックへの言及は削除

### 配置先

```
<移行先プロジェクト>/.claude/skills/<skill-name>/
├── SKILL.md
├── scripts/    （必要に応じて）
├── references/ （必要に応じて）
└── assets/     （必要に応じて）
```

移行元にbundled resourcesがある場合はコピーし、プロジェクトに合わせて調整する。

## ステップ6: レビュー・調整

生成したスキルをユーザーに提示し、フィードバックを受けて調整する。

### 提示する内容
1. 生成したSKILL.mdの全文
2. 移行元からの主な変更点のサマリ
3. 追加・削除したセクションの説明

### 調整のポイント
- ユーザーのフィードバックに基づいて修正
- 過剰な特化（狭すぎるスコープ）の調整
- 不足している規約やパターンの追加

## 注意事項

- 移行元スキルは一切変更しない（読み取り専用として扱う）
- 移行先ディレクトリが既に存在する場合、上書き前にユーザーに確認する
- プロジェクト分析で機密情報（API key、credentialなど）を検出した場合、スキルに含めない
- 大きなスキル（500行超）の場合、references/への分割を検討する