エージェント準備監査は何をしますか？

以下のチェックリストに基づいて現在のリポジトリを監査し、ギャップを報告します。これは読み取り専用監査であり、リポジトリファイルを決して変更、作成、削除しないでください。

ステップ 1: スタックを発見する

評価を下す前に、以下を特定します:

言語、フレームワーク、パッケージマネージャー、モノレポ構造
使用中のリンター、フォーマッター、型チェッカー
テストランナー
フックマネージャー（husky、lefthook、pre-commit、simple-git-hooks、プレーンな.git/hooks）
CIシステムとその設定
エージェント指示ファイル（AGENTS.md、CLAUDE.md、.cursorrules、copilot-instructionsなど）
スキル、ランブック、プロンプト、ワークフロードキュメントを含むディレクトリ

このリポジトリが実際に使用しているツールを使用して評価します。現在のツールで対応できない場合を除き、ツールの交換は推奨しないでください。

予算

ディレクトリ一覧、設定ファイル、指示ファイルから始めてください。ソースファイルをすべて読む代わりに、grep、カウント、ファイル一覧を使用してください。
主要パッケージごとに、代表的なファイルを最大3つまでサンプリングしてください。
リポジトリが大きすぎてカバーできない場合は、どの部分を調査しなかったかを明記してください。

ステップ 2: 各チェックリスト項目を評価する

各項目に1つのステータスを割り当てます:

PASS: 明確に整備されており、機能している
PARTIAL: 存在するが不完全、古い、強制されていない、または一貫性がない
MISSING: 確認したが存在しない
N/A: このスタックには該当しない（理由を述べてください）
UNCLEAR: 確認できなかった（何が妨げになったか、例：外部CIや調査しなかったリポジトリの部分を明記してください）

すべてのステータスに証拠（ファイルパス、設定キー、15語未満の短い引用スニペット）を添えてください。推測はしないでください。確認して何も見つからなかった場合はMISSINGとマークし、確認できなかった場合はUNCLEARとマークしてください。

チェックリスト

共有エージェント指示
- すべてのエージェントと新規エンジニアが読む単一のルートレベル指示ファイル
- コードスタイルルール（エクスポートスタイル、インポート構造、ファイル構成、アンチパターン）をカバーしている
- 信頼境界での外部データの検証を必須としている
- どのテストを書く価値があるかを示している
- 完了ゲートを定義している：コミット前にlint、型チェック、関連テストが合格する必要がある
- 最新かつ具体的である。3〜5個のルールを実際のコードに対してスポットチェックし、コードがそれらに従っているかを報告する
リポジトリ内のワークフロースキル
- コードと並行して、繰り返し発生するワークフローがステップバイステップのスキルまたはランブックとして文書化されている
- カバレッジ：コミット、PRのオープン/スタッキング、コードレビュー、CIを通したPRの通過、依存関係の変更、ローカライゼーション
- スタック固有のワークフローがカバーされている（データレイヤー、ルーター、デザインシステム、コード生成など）
- 各スキルにトリガー、順序付けられたステップ、完了の定義がある
- スキルは唯一の真実の情報源であり、重複や矛盾がない
lintルールとして強制されている規約
- 文書化された規約に対応するlintルールがある
- カスタムlintルールまたはプラグインがプロジェクト固有の使用法（データ取得、スタイリング、テスト、翻訳）をカバーしている
- エージェントの一般的なミスに対するアンチパターンルールが存在する：連鎖または不要な型アサーション、疎に型指定されたパラメータ（unknown/any）、空のオブジェクトの条件付きスプレッド、およびこのコードベースで見つかった繰り返し発生する低品質パターン
- ルールはエラーであり、警告ではなく、一律の無効化がない
自動化ゲート
- pre-commitフックが変更されたコードをフォーマット、lint、型チェックする
- pre-pushフックが変更されたパッケージとその依存関係を含むパッケージをlintまたはテストする
- CIが同じチェックを再実行するため、フックを迂回できない
- フックは合理的に高速である
- フックが配線されている：フック設定がコミットされており、インストール手順（prepareスクリプト、セットアップドキュメント、またはcore.hooksPath）が存在し、呼び出すコマンドが存在する。ファイルを読んで確認すること。フックを実行しないでください。
監視と構造
- アーキテクチャ上の決定が文書化されている
- マージ前にPRレビューが必要（ブランチ保護またはCODEOWNERSが可視であれば確認）
- パッケージとモジュールの境界が明確で強制されている

ステップ 3: 文書化されていない規約を見つける

コードから、一貫して適用されているがどこにも文書化されていないパターン、およびエージェントがよく間違えるパターン（疎な型付け、未検証の外部データ、一貫性のないエクスポート、重複したロジック）をサンプリングします。上位5つの候補をリストアップし、指示ファイルに追加するか、lintルールに変換することを提案します。

ステップ 4: 報告

以下を作成します:

サマリーテーブル：項目、ステータス、一行の証拠
「ギャップ」セクション：PARTIAL、MISSING、またはUNCLEARの各項目、何が問題か、そしてそれがエージェントの信頼性にとってなぜ重要か
優先順位付けされた推奨事項リスト（最も効果の高いものから順に）、それぞれに具体的な次のステップとおおよその労力（小/中/大）を、このリポジトリの既存ツールの観点で記述
ステップ3からの上位5つの規約候補

直接的であること。称賛で水増ししないこと。問題がなければPASSと言って次に進んでください。

レポートの後、不足している部分（スターター指示ファイル、スキルテンプレート、lintルールスタブ）をスキャフォールディングする提案を提供しますが、依頼されるまでは何も作成しないでください。

エージェント準備監査