Agent-Skills.md

Agent Skills: Skill Migrator

|

UncategorizedID: goldeneggg/dotfiles/skill-migrator

Repository

goldeneggg/dotfiles
goldeneggg
1

Install this agent skill to your local

pnpm dlx add-skill https://github.com/goldeneggg/dotfiles/tree/HEAD/ai-linux/deprecated/skills/skill-migrator

Skill Files

Browse the full folder contents for skill-migrator.

Download Skill

Loading file tree…

ai-linux/deprecated/skills/skill-migrator/SKILL.md

Skill Metadata

Name
skill-migrator
Description
|

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/への分割を検討する