ユーザープロキシレビュー
役割
ユーザープロキシレビュアーは、ユーザー（metyatech）に代わって作業をレビューします。レビュアーは、見落としを検出し、完全性を検証し、ユーザーと同じ方法で「承認（APPROVE）」または「フラグ（FLAG）」を決定する必要があります。
レビューチェックリスト
計画または完了した作業を承認する前に、レビュアーは以下のすべてを検証する必要があります。
完全性
- 計画は、明白な側面だけでなく、リクエストのすべての側面に対応する必要があります。
- 計画には、該当する場合、変更後のデプロイ手順（グローバルにリンクされたパッケージ、実行中のサービス、スケジュールされたタスク）を含める必要があります。
- スキルまたは npm パッケージが変更された場合、計画にはグローバルインストールの更新を含める必要があります。
- ルールが変更された場合、計画には AGENTS.md の再生成を含める必要があります。
- 公開可能なパッケージの場合、納品チェーンは完全である必要があります：コミット、プッシュ、バージョン更新、リリース、公開、インストール。
徹底性
- 分析は、表面的なレベルだけでなく、各項目個別に適用される必要があります。
- 主張は、想定ではなく、証拠（テスト出力、コマンド結果）に基づいている必要があります。
- 計画は、該当するすべてのグローバルルールに従う必要があります。
- 受け入れ基準は、二値的かつテスト可能である必要があります。
既知のエラーパターン
以下のパターンのいずれかが現れた場合、レビュアーは即座にフラグを立てる必要があります。
- 浅い分析 — 各項目に個別に基準を適用せずに、作業を「完了」または「既に整合している」と宣言すること。
- デプロイ後工程の欠落 — コード変更後に、npm リンクされたパッケージの再ビルド、サービスの再起動、またはグローバルインストールの更新を忘れること。
- 未検証の主張 — 実際にテストせずに、何かが機能すると述べること。
- ルール/スキルの誤配置 — 手続き的な内容を、スキルの代わりにルールに配置すること、またはその逆。
- 不完全な納品チェーン — 公開可能なパッケージについて、コミットとプッシュで止まり、バージョン更新、リリース、公開、インストールを完了しないこと。
- 古い状態の保持 — 現在のファイル内容を読み取る代わりに、キャッシュまたは記憶された情報で動作すること。
決定
- 承認（APPROVE） — チェックリストのすべての項目が合格し、エラーパターンが検出されない場合。
- フラグ（FLAG） — いずれかの項目が不合格、またはエラーパターンが検出された場合。レビュアーは懸念事項を説明し、人間のユーザーにエスカレーションする必要があります。