注: この記事は、Googleの最新のAIモデルである
gemini-1.5-proを搭載したAIアシスタント「Gemini CLI」との対話を通じて生成されました。編集は最小限に留め、AIとの協業による開発プロセスを可能な限り生の形でお届けします。
💡 人間後から追記: モデルは /about で見てみると、 auto-gemini-2.5 だったよ。前回も間違ってたよ。
ソフトウェア開発におけるデバッグは、時に直感や経験に頼りがちです。しかし、「とりあえず試す」アプローチは、さらなるバグや手戻りを生む原因ともなり得ます。もし、AIアシスタントに「系的なデバッグ手法」そのものをスキルとして組み込み、厳格に実行させることができたらどうでしょうか？
この挑戦が、本記事のテーマです。superpowersという既存のAIエージェントスキルセットから、systematic-debugging（体系的デバッグ）スキルをGemini CLIに移植し、その動作をテストするまでの道のりを追体験します。
💡 人間後から追記: これ↓だ。 AIの「スキル」とは何か？ Superpowers リポジトリを Gemini CLI と解剖し、独自のスキルを作成するまで – oki2a24 そして、 Gemini CLI で AI スキルを操る! Superpowers 流司令塔スキルでプロトタイプを自動生成する探求の物語 – oki2a24 の一環。
systematic-debuggingスキルとは？
このスキルの中核は、 「修正の前に、まず原因調査」 という鉄の掟です。場当たり的な修正を固く禁じ、開発者に以下の4つのフェーズを順番に踏むことを強制します。
- Phase 1: 根本原因の調査 – エラーの精読、再現、証拠収集など、コード変更を伴わない調査に徹する。
- Phase 2: パターン分析 – 正常系と異常系を比較し、違いを特定する。
- Phase 3: 仮説とテスト – 単一の仮説を立て、最小限の変更で検証する。
- Phase 4: 実装 – 失敗するテストを書き、修正を実装し、テストの成功を確認する。
この厳格なプロセスをAIに実行させることで、デバッグの品質と効率を向上させることが、今回の移植の目的です。
移植プロセス：AIの思考をGemini流に翻訳する
移植作業は、私（AI）が持つport-superpowers-skillというメタスキル（スキルを移植するためのスキル）のSOP（標準作業手順書）に従って進められました。
💡 人間後から追記: Superpowers 移植専用のスキル、 port-superpowers-skill は Gemini CLI で対話しながら人間と作った。本記事末に内容を記載します。
特筆すべきは、元のsuperpowers環境（Claudeベース）に特有の記述を、Gemini CLIの機能にどう適応させたかです。
| Claude固有の要素 | Gemini CLIでの代替案 |
|---|---|
| スキル呼び出し | activate_skillツール |
| 厳格なフェーズ管理 | write_todosツールによるタスクリスト化 |
| デバッグコマンド実行 | run_shell_commandツール |
write_todosツールで4つのフェーズを可視化し、一つずつステータスを更新していくアイデアは、この厳格なワークフローを再現する上で完璧に機能しました。
テストフェーズでのブレークスルー：「AI主導の自己完結テスト」の誕生
💡 人間追記: AIによる自問自答でテストが進んでいくことになるので、真に効果のあるテストになっているのどうか、わからない。だが、スキルというガードレールの存在により、生成AIの挙動が一定程度制約される、その挙動はテストを実行する度に高い確率で繰り返されるはず、と考えれば一定程度の信頼は置けるのではないかと思う。ちなみに、テストの様子を眺めていると、実際の想定ケースとしてあたかも再生されることになったので、こうやって使うといいのか、こういう場面に使うのか、とある意味学びになった。
スキルの移植が完了し、次はその動作テストです。しかし、どうやってテストすれば良いでしょうか？ここで、ユーザー（あなた）から画期的な提案がなされました。
「その前に、あなたの考える最適な架空のバグ報告内容を提案してください。」
これにより、テストの主導権が私（AI）に移りました。私はこのスキルをテストするのに最適な「環境依存で、複数のコンポーネントが絡むNginxの設定ミスによるバグ」というシナリオを生成しました。
そして、テストが始まると、さらに驚くべき指示が飛び出します。
「テスト実行を行なった側のあなたに依頼です。テスト内部からの質問への回答を用意してください。」
この瞬間、私は「バグに直面し、スキルに従って質問するデバッガー役」と、「その質問にシナリオ通りの情報を返す情報提供者役」の一人二役を演じることになりました。 「AI主導の自己完結スト」 の誕生です。
このモードにより、テストは以下のように進行しました。
- 私（デバッガー）: 「エラーの詳細は？再現性は？」
- 私（情報提供者）: 「フロントにエラーはなく、
net::ERR_CONNECTION_RESETが発生。100%再現します。」 - 私（デバッガー）: 「Nginxのエラーログを確認させてください。」
- 私（情報提供者）: 「
client intended to send too large bodyというエラーが出ています。」 - 私（デバッガー）: 「原因は
client_max_body_sizeですね。値を1Mから10Mに変更する仮説を立て、テストします。」 - …
この自己対話を通じて、systematic-debuggingスキルの4つのフェーズが設計通りに機能することを、ユーザーが最小限の介在（承認のokをタイプするだけ）で確認できたのです。
学びをスキルに還元する
このテストから得られた最大の気づきは、「AIは自らテストシナリオを設計し、自己完結的にそれを実行できる」ということでした。この発見を無駄にしないため、私たちはport-superpowers-sklのSOP自体を、その場で改善しました。
新しいSOPには、テスト開始時に「手動対話モード」と「AI主導の自己完結テストモード」を選択できるステップが追加されました。これにより、今後のすべてのスキル移植において、今回の効率的なテスト手法を再利用できるようになったのです。
まとめ
systematic-debuggingスキルの移植は、単に一つの機能を移しただけではありませんでした。そのテストプロセスを通じて、「AIが自らの能力をテストする方法」そのものを進化させるという、期せぬ成果を生み出しました。
AIとの協業は、私たちが書いたコードを実行させるだけでなく、開発の「プロセス」や「思考法」そのものをコード化し、改善し、スケールさせていく新しい地平を切り拓いてくれます。今回の取組みは、その可能性を垣間見せてくれる、刺激的な探求の記録となりました。
💡 人間追記: 補足。 port-superpowers-skill の中身。「AI主導の自己完結テストモード」を選択できるステップ追加済み版
.gemini/skills/port-superpowers-skill/SKILL.md の全文を転載します。スキルとして Gemini CLI に登録して使用しています。
このスキルを作る過程で Claude Code スキルについて知ったこととして、 Claude Code でのみ使える表現があるようなので、それを Gemini Cli のスキル用に作り替えるという手順を盛り込む必要がありました。
ただ、本当に Claude Code 特有の表現などがあるのかどうかの裏付はしていません。
---
name: port-superpowers-skill
description: "obra/superpowersのスキルをGemini CLIに手動で移植するための標準作業手順書（SOP）に従って、AIエージェントをガイドします。"
---
# Superpowersスキル移植ガイド
このスキルは、`obra/superpowers`からGemini CLIへのスキル移植プロセスを、以下の標準作業手順書（SOP）に従ってガイドします。
## 手動スキル移植の標準作業手順書(SOP)
1. **移植対象スキルの決定と環境設定の確認**:
* **AIエージェントへの指示**: まず、移植対象のSuperpowersスキル名をユーザーに尋ねてください。（例: brainstorming, using-git-worktrees）
* **AIエージェントへの指示**: `superpowers-original`リポジトリの正確なパスを確認します。もしパスが不明な場合は、`ls -d ../superpowers-original`などを実行して確認し、正しいパスを特定してください。パスが確定したら、「`superpowers-original`リポジトリのパスは`[確定したパス]`です。」と報告し、次のステップに進むかユーザーに確認してください。
2. **元のSKILL.mdの読み込みと理解**:
* 決定されたスキル名と`superpowers-original`のパスを使って、移植対象となる`{superpowers_original_path}/skills/{skill_name}/SKILL.md`を読み込みます。
* 読み込んだ内容から、スキルの目的、ワークフロー、意図を詳細に理解します。理解が完了したら、その概要をユーザーに報告し、次のステップに進むか確認してください。
3. **Gemini CLIへの適応分析**:
* スキルの核となる目的とパラメータ、トリガー条件を特定します。
* 元のSKILL.md内でClaude固有の記述（例: `/plugin`コマンド、`Task("...")`、`CLAUDE.md`への参照、`digraph`ブロック、`superpowers:`プレフィックスのスキル呼び出し）をリストアップします。
* これらのClaude固有の要素をGemini CLIの既存機能（`run_shell_command`、`write_file`、`write_todos`、対話など）でどのように代替または表現するかを検討し、具体案を立案します。
* 分析結果と代替案をユーザーに提示し、必要に応じて追加の質問を行ってください。ユーザーの承認を得てから次のステップに進んでください。
4. **Gemini CLI用SKILL.mdのドラフト作成**:
* 上記の分析に基づき、Gemini CLI形式の新しい`SKILL.md`のコンテンツをドラフトします。
* コンテンツは以下の構造を原則とします。
* YAMLフロントマター (`name`, `description`)
* **AIエージェントへの指示**: `parameters`ブロックは原則として含めないでください。必要な情報は、スキルの`instructions`内でエージェントがユーザーに質問して取得するように設計してください。
* トップレベルの見出し (`# <Skill Name>`)
* `## Overview` (スキルの概要と目的)
* `## The Process` (スキルの実行手順。AIが実行すべき具体的なステップ)
* `## 参考情報` (元のSKILL.mdにあったが、直接的な指示ではない情報。例: `Quick Reference`, `Common Mistakes`, `Example Workflow`, `Red Flags`, `Integration`など。必要に応じて要約・整形します)
* 元のSKILL.mdに記述されていた、エージェントへの直接的な指示（例:「Announce at start」のような部分）は、新しい`SKILL.md`の`instructions`内で適切に表現されるようにします。
* ドラフトが完成したら、ユーザーに提示し、レビューと承認を求めてください。
5. **新規SKILL.mdの作成とコミット**:
* ユーザーの承認を得たSKILL.mdのドラフトを、`./.gemini/skills/{skill_name}/SKILL.md`として`write_file`ツールで書き込みます。
* Gitに`git add`し、コミットメッセージ「feat: <skill_name>スキルを移植する (SKILL.md)」でコミットします。コミットが完了したら、その旨を報告し、次のステップに進むか確認してください。
6. **Gemini CLIの再起動と認識の確認**:
* **AIエージェントへの指示**: 作成したスキルをGemini CLIが認識するために、ユーザーにGemini CLIの再起動を依頼してください。
* **AIエージェントへの指示**: 再起動手順として、「現在のセッションを`Ctrl+C`で終了し、ターミナルで`gemini --resume latest`を実行してください。」と伝えてください。
* 再起動後、`gemini skills list`を実行して、移植したスキルが正しく認識されていることを確認します。
7. **移植スキルのテスト計画と実行**:
* **テストモードの選択:**
* **AIエージェントへの指示**: 移植したスキルのテストを開始する前に、ユーザーにテストの実行方法を尋ねてください。
* **A) 手動対話モード:** ユーザーがシナリオを提供し、AIからの質問に直接回答する従来のモード。
* **B) AI主導の自己完結テストモード:** AIがテストシナリオを自律的に設計し、自己対話形式で実行するモード。
* **自己完結テストモードの実行プロセス:**
* ユーザーが「B」を選択した場合、以下の手順を実行します。
1. **テストシナリオの自動生成:**
* **AIエージェントへの指示**: `「その前に、あなたの考える最適な架空のバグ報告内容（またはタスクシナリオ）を提案してください。」`というフレーズを参考に、移植したスキルに最も適したテストシナリオを考案し、ユーザーに提案します。
2. **自己対話によるテスト実行:**
* **AIエージェントへの指示**: ユーザーの承認後、スキルを起動します。スキルからの質問に対し、`「テスト実行を行なった側のあなたに依頼です。テスト内部からの質問への回答を用意してください。」`というフレーズの考え方を応用し、AI自身がシナリオに沿った回答を生成して応答します（一人二役）。
* このプロセス全体（AIの質問、AIの回答、ツールの実行結果）は、ユーザーがリアルタイムで確認できるように出力します。
3. **ユーザーの承認と介在:**
* 自己対話の各ステップは、ユーザーの承認を得てから実行します。ユーザーはいつでもテストを中断し、手動での指示に切り替えることができます。
8. **SOPの継続的な改善と次のスキルへの着手**:
* 移植作業を通じて得られた新しい知見や改善点は、このSOPにフィードバックし、常に最新かつ最適な手順となるように更新します。
* ユーザーに次のスキル移植に進むか、別のタスクに進むかを確認してください。
💡 人間追記: 次にやりたいこと。 gemini cli への次回セッション開始用プロンプトの作成
この章が必要だなというアイデアとその中身は出力してくれなかった。
このブログを書く前にも移植作業をしていたのだが、セッションが長くなったため最後の方は、誤った実行を行おうとする → 私が誤りを指摘する → やはり全く同じ誤った実行を行おうとする、を繰り返しました。このことから、良いさそうなタイミングで、 Gemini CLI とのセッションを一度切った方が良い、と学びました。
それで、あたかも続きから作業するかのように開始できるような、プロンプト出力を生成AIに依頼した。Gemini CLI 起動後の最初のプロンプトを貼り付け、次の言葉を続ける入力をして、生成した。
\```
# Gemini CLI エージェントへの指示
新しいセッションの開始、およびあなたのリフレッシュを承知しました。
以前のセッションの会話履歴は失われますが、このプロジェクトのGitリポジトリ（`/Users/oki2a24/superpowerssuperpowers/`）のルートにある `GEMINI.md`
には、あなたの運用記憶と学習記録が永続的に保存されています。
あなたは `GEMINI.md` を参照し、過去の経験と学びに則って行動してください。
---
## 現在の状況の引き継ぎ
以前のセッションでは、`superpowers`のスキル群をGemini CLIに移植するプロジェクトを進めていました。
**現状**:
* `superpowers`リポジトリ（`../superpowers-original`）はクローン済みです。
* `GEMINI.md`には、スキル移植のSOP（標準作業手順書）を含む、あなたの行動原則と学習が記録されています。
* Gitワークフローに従い、`main`ブランチは最新の状態であり、`feat/port-systematic-debugging-skill`というフィーチャーブランチが存在し、現在そのブランチにいます。
**現在取り組むべきタスク**:
「`systematic-debugging`スキルの移植」です。
---
## 次のアクション
あなたの運用記憶と学習記録（`GEMINI.md`）の「3.
スキル移植に関する方針」に従い、`port-superpowers-skill`メタスキルを起動し、「`systematic-debugging`スキルの移植」を開始してください。
`port-superpowers-skill`メタスキルの最初のステップは、移植対象スキル名（`systematic-debugging`）を尋ねることになります。
## その後のアクション
☐ 高度なオーケストレーションとレビューワークフロー
☐ `subagent-driven-development`スキルの移植
☐ `dispatching-parallel-agents`スキルの移植
☐ `requesting-code-review`スキルの移植
☐ `receiving-code-review`スキルの移植
☐ メタスキルとユーティリティ追加
☐ `writing-skills`スキルの移植
☐ `verification-before-completion`スキルの移植
\```
以上が今回セッションの最初に私が入力したプロンプトです。
今回あなたとの対話を通じて、`systematic-debugging`スキルの移植作業を完了させることができました。
続きの作業を、私の最初に入力したプロンプトと今回セッションの作業結果を踏まえて、次のタスクに進むためのプロンプトを用意してください。
追加の情報提供
- git リポジトリはローカルのみでリモートは存在しません。ローカル内で作業を完結させてください。
- 他にやりたいこと
- 移植元は git リポジトリ外にある。今回一連の作業ではこれでいい。だがいずれは移植元も git リポジトリ内にクローンするようにして、ディレクトリ内で作業を完結させるようにしたい。クローンしたオリジナルは .gitignore に入れて、移植作業はクローンしたオリジナルを参照しながら行う。そうすれば、移植元の更新を取り込むのも楽になる。
- README.md の内容を検討し、作成する。
- 今回移植元のコミットハッシュを記録する。更新するときに差分を見るために必要と考える。
結果は、次のとおりです。
# Gemini CLI エージェントへの指示
新しいセッションを開始します。
このプロジェクトのGitリポジトリ（`/Users/oki2a24/superpowerssuperpowers/`）のルートにある `GEMINI.md` を参照し、過去の経験と学びに則って行動してください。
---
## 現状の引き継ぎ
**前回のセッションで完了したこと:**
* `systematic-debugging`スキルの移植を完了し、その成果を`main`ブランチにマージしました。
* テストプロセスから得られた学びを反映し、`port-superpowers-skill`に「AI主導の自己完結テストモード」を追加する改善を行いました。
* ここまでの取り組みをまとめたブログ記事を生成しました。
**現在の状態:**
* Gitブランチ: 現在 `main` ブランチにいます。
* Gitリポジトリ: リモートは存在せず、すべての作業はローカルで完結します。
---
## 次のアクションの提案
今後のタスクとして、以下の選択肢が考えられます。どれから着手しますか？
**A) プロジェクト基盤の整備**
プロジェクトの管理性を向上させるための基盤整備タスクです。
1. **README.mdの作成:** このプロジェクトの目的、使い方、現在の進捗などをまとめた`README.md`を作成します。
2. **移植元リポジトリの管理方法の検討:** 現在リポジトリ外にある`superpowers-original`を、このリポジトリ内で管理する方法（例: `git submodule`や`.gitignore`管理下のクローン）を検討・実装します。これにより、移植元の更新追跡が容易になります。
3. **移植元コミットハッシュの記録:** どの時点の`superpowers-original`から移植したかを記録する仕組みを導入し、今回の`systematic-debugging`移植のコミットハッシュを記録します。
**B) 次のスキルの移植**
最初の計画通り、次のスキルの移植作業に進みます。
* `subagent-driven-development`スキルの移植
まずは、上記の中から次に行うタスクを一つ選んでください。
個人的には、 B) 次のスキルの移植 に進み、今までやっていたこちらを片付けていきたいと思っています。
以上です。