AIエージェントと開発しているリポジトリのAGENTS.md（エージェント向けのルール）を公開します。 構成のポイントは、AGENTS.mdを「入口」に徹させることです。詳しい手順は作業の種類ごとの手順書に分け、「この作業をするときは、この手順書を読む」という条件だけを書いています。 【基本方針】
• 必要な動作と理解を保ったうえで、コードとドキュメントは最小限にする。既存の実装や資料を再利用し、重複を作らない 
• いまの要件に合う、最も単純な設計を選ぶ。将来の可能性だけを理由に、抽象化・汎用化・依存を増やさない 
• 補助スクリプトや設定を足すのは、既存の仕組みでは足りず、繰り返しの利用やミス防止の効果が保守の負担に見合うときだけ。その場限りの検証はGit管理外で行う 
• 確認済みの事実、未確認の事項、未決定の事項を区別して報告する 
• 技術選定や慣例について、外部の仕様や推奨が判断に影響するときは、依頼を待たずに調査専用のサブエージェントへ任せる。結果を既存の実装と照らし合わせてから決める 【作業の種類ごとに手順書を読ませる】
• 機能追加・動作変更（小さな変更も含む）、不具合修正、動作を保つリファクタリングは、それぞれ専用の手順書に従う。リファクタリングに動作変更が混ざる場合は、PRを分ける 
• 性能の問題は、まだ計測していなくても、性能調査の手順から始める 
• 画面・導線・通知・文言の変更にはUXライティングの手順書を使う。外部向けREST APIは公開契約とエラー形式の手順書、API層（tRPC）の変更はその手順書を使う。いずれも設計時と検証時の両方で読む 
• DBスキーマの変更や一括処理では、カラムの根拠、移行と検証の方法、処理量とメモリ使用量を確認する 
• 認証・認可に関わる変更は、設計前と検証時に専用の手順書を使う。データの取得経路、公開範囲、セッションの寿命に加え、キャッシュ・エクスポート・バックグラウンド処理も対象に含める 
• 依存関係の変更時や、セキュリティ警告を検知したときは、脆弱性対応の手順を読む 
• 機能追加や調査のときは観測性の手順を読み、行動解析が必要かどうかも設計時に判断する 
• 中断した作業の再開や引継ぎでは、最初に現在の成果物、残りの作業、検証が有効な範囲を確認する 【PR・コミット・マージ】
• PRは「1つの目的を、前提が揃った状態で検証・マージできる最小単位」にする。依存するPRには、参照先とマージ順を書く 
• PRには実際の動作確認の結果を書く。画面に影響する変更には、実画面のスクリーンショットを付ける 
• コミットメッセージは type(scope): 日本語の説明 の形式。scopeは必須 
• マージはsquash merge。PRタイトルをそのままコミットタイトルにし、本文には必要な理由だけを書く 
• 自動マージしてよいのは、文書とテストの変更、動作を変えない整理、互換性を保つ依存更新だけ。対象かどうかは、ファイル名ではなく実際の影響で判断する 
• 自動マージの前に、最新のheadで検証と独立レビューを終え、その証跡をPRに残す。headが変わったら自動マージを解除し、確認をやり直す 
• 次の変更は自動マージせず、必ず人間の承認を取る：認証・権限・個人情報・秘密情報、データ破壊やスキーマ、本番インフラやデプロイ、外部送信や課金、CIや運用規約、依存のMAJOR更新、影響が分からない変更、そして自動マージ規約そのものの変更 【ドキュメントとコード】
• コードの中にコメントを書かない。説明が必要なら、より良い名前かテストに置き換え、外部の事実は設計ドキュメントに書く。例外はlintで固定する 
• ドキュメントを足す前に、コード・設定・既存の資料を確認する。一般知識は書かず、原典はリンクと版で参照する 
• READMEには、目的、始め方、正本への導線だけを書く。package.jsonを見れば分かることは書かない 
• ドキュメントと既存コードが食い違ったら、既存コードに従う。見つけた食い違いは、最後の報告ですべて挙げる 
• バージョンはSemVerに従い、リリースのときだけ上げる 
• importを変えたら、依存方向のチェックで逆向きの参照や循環がないことを確認する 【開発環境】
• ローカルの検証用DBやサーバーはコンテナで立てる。共有DBや本番の操作、外部への公開には、個別の承認を取る 
• 作業が終わったら、自分が作ったプロセスと検証用の資源だけを片づける