実装済みコードを3段階でセルフレビュー・自動修正

大きなコード変更を、別の独立したAIコンテキストから客観的にレビューして問題がないか確認できます 変更規模に応じて自動判定（小規模なら自己レビュー、大規模ならサブエージェント活用）して効率的にレビューします 重大な問題・軽微な問題・問題なしを判定して、修正が必要か完了可能かを明確にします 問題が見つかった場合は自動で修正→再レビューループを回し、LGTM判定になるまで繰り返します コミット前に変更内容を客観的に確認したい開発者 コードレビュー品質を高めたいチームリード 重大な不具合をコミット前に防ぎたいプロジェクト このスキルは、タスク完了前に実行するセルフレビュー手順です。トリガーは /self-review コマンドまたは大きな変更をコミットする前です。4つのフェーズで構成されています。Phase 1 で変更差分を収集（git diff で変更ファイルと内容を取得）、Phase 2 でサブエージェント（code-reviewer）によるレビューを実行（ただし変更規模が30行以下の場合はサブエージェント不要）、Phase 3 で判定（LGTM=PASS、軽微な問題=MINOR、重大な問題=FAIL）、Phase 4 で FAIL の場合は修正→Phase 1-3 再実行を繰り返します。変更規模別に調整可能で、30行以下は自己レビューのみ、31-100行は code-reviewer サブエージェント、100行以上は詳細分析を加えます。

Bridge Server（TypeScript）のユニットテスト実行、TypeScript型チェック、カバレッジ測定を順番に実行し、全てのテストがパスすることを自動確認できます。 テストファイルのみを指定したり、ウォッチモード（開発中は自動再実行）で効率的にテストを回すことができます。テストファイルと型チェック対象の関係を正確に管理します。 vitest規約に基づいたテスト記述方法（ファイル配置・命名・import・テスト構造）の標準を適用し、チーム全体で一貫性のあるテストコードを保証します。 parser.ts、claude-process.ts、image-store.tsなど、現在テスト対象のモジュールを管理し、新しく純粋関数が追加される際のテスト追加ガイダンスを提供します。 外部依存（プロセスspawn・ファイルシステム・WebSocket）を除いた、ROIの高い純粋ロジックのテストに集中できます。 Bridge Server開発でコード品質を保ちながら継続的にテストを実行したい開発チーム TypeScriptの型チェックとテスト自動化で本番バグを事前に防ぎたい品質管理者 テスト記述規約を統一して、チーム内の開発効率と保守性を向上させたい技術リード 新機能追加時に既存機能の回帰テストを確保したいCI/CD環境構築者 Bridge Server（TypeScript）のテスト実行・型チェック・テスト記述ガイド。実行手順①ユニットテスト（npm run test:bridge、特定ファイル指定可、ウォッチモード対応）②TypeScript型チェック（npx tsc --noEmit、テストファイルと vitest.config.ts は tsconfig.json の exclude に含まれ型チェック対象外）③カバレッジ測定（任意）。テスト記述規約：ファイルはソースと同ディレクトリに .test.ts 配置、vitest のみ import（jest互換は不可）、テスト対象モジュールは .js 拡張子で import（NodeNext moduleResolution）、describe でグルーピング・it は英語三人称現在形・1つの it は1振る舞い検証。テスト対象は純粋関数・ロジック中心（高ROI）。現在テスト対象モジュール：parseClaudeEvent、claudeEventToServerMessage、parseClientMessage（parser.ts）、parseRule、matchesSessionRule、buildSessionRule、toolNeedsApproval（claude-process.ts）、ImageStore.extractImagePaths（image-store.ts）。新テスト追加時は純粋関数があれば追加検討、internal関数テストは export に変更OK。

設計書・ヒアリングシート・アーキテクチャ説明を多角的にレビュー：AWS Well-Architected フレームワークの6つの視点（信頼性、セキュリティ、コスト最適化、運用上の優秀性、パフォーマンス効率、持続可能性）から包括的に分析し、改善案をレポート化します。 AWSベストプラクティスとの整合性を自動検証：最新のAWSドキュメントやサービス仕様と照合し、推測ではなく公式情報に基づいた指摘を提供します。 平易な説明とエンジニア向け詳細の両立：技術レベルに依存しない図解と、実装根拠となる詳細なドキュメントリンクを同時に提示します。 リージョン可用性やサービス最新機能を自動確認：新機能やリージョン対応状況を都度確認し、古い情報に基づく指摘を排除します。 非機能要件IPA分類とW-Aの柱の対応を自動マッピング：設計の品質要件を構造化し、どの柱でカバーされているか明確にします。 クラウドアーキテクト・ソリューションアーキテクト：新規プロジェクトの設計レビュー、既存システム改善の根拠提示に 開発チームリード・PMO：AWSベストプラクティス準拠をスケーラブルに検証したい セキュリティ・コンプライアンス担当：セキュリティ要件、コスト削減余地、リスク評価を構造化したい クラウド移行プロジェクト推進者：移行後の設計が大規模採用に耐えられるか定量的に判定したい AWS Well-Architected フレームワークの6本の柱に基づいてレビューを実施。対象は本リポジトリの設計テンプレート（design/doc_source/）、ヒアリングシート（survey/doc_source/）、ワークショップ資料（workshop/doc_source/）。ワークフローは①入力理解（ファイルパスまたはトピック名から対象を特定）、②ドキュメント読み込み（Glob・Read・Grep ツール活用）、③AWS最新ベストプラクティス確認（aws-knowledge MCPで Well-Architected・サービス固有・最新アップデート・リージョン可用性を検索）、④6本の柱による分析（非機能要件カテゴリ定義を参照して対応関係を確認）。出力は日本語で統一、AWS サービス名は英語表記のまま。AWS ドキュメントリンクは英語版URLを使用。