Skill.md検索

ゴール文書を入力すると、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完了、コード実装済み、解析エラーなし、テスト通過、計画更新済みです。

新機能の実装完了後、設計書・実装計画書・API比較表・README・チュートリアルをまとめて最新化できます Git の変更履歴から実装内容を自動判定し、どのドキュメントを更新すべきかを特定できます 実装ステータス、API仕様、実装詳細、ファイル構成などを一括更新し、ドキュメントと実装のズレを防げます 新しく実装されたAPIの場合、既存フォーマットに従って自動的に設計書を生成できます 機能を実装した直後、ドキュメント更新を効率的に済ませたい開発者 設計書と実装のズレを最小限にしたいプロジェクト README や API リファレンスを常に最新に保ちたいチーム 新機能追加時に、関連する複数のドキュメントを漏れなく更新したい人 update-docs スキルは 3 フェーズで実行されます。Phase 1（共通）：git diff と git log から変更内容を把握し、実装した機能を特定。Phase 2（開発ドキュメント更新）：設計書（docs/design/）ではステータスブロック・API仕様・Streamlit比較表を更新、実装計画書（docs/impl/）ではフェーズ完了状況・ファイル構成を更新、API比較表（docs/streamlit-api-comparison.md）では ❌ → ✅ に変更；該当ドキュメント未存在時は既存フォーマットに従い新規作成。Phase 3（README更新）：Features・API Reference セクションで新しいAPIを追加、既存フォーマット（TypeScript シグネチャ・パラメータテーブル・使用例）に従って記述。バグ修正・リファクタリング後にも使用可能。

git diff --cached で変更内容を分析し、日本語の Conventional Commits 形式でコミットメッセージを自動作成してコミットできます。 絵文字を使った type（feat:✨新機能、fix:🐛バグ修正、docs:📝ドキュメント、refactor:♻️リファクタリング等）を自動判定し、統一されたスタイルのコミットを実現します。 ステージされていない変更があれば検出して確認し、個別のファイルを追加するか判断できます。 変更の「何をしたか」を1行目に、「なぜしたか」を本文に記載し、Co-Authored-By を自動付与したコミットを作成できます。 Conventional Commits 形式で統一されたコミット履歴を保ちたい開発チーム コミットメッセージを毎回日本語で丁寧に書くのが面倒なエンジニア git diff を確認して適切な type を判定し、自動でコミットを作成させたい人 .env などの機密ファイルが誤ってコミットされるのを防ぎたい開発者 ステージ済み変更を分析し、日本語 Conventional Commits 形式でコミット実行するスキル。ステップ1で git status、git diff --cached --stat、git diff --cached、git log --oneline -5 を並列実行して変更内容と過去スタイルを把握。ステップ2でステージされていない変更を確認し、必要に応じて個別に git add で追加させる（git add . 厳禁）。ステップ3でコミットメッセージ作成：type は feat（✨）/ fix（🐛）/ docs（📝）/ refactor（♻️）/ chore（🔧）/ style（💄）/ test（✅）から選択、1行目は「何をしたか」を日本語で簡潔に、本文は「なぜか」を箇条書きで記載、Co-Authored-By: Claude Opus 4.6 を自動付与。ステップ4で HEREDOC 形式でコミット実行後 git status で確認、pre-commit フック失敗時は新規コミット作成（--amend 禁止）。.env やシークレット含むファイルは警告してコミット拒否。禁止事項：git push（明示指示時のみ可）、--amend、--no-verify、git add ./-A、git config 変更。

ユビキタス言語集を生成: ビジネスドメインで使用される専門用語を設計書とコードから抽出し、定義をまとめたドキュメント化。 アクター・ロール・権限を整理: システムに関わる人・役割・権限の関係を可視化し、認可ロジック（リファクタリング＝コードの整理・改善）と対応付け。 ドメイン-コード対応表を作成: 設計書の概念とコード上の実装を行ごとに紐付け、ドメイン理解を加速。 現行システム概要を文書化: 技術スタック、アーキテクチャ、モジュール構成を自動抽出し、新規開発者のオンボーディング資料に。 中間ファイルを逐次出力: 各ステップ完了時にすぐ結果ファイルを生成し、分析の進捗を可視化。 レガシーシステムをリプレイスまたはリファクタリングする開発チーム 既存システムの設計思想を新しいメンバーに学習させたい技術リーダー 設計書とコードの乖離を把握し、ドメインモデルを再構築したいアーキテクト マイクロサービス化やモジュール分割の検討時に現行構造を詳しく知りたい人 システム分析エージェントが既存システムの設計書とコードを分析し、ドメイン理解の基礎情報を抽出します。出力は reports/01_analysis/ ディレクトリに記載。Step 1 では mkdir でディレクトリ作成と対象スキャン、project-metadata.json 出力。Step 2 では設計書解析（ドキュメント読取、ビジネス用語抽出、アクター・ロール特定、機能・非機能要件整理）。Step 3 ではコードベース解析（mcp__serena__get_symbols_overview でシンボル一覧取得、ディレクトリ構造・名前空間・クラス・外部依存を観点に）、system-overview.md 出力。Step 4 ではユビキタス言語抽出（設計書の要件定義書・ER図・ユースケース、コードのクラス名・メソッド名・Enum値・コメント)、ubiquitous-language.md 出力。Step 5 ではアクター・ロール・権限整理（ユースケース図・認証コード・権限設定から）、actors-roles-permissions.md 出力。Step 6 では domain-code-mapping.md 出力（設計書概念とコード表現の対応表）。各ステップ完了時に即座にファイル出力すること。

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

既存システムのコード構造を分析し、モジュール性を4つの観点（凝集度・結合度・独立性・再利用性）から定量評価できます。 各モジュールの強み・弱みを明確にしたうえで、マイクロサービス化への準備度合いを数値スコア（0～100）で示します。 改善が必要な箇所を優先順位付きで提示し、リファクタリング（コードの整理・改善）や分割戦略の具体的な計画を策定できます。 分析結果は reports/02_evaluation/ に mmi-overview.md、mmi-by-module.md、mmi-improvement-plan.md として出力され、アーキテクチャ意思決定の根拠として活用できます。 既存レガシーシステムの分解・近代化を検討している技術責任者 モノリシックなアプリケーション（ひとかたまりのシステム）をマイクロサービス化したい開発チーム システムアーキテクチャの客観的な評価指標が欲しい設計者 リファクタリング計画の優先順位を数値に基づいて決めたい組織 Modularity Maturity Index (MMI) 評価エージェントは、ソフトウェアアーキテクチャのモジュール性を定量評価します。4つの評価軸（凝集度30%・結合度30%・独立性20%・再利用性20%）の加重平均で計算され、スコア80～100は高成熟、60～80は中成熟、40～60は低中成熟、0～40は未成熟と判定します。評価対象をパッケージ・クラス・サービス単位から選択し、Step 1でモジュール抽出、Step 2で各軸を5段階評価（5=最高、0=最低）、Step 3で結果をレポート化、Step 4で改善計画を策定します。Serena ツール等を用いてコードベースを直接分析し、前提条件として reports/01_analysis/system-overview.md などの事前分析ファイルを活用（推奨）しますが、存在しない場合はコードから直接分析を行います。

本番障害を素早く原因特定して修正できる 5分以内に障害内容・原因箇所・修正方針をユーザーに提示し、コード修正に集中できます。 修正範囲を最小限に保てる ホットフィックスモードで「余計なリファクタリング」を排除し、障害の原因箇所のみの修正に限定できるので、予期しない副作用を防げます。 修正後の設計書同期を忘れずに実施できる コード先行を許可しながらも、24時間以内のSpec同期を自動で催促し、設計書とコードの乖離を防げます。 被依存Specへの影響確認ができる 修正対象の要件に依存している他の仕様を逆引きで特定し、回帰テストを漏らさないようサポートします。 再発防止策まで提案できる 根本原因のレビュー後、テスト不足・設計不備・監視不足のいずれが原因かを分析し、次のアクション（テスト追加、仕様見直し、非機能要件の拡充）を提案できます。 本番環境で障害が発生し、「今すぐ直さないといけない」という場面にいる開発者・プロジェクトマネージャー 通常の「設計書ファースト」フローでは間に合わない、緊急度の高いバグ修正に対応したい人 セキュリティ脆弱性など、即座の修正が必要な案件を扱う人 ホットフィックス後も、Spec同期や再発防止を体系的に進めたい人 緊急修正（ホットフィックス）は設計書ファースト原則の例外措置。使用条件：本番環境で障害が発生している、ユーザーが「緊急」「至急」「ホットフィックス」と指示、セキュリティ脆弱性の即時修正が必要。該当しない場合は revise-spec への誘導を提案。フェーズ1障害把握（5分以内）：ユーザーから障害内容を聞く、該当REQ-IDを特定（不明なら REQ-HOTFIX-NNN で仮採番）、2段階探索（code-search-2stage.md）で原因箇所を特定、修正方針をユーザーに提示（障害・原因・修正方針・影響範囲）。フェーズ2コード修正：hotfix/[Spec ID] ブランチ作成（feature/ ではなく hotfix/ を使用）、最小限の修正で障害原因箇所のみに限定、既存テスト全てパス確認、障害再現テストを追加（可能な場合）、コミットメッセージに [HOTFIX] と障害内容記載（Spec同期：未完了（24h以内に実施すること）を明記）。フェーズ3Spec同期（24時間以内）：修正デプロイ後、該当Spec要件定義書を更新、spec-map.yml操作ガイドに従い spec-map.yml を更新、基本設計への影響があれば設計書も更新、docs: [HOTFIX] Spec同期 コミット。フェーズ3b被依存Spec影響確認：spec-map.yml で修正対象REQ-IDに依存しているSpec（被依存先）を逆引きで特定、実装済みSpec のテスト実行で回帰確認（不可能な場合は manual-test-cases.xlsx に「[REQ-YYY] ホットフィックス後の回帰確認」追加）、該当Spec一覧をユーザーに通知。フェーズ4振り返り：障害根本原因をユーザーに報告、再発防止策を提案（テスト不足→gen-testsで補強、設計不備→revise-specで仕様見直し、監視不足→非機能要件追加）、finish-impl.md同様のテンプレートフィードバックチェック。ルール：修正最小限、Spec同期必須24時間以内、仮REQ-ID は後で統合、PR作成は不要（コミットまで）。

標準フォルダ構造を自動作成 - リファクタリング分析に必要な00_summary～99_appendixまで8つのディレクトリを一括作成し、手動でのフォルダ作成作業をゼロにできます。 メタデータファイルを自動初期化 - project-metadata.jsonを自動生成して、プロジェクト名・バージョン・ソース情報・分析ステータスをあらかじめ設定できます。 複数の出力先に対応 - デフォルトのreports/フォルダのほか、カスタムパスを指定して任意の場所に同じ構造を作成できます。 既存ファイルを上書きしない安全設計 - 既にフォルダがあっても上書きしないため、前回の分析結果を誤って消す心配がありません。 分析開始前の準備を一元化 - コマンド1つで複雑なセットアップが完了し、すぐに実際の分析作業に入られます。 アーキテクト・リファクタリング推進者 - 大規模なコード分析を始める前に標準的な出力構成を用意したい エンジニアチーム - 複数プロジェクトの分析結果を統一されたフォルダ構造で管理したい テックリード・CTO - 分析環境のセットアップ手順を標準化して、チーム全体の効率を上げたい コンサルタント・外部専門家 - クライアント毎に分析出力フォルダを素早く準備したい /init-output [出力パス]で呼び出す（パス省略時はreports/）。生成フォルダは00_summary・01_analysis・02_evaluation・03_design・04_stories・05_estimate・graph/data・99_appendixの8階層。mkdir -pで既存ディレクトリを保持します。メタデータファイルproject-metadata.jsonは、project（name・version・created_at・updated_at）、source（path・type・languages・frameworks）、analysis（status・modules_count・domains_count・average_mmi）、agents（system_analyzer～microservice_architect各エージェントのステータス）を初期値として自動生成。Bashツール実行で完成。書き込み権限がない場合はエラー出力。相対・絶対パス対応。

テスト駆動開発（TDD）の4つのフェーズ（SPEC→RED→GREEN→BLUE）を対話ガイド付きで自動実行できます。 機能仕様書（docs 配下の feature-*.md）を選択すると、テストシナリオに変換し、失敗するテストを書き、最小限の実装を加え、リファクタリング評価を順序立てて進めます。 ディレクトリ構造を自動ミラーし、docs の設計書に対応したテストコード（tests 配下）と実装コード（src 配下）を正しい位置に配置します。 各フェーズの完了条件を明確に定義しており、サブエージェント（0spec.md、1red.md、2green.md、3blue.md）に委任することでコンテキスト消費を最小化できます。 品質のいい実装を確実に作りたい開発者・開発チーム テスト駆動開発の手順を学びながら実践したい初心者プログラマ 大規模機能開発で設計書とコードのズレを防ぎたいリードエンジニア 既存プロジェクトに TDD を導入し、品質基準を統一したい組織 TDD 統合スキルは、feature 仕様書を選択して対話を開始し、4つのサブエージェント（0spec: 仕様→テスト仕様書、1red: テストコード作成、2green: 最小実装、3blue: リファクタリング評価）に段階的に委任します。実行前の対話フロー（feature-*.md 一覧表示、参考コード確認、最終確認）により、テスト対象を明確に絞り込みます。docs と tests ディレクトリをミラーするルールを定義し、例えば docs/backend/services/rag/ なら tests/backend/services/rag/test_*.py と src/backend/services/rag.py に配置されます。各フェーズは特定の出力形式（STATUS・ファイルパス・概要）を返すことでコンテキストを制限し、効率的に進行します。

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

現在のブランチとベースブランチの差分を自動分析し、PRタイトルと説明文を自動生成できます。 コミット履歴や変更ファイル情報から、適切なConventional Commitsプレフィックス（feat・fix・refactor等）を判定します。 PR説明に背景・目的・変更内容・破壊的変更の有無をMarkdown形式で自動フォーマットできます。 ユーザー承認後にGitHubへ自動でPRを作成でき、手作業のコピペを削減できます。 ソフトウェア開発者：PR作成の定型作業を自動化したい方 チームリード：PR品質を統一し、レビュー効率を高めたい方 GitHub利用プロジェクト管理者：PR作成フローを標準化したい方 開発生産性を高めたい個人・チーム：毎回のタイトル・説明作成を自動化したい方 GitHubプルリクエスト作成スキルは、git branch・git log・git diffコマンドでブランチ差分を収集した後、変更の目的（機能追加・バグ修正・リファクタリング等）・変更ファイル・Breaking Change有無・関連Issue番号を分析します。タイトルは50～72文字以内で命令形、Conventional Commitsプレフィックス付与が基準。PR説明は「背景→目的→変更内容→変更種別→確認方法→補足」のテンプレートで生成され、Breaking Changeがあれば該当箇所に⚠マークとClosesキーワードを自動挿入します。GitHub MCPが利用可能な場合は優先使用され、ユーザー明示的承認後にPRを作成します。

QAチェックリストのバグIDを指定するだけで、修正対象ファイルの特定から実装まで自動実行できます。手作業でバグ情報を探す時間が削減されます。 .claude/rules/に記録された開発ルール（iOS Swift、Kotlin KMP）を自動参照して、プロジェクトのコーディング基準に合わせた修正を実施します。 バグ修正後、関連するテストを自動実行して検証し、修正の正確性を確認できます。 修正内容、検証結果、残存リスクを含むレポートを自動生成し、修正履歴を明確に記録できます。 iOS・Kotlin開発を行うエンジニアで、バグ修正プロセスを高速化したい人 QAから報告されたバグを効率的に処理したい開発チーム 修正ルールを統一し、品質ばらつきを減らしたい組織 最小限の変更でバグを修正し、副作用を最小化したい保守担当者 QAチェックリストのバグIDを指定してコード修正を自動実行します。処理フローは以下の通り：(1)docs/qa_checklist.mdから指定バグIDの詳細情報を取得、(2)バグ関連ファイルを特定し読み込み、(3).claude/rules/のルール（ios-swift.md、kotlin-kmp.md）を参照して修正方針を決定、(4)コード修正を実行、(5)関連テストがあれば実行して検証、(6)修正サマリーを報告。修正時は最小限の変更で不要なリファクタリングを避け、既存コードパターンに従います。Kotlin shared層修正は./gradlew :shared:testDebugUnitTestで検証、iOS層修正はビルドエラーがないことを確認します。出力は修正ファイル、変更概要、テスト・ビルド検証結果、残存リスクを含むMarkdown形式レポートです。

Pythonコードを書く・レビュー・リファクタリング（整理・改善）する際に、PEP 8（コードスタイル）とPEP 20（設計思想）に基づいた最良の実装方法をガイドできます。 命名規則・コードスタイル・型ヒント（関数の入出力の型を明示）・例外処理（エラー時の対応）・Pythonicなパターン（Pythonらしい書き方）など、すべてのフェーズで参照できる実践ガイドが提供されます。 よくある間違い（例：if x == None: を if x is None: に直す）を自動検出し、正しい書き方へ導けます。 新しいモジュール・クラス・関数作成時から、既存コードのレビュー・改善まで、すべての段階で一貫した品質基準が適用できます。 Pythonコードを書いて依頼する人 Pythonコードをレビュー・改善してもらいたい人 チーム内で統一されたPythonコーディング基準を導入したい人 Pythonらしい（Pythonic）な書き方を学びたい人 PEP 8（コードスタイル）・PEP 20（設計思想）に基づくPython実践リファレンス。適用タイミングは新しいモジュール・クラス・関数作成、命名規則・コードスタイル決定、Pythonコードレビュー・リファクタリング、例外処理・型ヒント・Pythonicなパターン実装時。カテゴリ別に設計思想（PEP 20）、コードスタイル（PEP 8の命名規則・コードレイアウト・空白・コメント・docstring）、実装パターン（プログラミング推奨事項・Pythonicパターン）をカバー。よくある間違いとして、if x == None: ではなく if x is None:、type(x) is int ではなく isinstance(x, int)、具体的な例外指定、明示的なインポート、関数の型ヒント明示、4スペースインデント（タブ不可）などを列挙。

TypeScript の型定義、命名規則、インポート順序など、プロジェクト全体で統一されたコーディング規約を一度に確認できます。 camelCase（変数・関数）、PascalCase（クラス・型）、UPPER_SNAKE_CASE（定数）などの命名ルールをAIが自動で適用するようになります。 is/has/can/should プレフィックスの Boolean 命名ルールが定義されているため、一貫性のある変数名でコードが書かれます。 関数の単一責任や早期リターンなどの設計パターンを、AIに学習させてコード品質を高められます。 TypeScript プロジェクトのコードレビュアーやリーダー 新規ファイル作成やリファクタリング時に、毎回「このプロジェクトの規約は？」と確認するのが面倒なエンジニア React / Next.js プロジェクトで、チーム全体のコーディングスタイルを統一したい人 AIに「このプロジェクトのコーディング規約に従ってコード生成して」と指示したい開発者 命名規則: 変数・関数は camelCase（getUserById）、定数は UPPER_SNAKE_CASE（MAX_RETRY_COUNT）、クラス・型は PascalCase（UserService）、ファイルは kebab-case（user-service.ts）、React コンポーネントは PascalCase（UserCard.tsx）、環境変数は UPPER_SNAKE_CASE（DATABASE_URL）。Boolean は is/has/can/should プレフィックスを使用（isActive、hasPermission、canEdit、shouldRefetch）。 型定義: any は禁止、unknown を使用して安全に処理。Optional chaining（user?.profile?.email）、Nullish coalescing（user.name ?? 'Anonymous'）推奨。 インポート順序: 外部ライブラリ → 内部モジュール（エイリアス） → 相対インポート。 関数設計: 単一責任の原則、早期リターンでネストを減らす。

対象システムのソースコード全体をスキャンして、使用している技術スタック（言語・フレームワーク・ライブラリ）を自動特定できます ディレクトリ構成、モジュール構造、依存関係を詳細に分析し、現行システムの全体像を把握できます 技術的負債（後付けパッチ、重複コード、古い設計パターン）、セキュリティリスク、アンチパターンを検出・リポート化します ドメイン駆動設計（DDD）への移行可能性を評価し、リファクタリング計画の基礎情報を体系的に提供します 複雑なコードベースの調査レポートを reports/before/ に自動出力、別エージェントとの並列作業にも対応します レガシーシステムの現状把握・リファクタリング計画を立てるアーキテクト・シニアエンジニア 新しいプロジェクトに参画し、コードベースを短時間で理解したい開発者 セキュリティ監査・品質向上を目的に、既存システムの問題点を列挙したい 他チームから引き継いだシステムの構造や依存関係を整理して、改善施策を検討する立場 このエージェントは Step 0～4 で構成されています。Step 0 では対象パスからプロジェクト名を特定し、出力ディレクトリを作成します。Step 1 の技術スタック調査では package.json、pom.xml、build.gradle などから言語・フレームワーク・データベース・ビルドツール・テストフレームワークを特定。Step 2 の構造分析ではファイルインベントリ、ディレクトリ構成、モジュール依存関係を調査。Step 3 の問題点特定では技術的負債、セキュリティリスク、アンチパターンを検出。Step 4 の DDD 適合性評価では既存構造を DDD に適合させるための課題を分析します。結果は reports/before/{project}/ に technology-stack.md・codebase-structure.md・issues-and-debt.md・ddd-readiness.md として段階的に出力されます。大規模コードベースの場合は Task tool の Explore エージェントを並列起動してコンテキストを保護します。

型チェック・リント・テストを一括検証: npm run typecheck「npm run lint」「npm run test」を順序立てて実行し、すべてパスすることを確認してからコミットへ進みます。 意図しないファイルの混入を防止: ステージング前に変更ファイルを確認し、.envやシークレット、個人情報などが含まれていないかチェックできます。 Conventional Commitsに準拠したメッセージ自動生成: typeと scopeを含めた統一的なコミットメッセージを自動成形し、チーム間のコミット履歴の品質を標準化します。 PR前の最終品質保証: npm run buildを含む差分確認、タイプチェック、テスト、ビルド確認を実行し、PRマージ前の品質を担保できます。 ブランチ戦略を自動適用: feature/*/fix/*などの命名規則に従ったブランチを自動作成し、mainへの直接コミットを防ぎます。 コード品質を厳しくチェックしたい開発チーム: コミット前に型チェック・リント・テストを一括実行することで、品質を保証した状態でPRへ進めます。 ヒューマンエラー（機密ファイルのコミットなど）を防ぎたい人: ファイル確認と機密ファイル検出で、うっかり漏洩を防げます。 Gitワークフロー・コミットメッセージの統一を図りたいチーム: Conventional Commits+ブランチ戦略により、全員が同じルールで開発できます。 コミット、ブランチ作成、PR準備など、Gitに関する操作時に安全なGitワークフローを自動適用します。ブランチ戦略は機能開発feature/*、バグ修正fix/*、リファクタリングrefactor/*の命名規則を使用。コミット前チェックリスト（MUST）は①npm run typecheckエラー0件②npm run lintエラー0件③npm run test全パス④意図しないファイル確認。コミットメッセージ規約はConventional Commitsで、typeは feat/fix/refactor/test/docs/chore/style、scope（オプション）とsubjectで構成。禁止事項は main/masterへの直接コミット・プッシュ、--force-push原則禁止（自分のブランチ以外絶対禁止）、.env・シークレット・個人情報ファイルをコミット禁止、複数無関係な変更を1コミット禁止。PR前確認はgit diff main...HEAD --stat、npm run typecheck、npm run test -- --run、npm run buildを実行。

テストを先に書いてからコードを実装することで、仕様漏れやバグを事前に防ぐことができます。 Red-Green-Refactorサイクル（失敗→成功→改善）を繰り返し、常にテストで保護されたコードを維持できます。 言語別のテストフレームワーク（Jest、Vitest、pytest等）の使い方がわかり、プロジェクトに合わせて選択できます。 リファクタリング（コードの整理・改善）時にテストがあることで、既存機能を壊さない安心感を得られます。 小さなテストケースに分解することで、複雑な機能も段階的に実装できます。 品質の高いコードを書きたいエンジニア バグの少ないシステムを構築したいチームリーダー テストの書き方が曖昧で、何から始めたらいいかわからない開発者 既存コードの改善時に壊す心配なくリファクタリングしたい人 TDD（テスト駆動開発）は Red-Green-Refactor というサイクルを繰り返します。RED（赤）フェーズではテストファイルを作成し、期待する振る舞いをテストとして記述してから実行し失敗を確認します。GREEN（緑）フェーズでは、テストを通すことだけに集中した最小限のプロダクションコードを書きます。REFACTOR（青）フェーズでは、テストが通る状態を維持しながら、重複を除去し、可読性を向上させ、既存パターンとの一貫性を保ちながら改善します。TDDには3つの法則があります：(1)失敗するテストを書くまで、プロダクションコードを書いてはならない、(2)失敗するテストを必要以上に書いてはならない（コンパイルエラーも失敗とみなす）、(3)現在失敗しているテストを通すために必要なプロダクションコード以上を書いてはならない。テストの書き方は AAA パターン（Arrange-Act-Assert）を使い、準備→実行→検証の構造で記述します。言語別のテストフレームワークとしては TypeScript/JavaScript では Vitest（高速・Vite統合）、Jest（エコシステムが豊富）、Playwright（E2Eテスト）があります。

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

テストコード・本体実装・リファクタリング・静的解析・PR 発行を体系的に実施し、品質を保ったまま開発を進める 既存コード（類似機能・型定義・テストパターン）を調査して参考にしながら実装し、一貫性のあるコードを書く コミット・リファクタリング検証・チェックリスト記録を含む完全な開発フローを自動化する 品質を重視した開発ワークフローを定着させたいリードエンジニア・アーキテクト 実装からレビュー依頼までの一連のプロセスを効率化したい開発チーム テストファーストで安心できる実装を進めたいプロダクト開発者 設計完了後、実装フェーズを開始するための開発フロー。①事前準備として実装対象ワークを確認。②コーディング：Explore エージェントで関連既存コード・型定義・テストパターンを調査し、初めにテストコードを実装してレビュー要求、問題なければ本体コード実装してコミット。③リファクタリング：実装後にリファクタリング実施、完了後に必ずテスト実行、eslint・prettier等の静的解析ツール実行、コミット。④レビュー依頼：完了後に PR 生成。チェックリスト（/docs/features/{index}-{feature-title}/checklist.md）に現状記録。

テスト駆動開発（TDD）のRed-Green-Refactorサイクルに従って、堅牢な機能を段階的に実装できます。 実装前にテストを書くことで、要件を明確にし、意図しない動作を事前に防げます。 各実装ステップでテストを実行して確認するため、バグを早期に発見でき、後の修正コストを削減できます。 リファクタリング（コードの整理・改善）を安心して行える環境が整い、コード品質を継続的に向上させられます。 テストコードが自動ドキュメントになるため、チーム内で実装意図の共有が容易になります。 新機能開発を担当するエンジニア：要件を正確に理解し、バグを減らしながら開発を進めたい チーム開発を行う人：テストコードを通じて実装意図を明確に伝えたい コード品質を重視する人：リファクタリングを安全に実施し、長期的にメンテナンスしやすいコードを目指したい 既存プロジェクトの改善に取り組む人：テストを通じてリグレッション（機能低下）を防ぎながら改善したい t-wada（和田卓人）推奨のTDDワークフローは、Red-Green-Refactorという3段階のサイクルで構成されます。Red段階ではテストを先に1つだけ書き、必ず失敗させることを確認します。Green段階では仮実装（Fake It）でテストを通し、必要に応じて三角測量（別テストケースを追加して一般化）を行います。Refactor段階ではテストが通った状態でコード重複や設計の問題を改善します。テストファイルはtest_.pyとして配置し、uv run pytestで実行。禁止事項として「テストを書く前に実装コードを書くこと」「テストがRedの状態でリファクタリングすること」「テストを実行せずに次のステップに進むこと」などが定められています。