エージェントのルールを楽に管理したい
結論
mizchiさんのこちらのリポジトリが最高！
これを僕の利用がっての良い形に少し変えたという感じになります。
経緯
先人たちの知恵を拝借し、rulesファイルを作成すれば自分の思い通りの結果にたどり着きやすいとは思ったものの、開発内容を書くだけではなく、gitにアクセスするためのルールだったり、エージェントがやっていいこと/ダメなことをこちらで決めないとかなり自由な行動をするので、その都度ルールを決める必要が出てきました。
しかしながら場当たり的に一つ一つ考えていくとどんどんrulesファイルが大きくなっていきます。。
そこで、開発タスク単位でマークダウンを作りそれらを自分の必要な作業に応じて組み合わせ1つのrulesファイルを作るということを自分なりにしてみようと思いました。
僕はエディタはcursorですが、clineをエージェントとして利用しています。それを前提で記載しているのですが他のエージェントもさほど変わりはないと思いますので参考になれば幸いです。
ルールが必要だったタスク
基本的な動作内容
よくある . がつく設定ファイルは読み込み・書き込み・削除それぞれされたくないのでルールとして書く必要がありました。
これを書かないと読み込みどころか削除までしてくるのでなかなかアグレッシブなことをしてくるなぁと笑っちゃいました。clineが悪いというわけではなく、されたくないことはあらかじめ表現して伝えないといけないと感じています。
逆にセキュリティ要件のようなものは確実に実施した方が良いので、そのような対策は実施するように表現しておくのも必要だと思います。
開発言語/環境ごとのコーディングルール
プロジェクトの中で利用している開発言語も開発物によって多少変わったり、特にフレームワークはバラバラになっていることが多いと思います。ですので、プロジェクト単位でコーディングルールを考えるよりは、言語とフレームワーク/パッケージの組み合わせでルールをあらかじめ用意しておいて、それらを組み合わせた方が楽だと思いました。
これは先人の知恵がかなり有用でこちらのリポジトリよりヒントを得られました。
このリポジトリでは、言語やフレームワーク/パッケージなどの組み合わせ別にルールファイルが存在しています。自分の都合の良い粒度に合わせてマークダウンを作り、それを組み合わせるというアプローチは可能なのだなと思ったきっかけになりました。
コミットメッセージ
エージェントを利用して開発した内容について、一つ一つ確認を取ることもなかなか手間のかかる作業だったりします。
自分で手を動かしてコーディングするならまだしも、差分だけ確認してぱっと見て理解できるなら良いのですが、なかなかそれもぱっと見でわからないコードが混じるとなんのことやらわからずApproveしてしまうこともあったりします。そこでコミットメッセージにより何のファイルに何をしたという記述が欲しいと思い至り、メッセージにもこだわりが出てきました。
コミットメッセージ用の設定には、前述している通りコミットメッセージさえ見れば何をやったか大体わかるという内容を書くことを表現しています。エージェントで編集していると、何をしているのかログが出てくるのですが、そのログも素早く流れてしまうことの方が多くなってきたので、コミットメッセージという最終的な業務報告があれば後で見返した時にも安心できると考えています。
ルールを結合するツール
結論にも書いた通りですが、ルールを結合するというアイデアも先人の知恵を拝借しています。
こちらのリポジトリでは、clineのルールを結合するためのコードが用意されていました。先程の言語とフレームワーク/パッケージごとのルールファイルですと、その組み合わせに応じてかなりの量を書かなければなりませんが、結合して作るとなるとそれぞれ必要な部分だけを抽出して効率的にルールファイルを作成できます。
僕の場合だと、基本的な動作+開発内容+コミットメッセージの組み合わせでruleファイルを作れば良いのだなと思いました。
ルールをまとめて一つのrulesファイルを作成する
こちらが僕の作成したリポジトリになります。goで作成したコマンドツールです。
rules cline frontend
たとえばこのようなコマンドで .clinerules にfrontendのルールが書き込まれるといった感じです。frontendのルールはマークダウン形式で用意しておいて、そのパスを環境変数にあらかじめ設定しておくという使い方になっています。
先ほどの僕が必要としている組み合わせで考えると・・
rules cline go-cli-tool basic commit
こんな感じのコマンドを叩くと、それぞれでルールを決めておいたマークダウンを読み込んで .clinerules を作れるといった感じです。
clineの部分をcursorにしたり、windsurfにしたりすると .cursorrules や .windsurfrules になるといった形です。
ルールの作成
プロンプトにはお金も関わるし、先人が知恵までに至るにはかなりの試行錯誤があったりしますので最初の一歩目ははおんぶに抱っこでそのまま使わせていただいておりました。
ただ、自分の事情が入り混じってくると補えない点というものがでてくるので、今の僕の場合はほとんど claude 3.7 sonnet で調整案を出してもらって、それを実際にプロンプトを使ってみて微調整を加えていく感じです。
それでもなんかおかしいとか思った際は先人の知恵を拝借しにいくのですが丸々使うというよりは自分の気持ちで微調整して行った方が納得感が強くなる傾向があるなぁと作業していて思いました。
おわりに
一回自分が納得いくルールはさほど大きな修正はせず微調整していくことの方が多いのですが、rulesファイル自体は結構巨大になり気味になるのでエージェントに依頼するタスク単位で細かく管理をしておけば後々楽になるのかな？というルールの収納術みたいな記事になったなぁと思いました。
ルールの管理はエージェント側でもなにかしら管理機能が付いたらいいなぁっていう期待もあったりしますが一旦自分なりの解決策ができてよかったなって思いました。
Discussion