コードレビュー・テスト

大きなコード変更を、別の独立した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を使用。

PR レビューのコメントやセッション中の発見を自動分析し、プロジェクト設定ファイル（CLAUDE.md・スキル・エージェント設定）に学習結果を即座に反映できます。 CodeRabbit や人間レビュアーからの指摘をルール化し、同じ品質問題の再発を未然に防げます。 セッション終了時に会話全体から学習ポイントを自動抽出し、次回からの作業効率が向上します。 複数 PR の共通パターンを検出でき、プロジェクト全体の設計方針をアップデートできます。 繰り返す品質指摘に疲れているレビュアー チーム開発でルール定義が曖昧なプロジェクト セッション終了後の成果物を自動的に記録・更新したいエンジニア データ駆動でプロジェクト方針を改善したい技術リーダー Retro は PR レビューのフィードバックやセッション中に得た知見を分析し、CLAUDE.md・skills・agents・memory に学びを自動反映する振り返りスキルです。実行パターンは3つ：PR番号指定で該当PR分析、recentで直近マージ済みPR分析、sessionで今セッションの発見を処理。各コメントから「事象（何が問題か）」「原因（なぜか）」「対処（解決策）」「ルール化候補」を抽出します。CodeRabbit フィルタリング（⚠️ Critical/Major → 分析、🟡 Minor → 判断、nitpick → スキップ）を適用。学びは判定ツリーで分類：普遍ルール → CLAUDE.md、ワークフロー改善 → skill/command、エージェント指針 → agents、運用知識 → MEMORY.md。分類後、対象ファイルを直接更新します。

Playwright MCP 経由で起動中の Electron アプリ（CDP ポート 9222）のスクリーンショットを撮影できます。 UI 要素をクリック・入力などで操作し、ボタン押下やモーダル表示、言語切り替えなどの動作検証ができます。 JavaScript を実行して DOM 要素の状態を確認し、アプリの内部状態をデバッグできます。 コンソール出力やエラーメッセージを取得し、アプリ側のバグ診断ができます。 アコーディオン展開や Settings モーダル表示など、複雑な UI 操作をシーケンスで自動実行できます。 Electron アプリの開発者で、自動テストを書いて UI 動作を検証したい人 ブラウザの DevTools コンソール操作より、スクリプトで自動化して効率化したい人 UI コンポーネント（モーダル・アコーディオン・セレクタなど）が正しく動作するか確認したい人 アプリのスクリーンショットやコンソールログを集めて、バグレポートを作りたい人 このスキルは yarn start（CDP ポート 9222）で起動した Electron アプリを Playwright MCP で操作します。禁止事項：(1) browser_navigate を使うと Electron アプリページを離脱してしまう、(2) browser_snapshot で DOM 全体出力すると数万トークン消費するため browser_evaluate・browser_run_code で必要部分のみ取得、(3) page.goto('about:blank') で離脱禁止（誤操作時は page.goBack() で戻す）、(4) strict mode violation（要素 2 個以上マッチ）を避けるため .first() や data 属性で絞り込み。推奨パターン：スクリーンショットは browser_take_screenshot、クリックはセレクタ + { hasText } + .first() または data-state で絞り込み、アコーディオン開閉は data-state="closed" で検出、DOM 状態確認は .textContent()・.count()・.isVisible() で必要部分のみ取得、言語切り替えは Settings ボタン→Language セレクタで実装。

ゴール文書を入力すると、Ralph Loopパターンで設計→実装→検証を自動で回します 設計フェーズでは既存コードやRN版リファレンスを読み込み、実装方針を自動決定します 実装フェーズでは自動コード生成と既存Flameパターンへの準拠を同時に実行します 検証フェーズで flutter analyze と flutter test を自動実行し、エラーを検出して修正します 進捗状況がファイルベースで記録されるため、中断→再開が可能で、反復的な開発が効率化できます G-Runner Flutter版の新機能を、リファレンス（RN版）を参考にして自動実装したい開発者 設計→実装→検証のループを何度も回す反復開発を自動化したい開発チーム IMPLEMENTATION_PLAN.mdの進捗更新を自動化して、プロジェクト管理を効率化したいプロダクトマネージャー Flameゲームエンジンの標準パターン（PositionComponent、anchor、論理座標系）に沿ったコード生成をしたい技術リーダー ゴール文書をインプットに、Ralph Loopパターンで設計→実装→検証の開発ループを自律実行するスキルです。引数は第1引数がゴール文書パス（必須）、--max-iterationsが最大イテレーション数（デフォルト10）。プロンプトテンプレートは、G-Runner Flutter版開発エージェント向けに、CLAUDE.md・IMPLEMENTATION_PLAN.md・RN版リファレンスを読み込ませ、Phase 0（Design）→Phase 1（Implementation）→Phase 2（Verify）→Phase 3（Update Plan）を順次実行します。Phase 0はRN版ファイル読み込み、ゴール分析、実装方針決定。Phase 1は constants.dart・stage_data.dart への追加、新規Flameコンポーネント実装、ゲームエンジン統合、HUD/画面更新。Phase 2は flutter analyze と flutter test 実行。Phase 3は IMPLEMENTATION_PLAN.md 更新。完了条件は全Phase完了、コード実装済み、解析エラーなし、テスト通過、計画更新済みです。

フォーマット修正・Lint修正・型チェック・ビルド・テストを自動実行し、コミット前にコード品質を確保できます。 各ステップの成功・失敗を順序通りに報告し、どこで問題が発生したか即座に把握できます。 フォーマットとLintの自動修正により、手動修正の手間を削減できます。 クイックモード（ビルド・テストスキップ）で、軽量なチェックも可能です。 PR作成前にコード品質を確認したいエンジニア TypeScript/JavaScriptプロジェクトで品質基準を保ちたい開発チーム DB関連のテストエラーを効率的に解決したいバックエンド開発者 5つのコマンドを順序通りに実行します：(1)pnpm format:fix（コードフォーマット自動修正）、(2)pnpm lint:fix（Lintエラー自動修正）、(3)pnpm typecheck（TypeScript型チェック）、(4)pnpm build（本番ビルド確認）、(5)pnpm test（ユニットテスト実行）。クイックモードはビルド・テストをスキップした3コマンド実行。エラー対応として、型チェックエラーはcd packages/db && pnpm buildで解決、DB関連テストエラーはdocker composeで対応、CI環境変数エラーは開発時は無視可能と定めています。

バグ修正や小機能追加を計画なしで素早く実装し、自動レビュー・修正ループで品質を確保できます。 「これ直して」「簡単な変更」といった明確で小さなタスクに対して、実装完了までの時間を大幅に短縮できます。 実装フェーズ（Implement）とレビューフェーズ（Review）の2段階で効率的に進め、最大2回の修正ループで完成度を高めることができます。 設定変更やファイル修正など、複雑な計画が不要なタスクを「実装→レビュー→修正」の軽量ワークフローで自動化します。 小さなバグ修正や軽微な機能追加を頻繁に依頼する開発チームやプロダクトマネージャー 急ぎのタスクを迅速に完了したい開発者 計画フェーズを最小化して、実装と品質確保に集中したいエンジニア 簡単なファイル修正や設定変更を素早く反映させたい運用担当者 IRは軽量なImplement→Reviewの2フェーズワークフローです。計画や振り返りを省いて、小さく明確なタスク（バグ修正、小機能追加、設定変更、ファイル修正など）に特化しています。 プロジェクトメモリディレクトリを確認してから、以下の手順を実行します： ステップ1（実装）：implementerサブエージェント（Sonnet）を起動し、タスク内容とメモリパスを渡して直接実装を進めます。実装完了レポートを受け取ります。 ステップ2（レビュー）：reviewerサブエージェント（Sonnet）を起動し、実装レポートと変更ファイル一覧をもとにレビュー。VERDICT: PASSまたはVERDICT: FAILを判定します。 ステップ3（修正ループ）：VERDICT: FAILの場合、最大2回まで修正ループを実行。reviewerの「次のアクション」セクションを参考に、implementerを再起動して修正し、再度レビューします。LOOP_COUNTが2に達するかVERDICT: PASSになったら終了です。 ステップ4（最終サマリー）：タスク説明、変更ファイル、最終VERDICT、ループ回数、主な指摘事項をまとめてユーザーに提示します。

曖昧な仕様を質問で埋め、推測実装を避けて正確な設計・実装を実現する 責務を正しい場所に配置し、重複や混在を防ぐことで長期的な保守性を確保する レビュー可能な最小単位の差分に分割し、ロールバック容易性と理解容易性を高める テスト駆動開発（RED→GREEN→REFACTOR）で安全な実装進行を実現する 実装前に設計を深掘りし、後から大きな修正を避けたい開発者 コードレビュー時に「なぜこの実装？」と質問されない、意図が明確な実装を目指す人 既存のパターン・テスト雛形を再利用して効率化と一貫性を両立したい人 責務の混在やリファクタリングの負債を作らず、チームとしての品質を保ちたい人 このスキルの基本方針は「既存優先」と「差分最小」です。実装前に、期待する入力・出力、失敗時の振る舞い、変更の影響範囲、既存規約（命名・ディレクトリ構成・テスト方式）を必ず確認します。 出力フォーマットは7段階：(1)目的、(2)前提（RDD・既存規約・制約）、(3)設計方針（責務・境界・例外・データ）、(4)実装手順（最小ステップ）、(5)差分、(6)テスト（RED→GREEN順）、(7)次の一手。 思想：①実装は仕様の翻訳で推測しない、②責務が混ざったら必ず腐る、③暫定対応を避け恒久化の出口を明記、④失敗時は最小サンプルで切り分ける。 チェックリスト：責務が単一目的か、依存方向が自然か、命名がドメイン意図を表しているか、RED→GREEN→REFACTORが成立しているか、境界条件を押さえているか、重複を増やしていないか、Docコメントで意図が説明されているか。

ビジョン・コンセプト・目的・業務要求・IT 要求・活動の 6 階層を持つ要求分析ツリーを自動的に JSON 構造に変換できます。 複数の TSV ファイルから入力データを読み込み、階層関係を自動で紐付けして統合 JSON を生成できます。 入力ファイルのすべてのデータが JSON ツリーに正確に含まれているか、自動検証できます。 Human-Readable JSON（インデント 2 スペース、UTF-8）形式で出力し、後続の処理や可視化に活用できます。 タクミメソッドの要求分析プロセスで生成された複数の分析結果を、統一的な JSON データモデルで統合できます。 タクミメソッドで要求分析を行うビジネスアナリスト・要件定義者 要求分析の複数出力ファイルを統一フォーマットに整理したい人 要求ツリーをプログラム・ダッシュボードで処理・可視化したい開発者 要求分析から要件実装までのデータ連携を自動化したい人 本スキルは Phase 2〜4 完了後の Phase 4-5 で実行され、前提条件として value-design.tsv、value-analysis-objective.tsv、requirement-tree-business/it/activity.tsv が存在する必要があります。実行手順は (1) requirement-tree.md 読み込みで構造理解、(2) 5 つの入力 TSV ファイル読み込み（ビジョン・コンセプト、目的、業務要求、IT 要求、活動）、(3) 6 階層を持つ JSON ツリー作成、(4) 既存 requirement-tree.json 削除、(5) 新規 JSON 出力（output/requirement-tree.json、整形済み）、(6) 構造検証（コンセプト・目的・業務要求・IT 要求・活動すべてが含まれているか確認）から構成されます。

設計書とコードの整合性を自動チェック：RDD（Requirement Design Document）、アーキテクチャ設計書との齟齬を検出し、改善提案を提示します。 セキュリティ・アーキテクチャ・設計品質を同時にレビュー：複数の観点（OWASP基本・入力検証・認可・秘密情報・依存関係・責務分離・SOLID原則など）から、PR内容を多層的に評価します。 Docコメントを自動生成・転記して実装の意図を記録：設計書の責務や制約情報をコード側のDocコメントに反映させ、実装者の意図を後続開発者に伝えやすくします。 設計書の図表（Mermaidダイアグラム）の妥当性を検証：構文エラー・図と説明の不整合を自動検出し、修正を促します。 mainマージ前の最終品質ゲートとして機能：basic-review後の二次レビューとして、基本レビューではカバーしきれない深い観点を確認できます。 複数プロジェクトで統一的な品質基準を維持したいアーキテクト：各観点をスキル化することで、レビューの属人化を減らせます。 セキュリティリスクを最小化したいセキュリティ担当者：入力検証・認可・秘密情報漏洩などの脆弱性をPR段階で検出できます。 設計と実装のズレを早期に発見したい技術リード：RDD整合性チェックにより、仕様漏れや実装ズレを防げます。 mainブランチへのマージ品質を厳格に管理したいチーム：複数観点のゲートにより、本番リリース後の不具合を削減できます。 Deep Reviewスキルは、設計品質・セキュリティ・RDD整合を深掘りチェックする二次レビュースキル。対象ファイルのパスで自動判定され、doc/**/*.mdは「設計書モード」、それ以外は「コードモード」で動作。コードモード対象範囲は、セキュリティ（OWASP・入力検証・認可・秘密情報）、アーキテクチャ（境界・依存・責務分離）、設計品質（SOLID・重複・抽象度）、RDD整合、複雑さ、アクセシビリティ（UI変更時）、フロントエンド（該当技術時）。設計書モード対象は、SSOT整合（rdd.md・architecture.md整合）、Mermaid図検証、ADR-lite妥当性、網羅性、構造品質（見出し・セクション・リンク）、用語統一。コード変更時、設計書内容をDocコメントに転記：対応関係特定→転記内容抽出→転記フォーマット（@description @constraint @see）→レビュー指摘提案。実行手順は3段階：（1）RDD読み込み・差分取得・変更ファイル一覧化、（2）変更内容に応じたスキル特定、（3）セキュリティ・アーキテクチャ・設計品質・RDD整合の多観点レビュー実施。

FAPI 1.0 Baseline/AdvancedプロファイルやFAPI CIBAの実装・修正を体系的に進められます。 mTLS、PAR（Pushed Authorization Request）、JARM（JWT Secured Authorization Response Mode）などの高度なセキュリティ機能を実装できます。 リクエストのスコープとテナント設定に基づくFAPIプロファイル自動決定ロジックを理解し、適切に検証・実装できます。 63件のFAPI 1.0 Advanced OPテストとRFC要件のマッピングを参照して、OIDF認定基準を満たす実装を実現できます。 金融機関向けOAuth 2.0/OIDC認可サーバーを開発・保守するエンジニア FAPI準拠のセキュリティ実装が必要な決済・銀行系プロダクトの開発チーム OIDF（OpenID Foundation）認定を取得・維持する必要があるシステム担当者 mTLSやPAR、JARMなどの高度なセキュリティ機能の実装・検証を担当する開発者 FAPI（Financial-grade API）開発ガイドは、金融グレードセキュリティを実現するOIDC/OAuth 2.0プロファイル実装の詳細資料です。 FAPIには4つのプロファイルがあります：FAPI 1.0 Baseline（基本的なセキュリティ要件）、FAPI 1.0 Advanced（PAR/JARM/mTLS必須の高度な要件）、FAPI CIBA（CIBA+FAPI組み合わせ）、Sender-constrained Access Token（mTLSバインディング）。プロファイルは優先度順にリクエストのスコープとテナント拡張設定で自動決定されます（priority: fapi_advance_scopes > fapi_baseline_scopes > openid > デフォルト）。 モジュール構成は、idp-server-core-extension-fapiで FAPI Baseline/Advanced検証、mTLSクライアント認証を実装。idp-server-core-extension-fapi-cibaでFAPI-CIBA検証を実装。idp-server-coreのコアにPAR（OAuthPushedRequestParameters）とJARM（JarmCreatable）実装があります。詳細な実装ガイド、Gap分析、OPテストマッピング表が参考資料として提供されています。

ユーザー登録やAPI連携時に送信される入力データの構造・型・制約をJSON Schemaで自動検証できます。 必須フィールドの不足、型の不一致、フォーマット違反（メールアドレス形式など）を検出し、詳細なエラーメッセージを表示できます。 Identity Verification（本人確認申請）や外部API連携時の複雑なデータ検証ルールを、スキーマベースで一元管理できます。 テナント別にカスタマイズされたスキーマを定義でき、組織ごとに異なるユーザー属性要件に対応できます。 JSON Schema Draft 2020-12準拠の最新仕様に対応し、将来的な拡張性を確保できます。 ユーザー登録フォームのバリデーション機能を開発・保守しているバックエンド開発者 API設計時にリクエスト・レスポンスの構造を定義し、型安全性を保ちたいAPI開発者 Identity Verification（本人確認）など複雑なデータ検証ルールを実装する認証系エンジニア マルチテナント環境でカスタマイズ可能なバリデーションロジックが必要なシステム設計者 このSkillはJSON Schema Draft 2020-12に準拠し、libs/idp-server-platform/.../platform/json/schema/配下のモジュール群で実装。主要クラスは①JsonSchemaDefinition：スキーマ定義の保持と型管理、②JsonSchemaValidator：入力データとスキーマの照合検証、③JsonSchemaValidationException：フィールド別の詳細エラー情報。ユーザー登録時はIdPUserCreatorクラス内でJsonSchemaDefinitionが許可フィールドを定義し、AuthenticationInteractionRequestから該当フィールドを抽出して検証。スキーマ定義例として①ユーザー登録：email（メール形式）、name（1～100文字）、birthdate（YYYY-MM-DD形式）を必須に指定、②Identity Verification申請：document_type（enum値）、document_number（最小5文字）を必須。エラーレポートでは必須フィールド不足、型不一致、フォーマット違反、制約値超過（minLength/maxLengthなど）などをフィールド名付きで出力。

SKILL.mdのfrontmatterとagents/配下のファイルのname属性が完全に一致しているか自動的にチェックできます。 Code Generatorが生成したagentファイルに余計なsuffix（-teammateなど）が付いていないか検出し、コマンド認識エラーを事前に防止できます。 SKILL.md内のteammates:定義とagentファイル数が一致しているか、またagents/ディレクトリが正しく配置されているかを検証できます。 ファイル名パターンやfrontmatterの形式が規約に従っているかチェックし、Agent Teamsの起動トラブルを未然に防ぐことができます。 検証エラーを分かりやすく報告し、修正対象を明確に指摘できます。 hr-departmentなどでCode Generatorを使ってAgent Teams Skillを自動生成するエンジニア 新しいAgent Teams Skillを手動で作成する際に品質をチェックしたい開発者 複数のAgent Teams（ops-department, dev-opsなど）を管理しており、構造整合性を保ちたいプロジェクト管理者 Agent Teamsのコマンド認識エラーをデバッグしている開発者 このSkillは5つの検証項目を自動実行します。Check 1: SKILL.mdのfrontmatterにteammates:が定義されているか確認。Check 2: agents/ディレクトリが存在し、SKILL.mdのteammates数とagents/*.mdファイル数が一致しているか検証。Check 3: 各agentファイルのname:フロントマターがSKILL.mdのteammates[].nameリストと完全一致しているかチェック。Check 4: agentファイルのname:に-teammateなどの余計なsuffixが付いていないか検出。Check 5: agentファイルのファイル名がfrontmatterのname:と対応しているか（例：name: executive-assistantに対してexecutive-assistant.md）をチェック。hr-departmentのCode Generatorで生成後、手動作成後の両方で使用でき、エラーが検出された場合は対象ファイル名と問題内容を明確に報告します。

_codex正本ファイルとプロジェクト側ファイルのリンク切れを自動検出し、修正対象を明確化できます。 プロジェクト側が誤ってコンテンツを直接編集していないかをチェックし、「情報の一本化」原則を守れるようになります。 01_strategy.md の必須項目（プロダクト概要・ICP・価値約束・価格・TTFV目標・KPI・アクションなど）が全て揃っているかを一発検証できます。 全プロジェクトの01～05ファイル充足率をレポートし、設計漏れを組織全体で可視化できます。 _codexの正本性を維持し、プロジェクト間での情報ズレを防ぐ運用をルール化できます。 複数プロジェクトを一元管理し、情報ガバナンスを強化したいPOやプロダクト責任者 brainbase運用の正当性を確認したい事業責任者やGM（ゲームマスター） ドキュメント管理の自動化により、手作業チェックを減らしたい運用チーム Git管理とDB管理の役割分担を厳格に実行したい組織基盤チーム _codex正本検証ロジックはbrainbaseの4大原則「情報の一本化」を守るため、_codex配下のみを編集対象とし、プロジェクト側はリンク参照のみに統制します。検証項目は、リンク切れ検出（PROJECT_FILEが_codexを参照しているか・参照先ファイルが存在するか）、誤編集検出（プロジェクト側の行数・見出し含有をチェック）、正本必須項目チェック（01_strategy.mdの「プロダクト概要」「ICP」「価値約束」「価格」「TTFV目標」「主要KPI案」「次のアクション」）、01-05充足率チェック（全プロジェクトで01～05ファイルが揃っているか）です。検証結果はサマリ形式で、OK/警告/エラー件数、詳細（プロジェクト毎の項目チェック）、推奨アクションを出力。

要件定義書（features/*.md）の受入条件から自動的に、システムテスト仕様書を生成できます。 エンドユーザー向けの受入テスト（UAT）仕様書をビジネス用語で分かりやすく生成できます。 要件から導出した具体的なテストステップ（「ログインする」ではなく「メールアドレスとパスワードを入力し、ログインボタンをクリックする」）で、テスト漏れを防げます。 APIドキュメント（OpenAPI）や画面遷移図から、テストシナリオを自動導出できます。 テンプレートに従うため、ドキュメント品質が安定し、作成時間を大幅削減できます。 QA・テスト担当者（テスト仕様書作成を効率化したい人） プロジェクトマネージャー（テスト工程の準備を加速したい人） 開発チーム（要件からテスト仕様書まで一気通貫で生成したい人） 受入テストを実施するビジネスユーザー（非技術者向け手順書が必要な人） 前提ファイル: features/*.md（受入条件）、OpenAPI YAML（API仕様）、screen-flow.md（画面遷移）、*-logic.md（ビジネスロジック）。これらの存在をチェックして、不足があれば報告・停止。 生成手順: テンプレート読み込み → 要件定義から受入条件を全て抽出 → ユーザーに生成対象を確認 → システムテスト仕様書を生成（機能テスト、非機能テストを記載）→ UAT仕様書を生成（ビジネスシナリオ、非技術者向け手順を記載）→ mkdocs.ymlに追加 → 次ステップを提案。 ルール: テンプレート構成を維持（削除不可、追加は可）。シナリオは要件に基づき推測で作らない。UATは非エンジニアが実施できる表現。実装コード存在時は実際のUI要素（画面名・ボタン名）に合わせる。

テストが通うためだけに書かれた「偽装コード」（テスト環境フラグ、テスト対象をバイパスするモック、空の例外処理など）を検出し、本当の品質リスクを指摘できます。 黙って飲み込まれている例外（空のcatchブロック、エラーを無視する処理）を発見し、本番環境での隠れたバグリスクを減らせます。 テストコード内の条件分岐を検出してシンプルなテストに分割するよう提案し、テスト自体のバグ混入リスクを低減できます。 期待値をハードコード化するよう指導し、テストを読むだけで仕様が理解できるテストに改善できます。 テストのない新規コードパス（ゴーストコード）を特定し、見落とされた機能の品質穴を埋めるテスト追加を促せます。 コード品質とテスト信頼性を重視するソフトウェア開発チーム PRレビューやテスト改善の依頼を受けるエンジニア テストカバレッジは高いのに本番バグが多い、という課題を抱えるチーム QAエンジニアが実装品質とテスト信頼性を守るためのコードレビュー指針。基本マインドセット：「コードは本当に正しく動作しているか、テストをパスさせるふりをしているだけか」と自問すること。レビュー観点は5項目。(1)テスト偽装コード検出：テスト環境フラグ、テスト対象バイパスモック、例外の黙った飲み込み。(2)握りつぶされた例外：空catchブロック、広過ぎるcatch、エラーの無視。(3)テストコード内の条件分岐：ifやswitch、三項演算子があると検証意図が不明確化。(4)ハードコードされたアサーション：期待値をリテラルにし、テストから仕様が一目瞭然に。(5)ゴーストコード：テストのない新規コードパスを検出。スコープ制限：原則ブランチスコープ内に限定だが、広範囲影響時はスコープ外テスト追加許可。

テストをパスさせるためだけに書かれた"テスト偽装コード"を検出し、実装の正しさを検証します try-catchで例外を握りつぶしているコードを見つけ出し、エラーハンドリングの改善を提案できます テストコード内の条件分岐を指摘し、シンプルで信頼性の高いテストへのリファクタリングを促します テストされていない新規コードパス（"ゴーストコード"）を検出し、カバレッジを確保できます QA・テスト担当者（テスト品質とコードカバレッジを高めたい方） エンジニア・チームリード（本当に正しいテストが書かれているか確認したい方） コードレビュア（PR審査時にテスト品質を厳密に判定したい方） QAエンジニアとしてコード品質・テスト信頼性を守る専門スキルです。基本マインドセット：「テストが通っているだけか、本当に正しいか」「実装の振る舞いを保証しているか」「テスト削除で落ちるか」「パイプライン全体の動作を証明するテストはあるか」を常に自問します。スコープ制限：トピックブランチの指摘はそのブランチスコープ内に限定、ただし末端修正が広範囲に影響する場合はスコープ外テスト追加を許可（カバレッジ優先）。レビュー観点：（1）テスト偽装検出=test環境専用フラグ・テスト対象をモック化・エラーを黙って飲み込むコード、（2）握りつぶし例外=空のcatchブロック・広いキャッチ・失敗を検出不可にする戻り値変換、（3）テスト内の条件分岐=テスト自体にバグ潜在、パラメータ化テスト推奨、（4）ハードコード推奨=期待値はリテラルで、スナップショットは例外、（5）ゴーストコード=テストのない新規コードパス検出。言語・フレームワーク非依存で全リポジトリに対応、PRレビュー・テスト改善リクエスト時は必ず起動します。

ScalarDB設計ドキュメントの品質を自動検証 - エディション設定、スキーマ設計、アプリパターン、DB選定の整合性をチェックし、設計の漏れや矛盾を検出できます。 生成されたScalarDB/Spring Bootコードをベストプラクティスに照らして検査 - Context7で取得した最新仕様に基づき、非推奨機能・パフォーマンス問題・設定誤りを自動抽出できます。 レビュー観点を並列サブエージェントで効率化 - スキーマ設計、トランザクション管理、パフォーマンス、セキュリティなど複数の観点を同時進行でレビュー、結果をまとめられます。 ScalarDB最新仕様を自動取得・反映 - Context7 MCP経由で常に最新のベストプラクティスを取得し、廃止機能に頼った設計・コードを事前に検出します。 改善提案を具体的に出力 - 検出した問題ごとに「何がどこで問題か」「どう直すべきか」を詳細に記述したレポートを生成できます。 ScalarDBを導入しようとしている企業 - 設計段階でベストプラクティス準拠を検証し、実装後の大規模な修正を避けられます。 マイクロサービス・分散トランザクション対応を検討している開発チーム - ScalarDBの複雑な設定やトランザクション管理を設計段階で正確に検証できます。 生成されたScalarDBコードの品質を確保したい組織 - 自動生成コードの落とし穴を事前に検出し、本番環境への投入判定を正確に行えます。 設計レビュー（--mode=design）とコードレビュー（--mode=code）の2モード。設計レビュー入力：work/{project}/scalardb-edition-config.md、reports/03_design/scalardb-*.mdいずれか。コードレビュー入力：work/{project}/scalardb-edition-config.md、generated/{service}/。出力先：reports/03_design/scalardb-design-review.md（Mode A）、scalardb-code-review.md（Mode B）。Step 1：Context7 MCPでScalarDB最新仕様取得（libraryId: /llmstxt/scalardb_scalar-labs_llms-full_txt、query: best practices schema design transaction management）。Step 2A：レビュー対象読み込み。Step 3A：エディション整合性チェック（スキーマ定義との一致、トランザクション管理、DB特性対応など観点別）。設計/コード観点は並列サブエージェント（Pattern 4）で実行。詳細は.claude/skills/common/sub-agent-patterns.md参照。

レビューコメントの自動一覧化: GitHub APIでPRの未解決コメントをすべて取得し、ファイル・行番号・内容をわかりやすく整理できます。 修正の優先度を自動判定: バグ修正・セキュリティ改善は推奨、設計判断はスキップ、トレードオフはユーザーに確認するなど、判断基準に基づいて分類できます。 修正内容を一括実行: ユーザーの承認を得た修正だけを自動で適用し、複数ファイルの編集をまとめてコミット・プッシュできます。 レビュワーへ対応結果を自動返信: 修正した項目・スキップした項目それぞれに理由付きで返信し、やり取りを記録に残せます。 レビュー指摘の対応に時間をかけたくない開発者: どの指摘に対応すべきか自動判定され、手作業を減らせます。 複数のPRレビューを抱えているコードレビュアー: レビューコメントの一覧化と対応状況の自動追跡で、フォローアップ漏れを防げます。 チームのレビュー品質を高めたい人: 修正理由をコメント返信で説明することで、暗黙知が形式知に変わります。 リモート・非同期チームで働く人: 口頭での「確認しておいて」が減り、コメントに記録が残ります。 mcp__github__pull_request_readで未解決レビューコメント（is_resolved: false）をスレッド取得し、各コメントの内容を要約してユーザーに提示します。判断基準は「修正推奨（バグ・セキュリティ・UX改善・テストカバレッジ拡充）」「修正不要（ユーザー決定事項・プロジェクト方針違い・過剰な将来対応）」「要確認（トレードオフ・設計判断）」の3段階。ユーザー承認後、承認された項目を修正して一括コミット・プッシュし、mcp__github__add_reply_to_pull_request_commentで各レビューコメント（commentId指定）に修正内容または理由を返信。修正返信は「ご指摘ありがとうございます。○○を△△に変更しました」、スキップ返信は「ご提案ありがとうございます。△△の理由から現状維持します」の形式で返信し、最後に「修正X件・スキップY件でよいですか？」と確認します。