カスタムエージェントはベータ版です。動作や画面は今後変わる可能性があります。
1 つの関心事に 1 つのエージェント
アーキテクチャ、セキュリティ、テストカバレッジを一度に見るエージェントは、曖昧な指示を持ち、曖昧な指摘を返します。分割してください。関心事ごとに 1 つのエージェントを作り、それぞれにファイル、ガイド、タグを持たせます。タグで誰の発言かがわかり、各エージェントのページに過去 30 日間の投稿が表示されるので、どのエージェントがうるさいかがわかります。焦点を絞った指示を書く
指示は、コードベースを知るレビュアーへのブリーフとして書きます。次の 3 点をカバーしてください。- 何を探すかを具体的に：「アーキテクチャの問題」ではなく「
src/domainからsrc/httpへの import」。 - 何を無視するか：スタイル、命名、他のエージェントや Kody がすでにカバーしていること。
- 指摘にどんな証拠が必要か：「既存のパターンを示すファイルを挙げる」「ソースからシンクまでの経路を示す」「
docs/ledger.mdのルールを引用する」。
- 曖昧
- 焦点が明確
指摘に必要な証拠を書く
指摘は投稿前にチェックされます。エージェントが証明できるものを与えてください。- ガイドのルール：doc や skill を紐付け、ルールを引用するよう指示します。引用はターゲットブランチのガイドで確認されます。
- CLI の結果：ファイルを名指しする CLI 出力の行が、証拠としてコメントに入ります。
- ast-grep ルール：マッチはそれ自体が証拠で、モデルによるチェックは不要です。
glob を明示する
- Files にはエージェントが気にするコードを設定します。空ではなく
src/payments/**のように。glob のないエージェントはすべてのプルリクエストで実行されます。 - テスト、フィクスチャ、生成コードには Except を使います。
- 無視パスにあるがエージェントには読ませたいファイルは、明示的に名指しします：
package.json、infra/**/*.tf。**/*.tsのような広い glob やsrc/**のようなフォルダ指定は、無視されたファイルに届きません。 - ディレクトリレベルでも、glob はリポジトリのルートから書きます。
Skill か doc か
docs はエージェントごとに 20,000 トークンの予算を消費します。長いハンドブックは、参照ファイル付きの skill にするほうが適しています。
オンにする前に実際のプルリクエストで試す
新しいエージェントはオフで始まります。オンにする前に：- エージェントのファイルに触れる最近のプルリクエストを選びます。良いレビュアーなら何を言うか分かっているものが理想です。
- Try it を実行します。ツール呼び出し、開いた skills、すべての指摘を読みます。
- 指示、glob、最小重大度を調整して、再実行します。
- 投稿されるコメントがプルリクエストに付いてほしいものになったら、オンにします。
@kody -v <名前> は、エージェントがまだオフの状態で、実際のプルリクエストに同じことを行い、コメントを投稿します。
破棄の理由を読む
破棄された指摘は、エージェントの何を直すべきかを教えてくれます。量を適切に保つ
- 重複コードのエージェントのように多くの指摘を出しうるものには Max comments per pull request を設定します。重大度の高いものが残ります。
- カバレッジレポートのように、まとめて読むほうがよい指摘には One PR comment を使います。
- アーキテクチャの移動のように修正が推測になる場合は Suggested fix: Never を使います。