はじめに
「Vimプラグイン、作りたいけど面倒くさい」「自分用で十分だから公開しなくていいや」
そう思っていた私が、あるツールとの出会いをきっかけに、構想からわずか2時間でプラグインを実装し、GitHubで公開するに至りました。
そのツールとは、Gemini CLI Conductor。そして Agent Skill です。
この記事では、エージェントが私の曖昧な意図を汲み取り、認識のズレを一切感じさせずにVimプラグインを開発したプロセスについて紹介します。
なぜ今まで作らなかったのか？
私はこれまでも、自分の .config/nvim 内で小さなモジュールを作ることはありました。しかし、それを「プラグイン」として切り出し、一般公開するには至っていませんでした。
- 技術的な障壁: ディレクトリ構成のお作法、Luaでのテスト環境構築、CIの設定などが面倒。
- 心理的な障壁: 「今使えているし、わざわざ公開するほどのものでもない」という面倒臭さ。
しかし、Gemini CLI の練習を進める中で、SKILLの確認頻度が異常に高かったので、「実験の場」としてSKILLをチェックコピーできるプラグイン作りをしてみることにしました。
会社のvimmerにも共有したかったので。。。
解決したかった課題
私は日々の開発で、AIエージェントの SKILL.md を多用しています。しかし、数が増えるにつれて「あれ、どんなSkillがあったけ？」と、oilプラグインでディレクトリを彷徨う時間が増えていました。
「TelescopeでSkillを爆速で検索して、
名前をコピーしたり挿入したりしたい！」
これが開発の動機付けとなりました。
開発を加速させた「Skill」と「Conductor」
「Conductor」とは？
今回の開発の鍵となったのは、Gemini CLI の拡張機能である Conductor です。Conductorは、単にコードを書くだけでなく、仕様策定 → 実装計画 → 実装 → テスト → 公開 という開発プロセス全体を指揮（Conduct）してくれる拡張機能です。
「Skill」とは？
「Skill」とは、AIエージェントに特定のタスクを遂行させるための、自然言語で書かれた手順書（Markdownファイル）のことです。これを必要な時に呼び出して使います。今回のプラグインは、まさにこの SKILL.md ファイル群を検索するためのものです。
「壁打ち」スキルが暗黙知を仕様に変える
私は漠然としたアイデアを持っていましたが、詳細な仕様は決まっていませんでした。そこで、独自に定義していた 「壁打ち（kabeuchi）」スキル を起動しました。
kabeuchi したい! 📗skill_getter_plugin.md を作ろうと思うんだけど、足りないところがまだあると思う。炙りだして!
（壁打ちスキル発動）承知しました。いくつか鋭いツッコミを入れさせてください。
- パフォーマンス: 毎回ファイルをパースすると遅くなりますが、起動時に非同期キャッシュしますか？
- アクション: コピーだけでいいんですか？ インサートやタブで開く機能は要りませんか？
- エラー処理: YAMLが壊れていたらどうしますか？ 通知を出しますか？
- 命名規則: 環境変数
ZETTELKASTEN_HOMEは不適切ではありませんか？SKILLS_DIRの方が汎用的です。
この kabeuchi スキル は、あらかじめ「辛口の技術レビュワー」としての振る舞いを定義した Markdown ファイル（SKILL.md）です。設計の穴を塞いでくれました。
Conductorによる「認知負荷ゼロ」の実装
壁打ちが終わると、Conductorは対話内容を元に spec.md（仕様書）と plan.md（実装計画書）を自動生成しました。
主観的感想ですが、以前使っていた Speckit などのツールと比べても、コンテキスト管理の認知負荷が圧倒的に低い と感じました。conductorは小さいプロジェクトに向いていると思います。
実装フェーズに入ると、Conductorは驚くべきことに TDD（テスト駆動開発） のサイクルを自律的に回し始めました。なぜなら、事前にプラグインの作成方法をスキル化させておいたからです。
- Skill: 「どのようにテストを書くべきか（plenary.bustedを使う等）」という技術的な「地図」を提供。
- Conductor: その地図に従い、「テスト作成→実装→修正」という手順を確実に遂行する「ドライバー」として機能。
Skillという「型」があったからこそ、Conductorは迷走することなく、最短距離でゴール（実装完了）まで走り切ることができたのです。
- Red: 失敗するテストを書く（
tests/parser_spec.lua） - Green: 実装コードを書く（
lua/skill-picker/parser.lua） - Refactor: エッジケースに対応する
私はターミナルでテストが通っていく様子を眺めているだけでした。
2時間で公開まで完了
こうして完成したのが telescope-skill-picker.nvim です。
開発のプロセス
SKILL.md)」を定義し、AIに開発の「型」を覚えさせる。📗skill_getter_plugin.md) へ昇華。spec.md と plan.md を生成。TDDサイクルを自律的に回して実装を完了。gh コマンドでGitHubへパブリックに公開。成果物や関連資料を WebFileBin で共有可能に。
「自分用ツール」として作り始めたはずが、AIとの対話を通じて自然とエラーハンドリングやドキュメント（README）が整備され、気付けば「公開できる品質」になっていました。
実際の動作画面：TelescopeでSkillを検索している様子
おわりに
今回の体験で、Vimプラグイン開発の敷居は、AIの力で限りなく低くなっていることを実感しました。
Vim界隈を盛り上げるためにも頭の片隅にあるアイデアや、ローカルにしかないモジュールを作って公開してみてください？