あらゆるスキルを自分のプラットフォーム仕様に変換するClaudeCodeプラグインを作った

Last updated at 2026-04-26Posted at 2026-04-26

はじめに

Claude Code スキルの探索・制作を始めて日が浅いのですが、公開スキルの多くが自分の環境に合わないと感じていました。

公開されているスキルの多くが英語で書かれている
コード例が TypeScript / Python / C# など、自分のスタックと合わない
Claude Code 前提で書かれていて、Copilot CLI や Gemini CLI に持っていけない

私の仕事は VB.NET + Windows Forms という産業用制御系なので適合するスキルが少なく、 LLM に翻訳・移植を頼むと下記のような事故が起きました。

元に無かった「ベストプラクティス」が勝手に追加される
訳しにくい箇所が静かに消える
同じ概念が文書内で複数の訳語に揺れる
後から「なぜこの記述が入っているのか」を辿れない

そこで、 VB.NET 専用に「Web / C# 向けスキルを勝手な改変を阻止しつつ VB.NET Windows Forms 向けに書き換える」というフローを組み立てました。これがうまく回ったことが発端で、この手順は言語にもロケールにもエージェントにも効くのでは？ と気づいたので、あらゆる変換に使える汎用プラグインとして切り出したのが skill-conversionです。

リポジトリ: https://github.com/oreguchi/skill-conversion

何をするプラグインか

既存の Claude Code スキルを 3 次元の任意組み合わせで変換するプラグインです。

次元	変えるもの	具体例
Technical	プログラミング言語・FW	C# → VB.NET、Python → Go、React → Vue
Locale	自然言語	英語 → 日本語、英語 → 中国語
Agent	実行エージェント	Claude Code → Copilot CLI / Gemini CLI

3 次元はそれぞれ独立していて、任意の組み合わせをサポートします。「英語の Claude Code 向け TypeScript スキル → 日本語の Copilot CLI 向け Go スキル」という 3 次元同時変換も可能です。

v1.0 の中核設計 — 3 軸モデル

v1.0 では変換の品質を 3 つの軸で同時に管理します。

軸	何を測るか	v0.2 までの扱い
変換元忠実度	ソース著者の意図がどれだけ保たれているか	approved-additions register で管理（v0.2 に既存）
技術的正確性	ターゲット環境でコードがコンパイル / 実行可能か	Phase 3 で検証（v0.2 に既存）
ターゲット有用性	ターゲット環境固有の必須機能 / 差別化機能がカバーされているか	検出機構が存在しなかった（v1.0 で新設）

3 軸目の「ターゲット有用性」を構造化するために、v1.0 では Conversion Profile（期待値の宣言）と Catalog System（環境固有機能のカタログ）を導入しました。

設計の要点 — 7 つの機構

1. 変換規則表（conversion rule tables）

翻訳に着手する前の Phase 0 で、次元ごとに「元 → 先」の対応表を先に固めます。たとえば Python → Go なら:

Python	Go
`def foo():`	`func foo()`
`class Bar:`	`type Bar struct{}`
`try/except`	`if err != nil`

アドホックに判断する前に表を確定しておくのがポイントです。これだけで用語の揺れと構文のぶれが大幅に減ります。

2. 追加台帳（approved-additions register）

元に存在しなかった内容を足すときは、必ず一件ずつユーザー承認を経て、理由と影響度を添えて台帳に記録します。バッチ承認は禁止しています（audit trail が形骸化するため）。

v1.0 で Category 列が追加されました:

A. 忠実度維持: ソース忠実度を維持するための補正（コンパイラ制約への対応など）
B. 環境必須: ターゲット環境で事実上必須な基本機能（Catalog Tier 1+2 相当）
C. 差別化機能: ターゲット環境特有の差別化機能（Catalog Tier 3 相当）

追加日	場所	要約	Category	理由	影響度	承認者
2026-04-25	§3.2	UI スレッドマーシャリング統合	B	WinForms 環境で必須	heavy	oreguchi

3. 不動点レビューループ（fixpoint review loop）

翻訳直後に、3 軸のレビュー（技術 / 文章 / 元との差分）を並列で走らせます。1 パスでゼロ変更になるまで繰り返します。重要度の高いスキルは 2 パス連続ゼロ変更が収束条件です。v1.0 では profile に関わらず常に 2 パス連続を採用します（profile は他の 3 機構で表現されるため、品質ガードレールを下げない）。

4. 差分レポート（drift report）

完了時に、元スキルとの全差分を集計してレポートを出力します。Phase 1 / 4 で承認された追加、却下された提案、影響度サマリ、総合判定（LOW / MODERATE / HIGH）。v1.0 では Conversion Profile、使用 Catalog、Phase 3 採用 API、Profile 拒否提案セクションが追加されました。

5. Conversion Profile（v1.0 NEW）

ユーザーが Phase 0 §7 で「変換の期待値」を 3 段階で宣言します。

Profile	意味	既定での挙動
高忠実度	ソース忠実度最優先	Phase 4 opt-out 可（理由必須）/ 追加は A のみ受け付け
バランス（既定）	忠実度 + 有用性両立	Phase 4 強制 on / 追加は A + B 受け付け
高有用性	ターゲット有用性最優先	Phase 4 強制 on / 追加は A + B + C 受け付け

profile 宣言が以下の 4 軸を機械的に決定します:

Phase 4 opt-in 状態
approved-additions 承認閾値
Catalog 参照範囲
(Phase 2 fixpoint は profile 不問で常に 2 パス連続)

これにより、ユーザーの意図が変換ワークフロー全体に一貫して反映されます。

6. Catalog System（v1.0 NEW）

ターゲット環境特有の「期待機能」と「罠」を蓄積するカタログ。references/catalogs/<lang>-<framework>.md 形式で永続化されます。

期待機能は 3 階層に分類:

Tier 1: ソース忠実度の延長として欠落させない基本機能（どの profile でも参照）
Tier 2: ターゲット環境で事実上必須な機能（balanced 以上で参照）
Tier 3: ターゲット環境特有の差別化機能（high-utility のみ参照）

罠（Gotchas）は profile 不問で全件参照され、Phase 1〜2 の §3b no-equivalent 表に自動マージされます。

生成・承認は 2 段階:

内容承認: subagent が catalog ドラフトを生成 → ユーザーが Tier 分類・項目をレビュー・承認
永続化承認: 承認済 catalog を再利用可能な形で保存するか、今回限りで破棄するかをユーザーが選択

「VB.NET WinForms カタログ」を一度作って永続化しておけば、次回以降の変換で再利用できます。

7. 9 マス承認テーブル（v1.0 NEW）

Category × Profile による approved-additions の自動判定マトリクス。Impact（minor / moderate / heavy）と組み合わせて 27 セル。

カテゴリ × Impact	高忠実度	バランス	高有用性
A. 忠実度維持・minor	自動承認	自動承認	自動承認
A. 忠実度維持・moderate	自動承認	自動承認	自動承認
A. 忠実度維持・heavy	user 承認必須	user 承認必須	user 承認必須
B. 環境必須・minor	user 承認必須	自動承認	自動承認
B. 環境必須・moderate	拒否（原則）	user 承認必須	自動承認
B. 環境必須・heavy	拒否	user 承認必須	user 承認必須
C. 差別化機能・minor	拒否	user 承認必須	自動承認
C. 差別化機能・moderate	拒否	拒否	user 承認必須
C. 差別化機能・heavy	拒否	拒否	user 承認必須

「拒否」になった追加は profile の意図に反するため取り込まれず、drift-report の「Profile 拒否提案」セクションに記録されます。同じ提案が profile を変えるだけで結果が変わるのがポイントで、ユーザーが宣言した期待値が機械的に強制されます。

dogfooding（v1.0.0 自身の検証）でこの効果を実証しました:

同じ「Tier 3 由来の C × heavy 提案」が、profile=高有用性では user 承認 → 採用、profile=バランス / 高忠実度では自動的に rejected
v0.2 で発生した「期待値とアウトプットのずれ」が、v1.0 では構造的に発生しなくなる

Phase 3 — 出典確認サブステップ（v1.0 NEW）

ビルド PASS 後、採用された API の公式性を 4 段階で記録します。

レベル	定義
Official	Microsoft Learn / 公式リファレンス / 言語仕様書に記載
Standard	主要書籍・公式チュートリアル・主要 OSS のドキュメントに記載
Peripheral	GitHub README / ブログのみ
Unknown	出典未確認

Peripheral / Unknown の API を採用する場合は、SKILL.md に標準パターンと採用 API の両方を併記するのが必須化されました。

これは v0.2 で AddOptionsWithValidateOnStart のような peripheral な API がビルド回避策として採用されたが、レビューで「公式性が低い」と指摘された経験を踏まえての追加です。コンパイルが通れば OK、ではなく、読者が公式性まで判断できる情報まで残すという思想です。

6 フェーズのワークフロー

Phase 0  スコープ宣言 + Profile 宣言 + Catalog 状態確認・生成
  ↓
Phase 1  初期翻訳（Catalog 罠を §3b に自動マージ）
  ↓
Phase 2  Fixpoint ループ（2 パス連続ゼロ変更）
  ↓
Phase 3  コード実行可能性検証 + 出典確認
  ↓
Phase 4  経験的チューニング（profile が opt-in 状態を機械決定）
  ↓
Phase 5  Auto-fire テスト（新規セッションで発火確認）
  ↓
完了    Drift Report → ユーザー承認

Phase 0 が v1.0 で大きく拡張され、Profile 宣言と Catalog 状態確認・生成・2 段階承認のステップが追加されました。

使い方

自然言語で話しかけるだけです。

「この C# スキルを VB.NET に変換して、バランス profile で」
「このスキルを日本語に翻訳して、高忠実度で（Phase 4 は不要）」
「Claude Code のこのスキルを Go で Copilot CLI 向けに移植して、有用性重視で」

profile を指定しない場合は balanced（バランス）が自動採用されます（warning 付き）。

発火後は Phase 0 の項目をヒアリング → plan doc を生成 → Phase 1 以降に進みます。追加・catalog 永続化・Phase 4 採用などの場面では必ずユーザーゲートが挟まります。

インストール

/plugin install superpowers
/plugin install empirical-prompt-tuning
/plugin marketplace add oreguchi/skill-conversion
/plugin install skill-conversion@skill-conversion-marketplace

前提プラグイン: