3ヶ月で13万スターまで伸びたOSS（ponytail、AIエージェント向けにプロンプトを最適化する仕組み）を調べた。結論は「自分には入れない」。理由は、自分の悩みと向きが逆だったからだ。
なぜ調べたか
GitHubで話題になっているリポジトリを見かけ、まず「これは何か」から確認した。読んでいるうちに、自分が開発でよくやる失敗を思い出した。無料のライブラリを使えばいいのに、使わず自前で書いてしまい、微妙な物ができあがる、という癖だ。この癖とponytailの相性を考えることにした。
やったこと
- READMEとルール本文まで読み込み、ponytailが「書かないコードが最高のコード」という思想で、新規の依存をなるべく避けよと明記していることを確認した
- 自分の課題（ライブラリを避けて自前実装してしまう）と照らすと、ponytailは同じ方向をさらに強める働きをすると気づいた
- 「なぜ自分はライブラリを避けるのか」を掘り下げた。ライブラリは実在するか・品質はどうかを確認するコストがかかるが、自前実装にはそのコストがない。だから確証を求めなくていい自前実装に流れやすい、という構造が見えた
決めたこと
ponytailは常時使う形では導入せず、見送った。代わりに2つの手を打つことにした。
1つ目は、自分の運用ルール文書に「汎用処理を自前で書く前に、既成のライブラリを一度調べて、使う・使わないとその理由を述べる」という一文を足す案。ルール文書には行数の上限があるが、まだ余裕はある。
2つ目は、話の途中で出てきた別の悩み「デザイン用のアセットをもっと積極的に使いたい」への対応だ。自作のデザインスキル（design-forge）の中身を調べると、素材の使い方について「量産感のある素材を使うと減点する」という規律で成り立っていた。ここに「アセットを積極的に使え」をそのまま書き足すと、スキル自体の一貫性が壊れる。既存スキルへの追記（矛盾）、新スキルを独立して作る（道具は共有）、既存スキルにモード分岐を足す、の3案を比べ、新スキルを独立して作る案を選んだ。
わかったこと
- 話題のOSSでも、自分の症状と方向が逆なら導入すべきではない。スター数はその判断材料にならない
- 概要だけでなくルール本文を最後まで読むと、概要では見落とす前提条件に気づける
- 既存のルールに何でも追記すると、そのルールが元々持っていた一貫性を壊すことがある。矛盾する方向性は、追記ではなく別のルールとして切り出す方が安全だ
次にやること
デザインアセットを積極活用する新スキルの設計に入る。方向性ごとに最適なデザインができるよう、まずは完成度の高いサイトの傾向を分類するところから始める。