私のPythonプロジェクトの最初のコミットから、他のどのルールよりも重要だったルールが一つあります。それは、コーディングエージェントに受け入れ基準を決して見せないことです。そこで、互いに情報を交換しない二つのエージェントを作りました。一方は完全な仕様からテストを書き、もう一方は基準を取り除いた同じ仕様からコードを書きます。多くのコーディング環境では同じエージェントが両方を書くため、テスト結果の妥当性が損なわれます。
私は、その切り離しをコンテキストの組み立て、つまりコーディングエージェントのプロンプトを構築する工程で、コードによって強制しました。プロンプトを組み立てる前に、タスクファイルの基準セクションを取り除きます。しばらくの間、この切り離しは完璧だと思っていました。ところが、コメント行が一つあるだけでそれが壊れることがわかりました。切り離しはそこで止まり、コメント以降のすべての基準がコーディングエージェントに届いていたのです。一週間後には、二行目にまたがって書かれた基準でも同じことが起きました。どちらのバグも私自身の過ちでした。今回は修正に加えてテストを追加し、切り離しが意図どおりに適用されなければ、今後のビルドが失敗するようにしました。
SkillとMCPサーバーはよく比較されますが、私のプロジェクトが依存しているルールに関しては、どちらでもないという答えになりました。私は、ユーザーがClaude CodeやCursorのようなAIアシスタントから、私のコマンドラインツールqikly を利用できるようにしたかったのです。そうなると二つのLLMが関わることになり、どちらも受け入れ基準を見てはいけません。アシスタントはqiklyを実行できましたが、いつ使うべきかを知りませんでした。そこで私はSkillを書きました。これは、リクエストがその説明に一致したときにアシスタントが読み込む、Markdownの指示をまとめたフォルダです。
Skillを書いたことで、二つの役割が明確に分かれました。Skillの役割は、何を要件に書き、何を受け入れ基準に書くべきかについて助言することです。これは教えることはできても、保証することはできません。コンテキストの組み立ての役割は、Skillがインストールされているかどうかにかかわらず、毎回基準を取り除くことです。とはいえ助言にも意味はあります。要件にも書かれた基準は、いずれにせよコーディングエージェントに届くからです。そこで私は、そのような重複を警告するチェックをqikly --validateに追加しました。
よくある質問
質問：LLMに基準を見せないようにするために、より優れたモデルや温度ゼロに頼ってはいけないのはなぜですか？
回答：より優れたモデルは指示に従うことが多いものの、常にとは限りません。温度をゼロにすると回答は再現性が高くなりますが、より従順になるわけではありません。常に守られるべきルールは、コンテキストの組み立てのようにコードで強制すべきです。一方、判断を伴う指針はSkillに置くことができます。
出典: Towards Data Science · 要約：HeadlinesBriefing