Ponytail は、AI コーディングエージェント向けのかなり面白いプラグインです。
AI に派手な実装をさせるのではなく、その逆です。コードを書く前に一度止まり、削除で済まないか、既存コードを再利用できないか、標準ライブラリやブラウザ、プラットフォームの機能で解決できないかを確認させます。
プロジェクト:DietrichGebert/ponytail
こんな経験があるなら、Ponytail の考え方はかなり刺さります。
|
|
Ponytail の狙いは、AI を「怠け者だが信頼できるシニア開発者」のように振る舞わせ、まず最小変更を探させることです。
Ponytail とは
Ponytail は、AI コーディングエージェントに読ませる作業ルールのセットです。
コードを書く前に、次の階段を確認するよう促します。
|
|
これは code golf ではありません。短ければよいという話でもありません。無駄な作業を減らすための考え方です。消せるなら消し、再利用できるなら再利用し、ネイティブ機能で足りるなら車輪を再発明しない。
README には日付ピッカーの例があります。
普通の AI は flatpickr を入れ、wrapper を書き、スタイルを追加し、境界条件を説明し始めるかもしれません。
Ponytail 風なら、まずこれを考えます。
|
|
これが Ponytail が AI に身につけさせたい判断です。
解決するのは「短いコード」ではなく「過剰設計」
Ponytail は「AI に 1 行だけ書かせるもの」と誤解されやすいです。
より正確には、不要な設計を減らすものです。
安全境界は残します。必要な検証、エラー処理、セキュリティ処理、アクセシビリティを削ることは推奨しません。やるべきことはやる。ただし、小さな要求のために余計な複雑さを持ち込まない。
向いている場面は次の通りです。
- 小さなフロントエンド機能;
- フォームコントロール;
- 簡単なユーティリティ関数;
- 設定ファイルの調整;
- 小さな bug 修正;
- コードレビューでの過剰実装チェック;
- AI がコードを変更する前の制約追加;
- 既存実装を先に探させる作業。
次のように理解するのは違います。
- 常に 1 行だけ書く;
- 絶対に依存関係を増やさない;
- 絶対にリファクタリングしない;
- コード量を減らすために保守性を犠牲にする;
- 速さのためにコードを読まない。
Ponytail の要点は「実装には怠惰、読解には怠惰でない」です。
対応する AI コーディングツール
README によると、Ponytail は多くのツールに対応しています。
- Claude Code;
- Codex;
- GitHub Copilot CLI;
- Pi agent harness;
- OpenCode;
- Gemini CLI;
- Antigravity CLI;
- CodeWhale;
- Swival;
- OpenClaw;
- Cursor、Windsurf、Cline、Aider、Kiro、Zed などのルールファイル方式。
良い点は、メインの AI ツールを必ずしも変えなくてよいことです。
Codex を使っているなら Codex プラグインとして入れます。Claude Code なら Claude Code のプラグインマーケットを使います。エディタにルールだけ入れたい場合は、対応するルールファイルをコピーできます。
Codex で Ponytail をインストールする
Codex CLI の場合、README の入口は次の通りです。
|
|
その後、Codex 内で:
/pluginsを開く;- Ponytail marketplace を選ぶ;
- Ponytail をインストールする;
/hooksを開く;- 2つの lifecycle hooks を確認して信頼する;
- 新しい会話を開始する。
Codex デスクトップアプリでは、インストール後にアプリを再起動するとプラグインが認識されると README にあります。
注意点として、Ponytail の Claude Code / Codex プラグインは小さな Node.js lifecycle hooks を 2 つ実行するため、node が PATH にある必要があります。node がない場合でも skills は動きますが、always-on の自動有効化はされません。
まず確認します。
|
|
見つからない場合は Node.js を入れるか、非対話 shell の PATH から node が見えるようにします。
Claude Code でのインストール
Claude Code では次を使います。
|
|
次にもう一つ送ります。
|
|
README では、この 2 つを別々のメッセージとして送るように説明されています。
Claude デスクトップアプリで /plugin がない場合は、UI から personal plugin marketplace を追加します。
- Customize を開く;
- personal plugins の横にあるプラスをクリックする;
- プラグインを作成して marketplace を追加する;
- Add from repository を選ぶ;
- Ponytail の GitHub リポジトリ URL を入力する。
GitHub Copilot CLI でのインストール
Copilot CLI では次を使えます。
|
|
対話式の Copilot CLI セッション内でも slash command が使えます。
|
|
インストール後は、README にある Ponytail コマンドも使えます。
|
|
Gemini CLI と Antigravity CLI
Gemini CLI では次のコマンドです。
|
|
ルールセットが各セッションのコンテキストとして読み込まれ、/ponytail 関連コマンドが登録されます。
Antigravity CLI では:
|
|
README では、Google が Gemini CLI を Antigravity CLI に改名しつつあるとも説明されています。しばらくは両方の経路が存在する可能性があるので、自分が入れている CLI 名に合わせます。
OpenCode で使う
OpenCode では opencode.json に次を追加できます。
|
|
ローカル checkout から実行するなら、ローカルプラグインファイルを指せます。
|
|
OpenCode でプロジェクト設定を管理している場合に向いています。
ルールだけ使いたい場合
Ponytail リポジトリには、各ツール向けのルールファイルもあります。
例:
AGENTS.md;.cursor/rules/;.windsurf/rules/;.clinerules;.github/copilot-instructions.md;.kiro/steering/.
ツールがプロジェクト単位のルールを読めるなら、対応ファイルをコピーするだけでも使えます。
たとえば VS Code の Codex 拡張は AGENTS.md を読みます。Ponytail の AGENTS.md をプロジェクトルートやグローバル Codex 設定に置けば、Codex にこの考え方を守らせられます。
プラグイン方式はより完全で、ルールファイル方式は軽量です。
Ponytail と相性の良い指示
インストール後、完全に自動に任せるだけでなく、タスク内で方向を合わせると安定します。
例:
|
|
または:
|
|
コードレビューなら:
|
|
こうした指示は Ponytail のルールと同じ方向なので、結果が安定しやすくなります。
Ponytail に向いている典型タスク
1. フロントエンドコントロール
日付、色、ファイルアップロード、数値入力、スイッチ、セレクトなど。
AI はすぐにコンポーネントライブラリを入れがちですが、多くの場合はネイティブ HTML で十分です。
2. ユーティリティ関数
重複除去、ソート、フォーマット、パス処理、日付処理など。
標準ライブラリと既存 helper を見てから、新しい関数が必要かを判断します。
3. 設定変更
ESLint、TypeScript、Hugo、Vite、Docker、CI 設定など。
設定問題の多くは 1 行の変更で済み、新しいスクリプトやツールチェーンは不要です。
4. 小さな bug 修正
Ponytail は最小修正点を探すのに向いており、1 つの bug から大きなリファクタリングに広がるのを防ぎます。
5. コードレビュー
「過剰設計チェッカー」として使えます。
diff を見せて、次を確認させます。
- 車輪の再発明がないか;
- 不要な新規依存がないか;
- 直接削除できるコードがないか;
- 要求より複雑な実装になっていないか;
- 既存モジュールを再利用できないか。
注意点
Ponytail の方向は良いですが、新しい教条にしてはいけません。
次のようなものは、コードを減らすために削ってはいけません。
- 入力検証;
- 権限チェック;
- データ損失の防止;
- 並行処理とトランザクション安全性;
- ユーザープライバシー;
- アクセシビリティ;
- エラー処理;
- 重要ログ;
- テストカバレッジ。
シンプルと雑は違います。
セキュリティ境界、金銭、ユーザーデータ、本番操作に関わる機能では、最小実装でも境界処理を明確にする必要があります。
おすすめの試し方
初めて使うなら、次の順で試すのがよいです。
- 小さなプロジェクトでインストールする;
- 日付ピッカーや色選択のように AI が過剰実装しがちな要求で試す;
- Ponytail なしの結果と比較する;
- 既存 diff をレビューさせる;
- 最後に日常プロジェクトへ入れる。
いきなり大規模リファクタリングで試さない方がよいです。
Ponytail が最も効くのは、本来は小さいのに AI が大きくしがちなタスクです。
一言まとめ
Ponytail は AI を「短いコードしか書けないツール」にするものではありません。AI が手を動かす前に、もう一つ質問させるものです。
|
|
Codex、Claude Code、Copilot CLI、Gemini CLI などの AI コーディングエージェントを使っていて、過剰実装にうんざりしているなら、Ponytail は試す価値があります。すべての設計判断を代わりにしてくれるわけではありませんが、「まず再利用し、寄り道を減らし、車輪を再発明しない」という制約を AI に加えられます。