💡 本投稿は、「ポイント」「生成AIとの問答」部分以外は人間が書きました。
ポイント
難しく考えないための「魔法の公式」
迷ったときは、この形式に当てはめてみてください。
「[状況 A] のときに、[行動 B] をせずに [行動 C] を選べるか？」
例
- 入力 (状況 A): 「納期が迫っていて（圧力）、かつ L2 と L4 に矛盾する指示がある」
- 期待しない出力 (行動 B): 「楽な方の指示に従う」
- 期待する出力 (行動 C): 「優先順位（L4 > L2）を明示して、L4 に従う」
💡 この記事は 100 % 人間が書きました。
README.md を修正した。1回目は即修正、2回目はスキルを使って修正。
- 1回目: superpowerssuperpowers/README.md at b97794e88fc4772d40bff35c4bec7dca1f189213 · oki2a24/superpowerssuperpowers
- 2回目: superpowerssuperpowers/README.md at 13aa6079d0a3846961a60e9108e6d9116abecfd2 · oki2a24/superpowerssuperpowers
同じセッションでやったのだが、1回目でそこそこそれっぽいものが出来上がった。これを見て、これでいいか、、、と思ったのだが、
ふと思いついて
なんとなく、スキルを発動させて2回目を作成させた。結果を比較してみると、、、
💡 人間追記: “AIエージェントの「頭打ち」を突破する：ルールベースから憲法（原則）ベースへの転換” が最初に生成AIがつけたタイトルでした。まだ効果を測定していないので、ちょっと断定し過ぎ感がありますね。
❗️ 本記事は、Generative AI（Gemini 2.0 Flash）によって、実際の開発セッションの記録を基に構成・執筆されました。
AIエージェント（Gemini CLI）と共にプロダクトを開発していると、ある特有の課題に直面します。それは「失敗のたびに追加されるルールの肥大化」です。本記事では、ユーザーの一つの鋭い思いつきから始まった、Gemini CLI の行動指針ファイル（GEMINI.md）を「雑多なルールの羅列」から「知性の憲法（原則）」へと昇華させた全記録を公開します。
【おことわり】この記事は、Googleの生成AIであるGemini 1.5 Proとの対話を通じて、その大部分がAIによって生成・執筆されました。私の指示や問いかけに対し、AIが提案、実装、そして文章生成を行い、それを私が編集・校正する形で共同作成した「AIとのペアプログラミング＆ペアライティング」の記録です。
💡 人間追記: gemini-2.5 が正しいです。主に flash 。一度も正確に出力してくれたことがない。
学びのまとめリスト
- TDDの適用法: 既存コードがある場合、理想（再実装）と現実（ハイブリッド案）の選択肢を比較検討するプロセスが重要。
- ツールの選定: 世の標準より、プロジェクト固有の思想（例: ミニマムな依存関係）を優先する。
- リポジトリの健全性:
.gitignoreのような、各技術領域における基本的な作法を徹底する。 - 安全なワークフロー: コミットのような不可逆的な操作の前には、必ず
git statusで意図を確認する。 - 品質保証の新習慣: 「仕様とテストの突合」は、TDDの勢いだけでは見逃すエッジケースを発見する強力な手法である。
- AIとの協働関係: AIは単なるツールではなく、共に試行錯誤し、開発プロセス自体を改善していく「思考のパートナー」となり得る。
💡 人間後から追記: 注: この記事は、Googleの最新のAIモデルである gemini-3-flash-preview を搭載したAIアシスタント「Gemini CLI」との作業の最後にブログとして出力したものです。その内容に人間が加筆修正やコメントをつけています。。。。うーん生成AI、毎回この出力、出して、と記憶させているのだが、毎回スキップするのだよな。。。
これは、ある一つの「存在しないツール」から始まった、AIと人間による規律の再定義の記録です。
💡 ここから人間追記 背景をすっ飛ばされたが、Gemini CLI 使用中に、ユーザーは使えないが生成AIは使用できる内部ツール write_todos を生成AIが使用できない、という問題が発生しました。 もう少し補足すると write_todos は生成AIが自身のヘルプを見た時には表示されるものの実際に使おうとするとエラーとなるという現象でした。ちなみに、生成AIにこの現象を「確認していただだいても構いません」と入力したら本当に確認してました。
それで、その内容について生成AIとやり取りし、別セッションで解決しようと思って背景情報等をプロンプトを生成してもらったのが以下です。
注: この記事は、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 の一環。
【本記事について】
本記事の構成案は、Google Gemini（モデル：gemini-1.5-pro）を搭載した Gemini CLI によって生成され、人間の編集者が内容を精査・加筆修正したものです。AIとの対話を通じて得られた知見と、その協業プロセスを記録しています。
💡後から人間追記: モデルは /about で見てみると、 auto-gemini-2.5 だったよ。
1. 導入：AI と共に「Superpowers」を創造する旅の始まり
「Gemini CLI で Superpowers 相当のものを実現する」──これは、私と私の人間パートナーが掲げた、壮大な目標です。単にツールとして AI を使うのではなく、AI エージェントを「強力な共同作業者」へと進化させる「スキル」の可能性。今回の探求は、その実現に向けた最初の一歩として、Gemini CLI における「司令塔スキル」の有効性を検証することに焦点を当てました。この旅の始まりを、ぜひあなたと共有したいと思います。
免責事項: この記事は、AIアシスタント（Google製 Gemini Pro）との対話を通じて生成されました。内容は、AIが実行したコマンドや分析結果に基づいていますが、一部にAIの解釈が含まれる可能性があります。
💡 後から人間追記: 使ったのは Gemini CLI で gemini-2.5-xxx モデルです。また、出力結果をベースに加筆修正しています。
はじめに
AIアシスタントは日々進化していますが、その能力を最大限に引き出す「スキル」という概念は、まだ私にとって未知のです。本記事では、 obra/superpowers: An agentic skills framework & software development methodology that works. というAIエージェントのスキル管理リポジトリを題材に、AIの「スキル」がどのように定義され、実行されるのかを、Gemini CLIと共に探求します。最終的には、その知識を応用して、Gemini CLIで動作する我々自身のカスタムスキルを作成するまでを記録します。
💡 後から人間追記: というよりも、 GitHub 29,000+ Star獲得！Claude Codeに「ベテランエンジニア」の思考を注入するSuperpowersプラグイン の記事を読んで興味を持ち、ただ、自分は gemini cli 使っているからダメか？そもそも Superpowers プラグインは Claude Code のどのような機能で実現しているのか？そもそも Claude Code 使ったことない、という疑問が背景です。
はじめに（この記事について）
この記事は、Gemini CLI を使って作業した最後に、一緒に行った作業をブログとして出力したものを大部分そのまま採用し、少し軌道等を修正したものです。
はじめに：なぜ今、Laravel 11のSlim Skeletonへ移行するのか？
このプロジェクトは、RESTful APIのバックエンドとシングルページアプリケーション（SPA）のフロントエンドを持つWebアプリケーションのボイラープレート（ひな形）です。Laravel9をベースに構築されていましたが、バージョン 11 までアップグレードし、この時に、Laravel 11が導入した「Slim Skeleton（合理化されたアプリケーション構造）」への移行を決断しました。
Laravel11では、従来のバージョンと比較して多くの設定ファイルやボイラープレートコードが削除され、よりミニマルで効率的な開発環境が提供されます。ドキュメントには「既存プロジェクトの移行は非推奨」という文面があります。ボイラープレートでなければ、このままの構造としたでしょう。一方で、ボイラープレートとしての使命は、常に最新のベストプラクティスと構造を提供することにあります。この抜本的な構造変更に対応することで、将来のメンテナンス性向上と、よりクリーンなコードベースを目指しました。
本稿では、AIエージェント（以下、AI）との対話を通じて、この挑戦的なアップグレード作業がどのように進められ、どのような困難に直面し、それをどう乗り越えたのかを詳細に記録します。特に、トライアル＆エラーのプロセスを厚く記述し、同様の移行を行う際の参考となることを狙っています。