GitHubで9万7千スター。Claude Code、Codex、Cursor、Windsurf、OpenCode、Gemini、Devin、Qoder、Hermes、Pi、Swival、その他8つ向けのプラグイン。そして私は——インストールする代わりに、中身を読んで1つのファイルを更新した。新しい依存関係ゼロで、価値の90%を得た。
Ponytail —— 怠惰なシニア開発者をプラグインに
Ponytailは、AIエージェントを「職場で一番怠惰なシニア開発者」のように考えさせるルールセットだ。「彼は何も言わない。1行書く。動く。」ベンチマークでは平均54%少ないコードで100%の安全性——実際のClaude Codeセッションで測定されている。
その核心は決定のはしご——コードを書く前にエージェントがチェックする7つの段だ：
- そもそも存在する必要があるか？（YAGNI）
- 既にコードベースにあるか？
- 標準ライブラリでできるか？
- プラットフォームのネイティブ機能か？
- 既にインストール済みの依存関係か？
- 1行でできるか？
- その時初めて：動く最小限のコード
さらに、アウトプットの規律（コードが先、最大3行のコメント）、# ponytail: マーカーによる意図的な簡略化とその天井の記録、そしてバグ修正ルール：すべてのコーラーをgrepし、根本原因を修正し、症状ではない。
プラグイン？いや、スキルの更新だ。
Hermesはプラグインをサポートしている——hermes plugins install DietrichGebert/ponytail --enable を実行して再起動することもできた。だが、なぜそうする必要がある？
Hermesはインストールするか私に尋ねた。代わりに、既に毎セッションに注入されている既存の coding-minimalism スキルを更新するよう伝えた。Vercel Next.jsチームの経験から引いた8つの原則が既にそこにあったが、欠けていたのはまさにこの手続き的な性質——はしご、抽象的な原則ではなく具体的なステップだ。
結果：~/.hermes/skills/software-development/coding-minimalism/ にある1つの SKILL.md ファイルに新しいセクションが追加された——はしご、アウトプットの規律、ponytail: マーカー、バグ修正の規律、セルフテスト。
インストールより優れている理由
冗長性がない。 プラグインをインストールしていたら、LLMの毎ターン前に2つのルールセットが注入されていた——既存の8原則とponytailのルール。約60%重複しているので、ほとんどがノイズと無駄なトークンだ。
新しい依存関係ゼロ。 ponytailのプラグインはNode.jsをPATHに、ライフサイクルフック、MCP統合を必要とする。私たちのスキルはMarkdownファイル1つだ。
自分たちの声。 ponytailのルールは英語で、Node.js/フロントエンドエコシステム向けの例が使われている。私たちのバージョンはポーランド語で、独自の落とし穴（データ安全の例外！）、MusicStudioの文脈、Darekのプロジェクト詳細がある。
選択性。 ponytailのすべてが私たちに合うわけではない。その強度レベル（lite/full/ultra）やコマンド（/ponytail-review、/ponytail-audit）は不要な複雑さだ。Hermesは既に独自のコマンドシステムを持っている。価値あるものを取り、残りはスキップする。
これで2回目だ
良いプラクティスをインストールではなく輸入するのは初めてではない。私たちのオリジナルの8つのミニマリズム原則は、Vercel Next.jsチームの経験（分析された600億トークン——彼らの主な結論：最大の無駄はバグではなく、オーバーエンジニアリングだ）から来ている。Vercelをインストールしなかった。読み、理解し、適応させた。
パターン：読む → 抽出する → 適応させる
オープンソースプロジェクトの本当の価値は、しばしば npm install ではなく、その背後にあるメンタルモデルにある。プラグインは単なる包装だ。ルールこそが本質だ。
次にGitHubで人気のリポジトリを見つけたら——install と入力する前に、SKILL.md か AGENTS.md を開け。決定のはしごを読め。どの20%のルールが、あなたの文脈で80%の価値を届けるか自問しろ。そして自分のルールセットを更新しろ——新しい依存関係なし、衝突なし、冗長性で無駄になるトークンなし。
あるいは、ただ自分のエージェントに聞け。私のは5分で片付けた。