デバッグ・障害対応

テストが失敗したり、実装が意図通りに動かない時に、推測や思いつきではなく、ログ出力による「証拠」に基づいてバグの原因を特定できます。 考えられる原因を5～7個列挙し、最も可能性の高いものに絞って検証するため、闇雲なデバッグの時間を大幅に削減できます。 修正後も、デバッグログをすべて削除し、プロジェクト全体の一貫性を保った状態でコミットできます。 テストコードがパスしないトラブルに遭遇したエンジニア 「なぜ動かないのか理由が不明」という状況から抜け出したい方 原因不明のコンパイルエラーやランタイムエラーの対応を効率化したい方 バグ修正時に、問題の根本原因を正確に把握してから対応したいチーム ワークフローは6ステップで構成。Step 1：症状の正確な把握。エラーメッセージ・スタックトレース全文確認、期待値と実際値の差分明確化、再現条件の特定を「期待/実際/エラー/再現」テンプレートで記録。Step 2：仮説の列挙（5～7個）。データ（入力値・初期化順序）、状態（ライフサイクル・タイミング）、依存（他システム連携・イベント順序）、環境（Unity固有・非同期・スレッド）のカテゴリ別に幅広く検討。Step 3：絞り込み（1～2個）。エラーメッセージとの整合性、変更履歴との関連、再現パターンの一致、過去類似バグ経験を判断基準に。Step 4：ログによる仮説検証。問題メソッドの入口・出口、条件分岐直前、データ変換前後に Debug.Log で値を出力。Step 5：検証と修正。ログ結果から原因特定し最小限修正、外れたら新仮説を追加検証。Step 6：クリーンアップ。デバッグログ全削除、プロジェクト一貫性確認。アンチパターンは推測修正・一度に大量変更・ログ残し。

症状から出発して、ログ・スタックトレース・デバッグツールを活用しながら根本原因を特定できます 5 Why 分析やフィッシュボーン図など体系的な RCA（根本原因分析）手法を使い、表面的な原因ではなく本質的な問題を見つけられます メモリリーク、競合状態、パフォーマンス問題など、複雑なバグのパターンに対応できます デバッグループに陥ったときに自動検出し、別のアプローチを提案して効率的に問題を解決できます GitHub Issue から問題の詳細を抽出し、構造的に調査を進めることができます 本番環境で複雑なバグが発生し、原因が特定しづらい状況に困っている開発者 デバッグに何時間もかかってしまい、効率化したい人 チーム内で「このバグ、何が問題なのか」を説明する必要がある人 パフォーマンス問題やメモリリークなど、実装的な根深い問題に対応したい人 Bug Hunter AI は英語でバグ調査・根本原因分析・フィックス生成を支援するエージェントで、日本語での対話で効率的なデバッグを実現します。得意領域は再現手順（Minimal Reproducible Examples）・ログ分析（エラーログ・スタックトレース）・デバッグツール（ブレークポイント・ステップ実行・変数監視）、および 5 Why・フィッシュボーン図・タイムラインを使った RCA です。バグ種別としてロジックエラー・メモリリーク・競合状態・パフォーマンス問題・セキュリティ脆弱性に対応し、二分探索デバッグ・ラバーダック・分割統治・仮説検証などの戦略を適用します。MUSUBI Agent の StuckDetector モジュールでデバッグループ検出が可能（repeatThreshold: 3、minHistoryLength: 5）で、IssueResolver で GitHub Issue から bug 詳細を抽出（issue number・title・description）して体系的に調査を開始できます。

Steel.devクラウドブラウザを使い、実ユーザー視点でWebアプリを自動テストし、バグを検出できます。 ページレンダリング、リンク・フォーム機能、エッジケース（空入力、特殊文字、ネットワーク遅延）、JavaScriptエラーを包括的にチェックできます。 検出したバグをCritical/High/Medium/Lowに分類し、Tier（Quick/Standard/Exhaustive）に応じた自動修正ループで品質を向上させます。 テスト実行から修正検証までのワークフローを自動化し、Paperclip Heartbeatで定期的にQAを実行できます。 Web アプリケーション開発チームの品質保証（QA）担当者 継続的デリバリーで定期的な自動テストが必要なスタートアップやSaaS企業 ブラウザの互換性確認やレイアウト崩れ検出を自動化したいフロントエンド開発チーム バグ検出から修正検証までを効率化したいプロダクト開発チーム Dev QA（Browser Testing & Bug Fix Agent）は、Steel.dev クラウドブラウザAPI を使い、Paperclip Heartbeat上でWebアプリを実ユーザー視点でテストします。 環境変数STEEL_API_KEY、PAPERCLIP_API_URL/KEY、COMPANY_ID、RUN_IDを設定後、Heartbeatフローは以下の通り：割り当てIssueを取得 → テスト対象URL・スコープを抽出 → ブラウザセッション作成 → テスト実行・バグ検出・修正・再検証 → レポートをIssueコメントに投稿 → セッション終了。 Steel.dev API操作は、POST /sessions でセッション作成（CDP_URL取得）、POST /actions/navigate でページ遷移、GET /actions/screenshot でスクリーンショット取得、DELETE /sessions でセッション終了。テストプロセスは、IssueからTarget URL・Scope・Tier を抽出。テスト実行ではレンダリング（HTTP 200、レイアウト、モバイル表示）、インタラクション（リンク・フォーム・ボタン・連打耐性）、エッジケース（空入力・特殊文字・遅延・戻る）、コンソール（JSエラー・ネットワークエラー）をチェック。バグをCritical/High/Medium/Low に分類し、Tier別に修正範囲を決定します。

モバイルやCloudflare経由でセッション開いた直後に発生する「再接続中...」ループを診断・修正できます。 ブラウザコンソールの WebSocket connection failed エラーと 502 Bad Gateway の原因を特定できます。 ttydプロセス起動時のタイミングレース問題を解決する2段階確認方式を実装できます。 サーバーログから「ポートリッスン準備完了」を確認してからクライアント接続を許可する仕組みに変更できます。 既存アクティブセッションの再起動時に旧ロジックが残っている問題を検出・修正できます。 ttydを使ったブラウザベースターミナルを運用している開発者 モバイルやプロキシ経由でのリモート接続が多い環境の管理者 WebSocket接続エラーのトラブルシューティングに時間がかかっている方 接続の安定性を改善したいインフラエンジニア ttydプロセス起動には2つのステップが存在します：(1)プロセス起動（spawn完了）と(2)ポートリッスン開始（WebSocket接続受付可能）。旧実装では(1)までしか確認していないため、クライアントが(2)完了前にWS接続を試行してしまい失敗します。特にCloudflare Zero Trust経由ではプロキシ遅延により顕著に発生します。解決策として、新規メソッド waitForTtydReady() を実装し、ポートリッスン確認を10秒間、100ms間隔でリトライします。このメソッドは port、timeoutMs、retryIntervalMs をパラメータに取り、ポート監視完了時に「Port ready after XXXms」ログを出力します。session-manager.js の起動フローに2段階確認方式を導入し、Step 1でプロセス生存確認、Step 2でポートリッスン確認を実行する実装が commit: e0775da で提供されています。

本番障害を素早く原因特定して修正できる 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作成は不要（コミットまで）。

白い画面やエラーが出ている原因を特定できる。Metro ログの確認、Auth 状態の確認、ネイティブモジュールの問題切り分けなど、体系的なチェックリストに従って不具合の原因を素早く見つけられます。 Firebase 接続トラブルを解決できる。Firebase Auth の初期化方法、React Native 専用の設定方法、インポート不整合の調査などが分かります。 ネイティブモジュールのトラブルシューティングができる。Expo Go では使えない機能、dev-client が必要な場合、リビルド方法など、ネイティブ周りの問題を早期に発見できます。 Firebase Emulator をローカルで安定稼働させられる。iOS シミュレータ・Android エミュレータごとの正しいホストアドレス、実装時の設定、接続確認コマンドなどが分かります。 パフォーマンス問題（再レンダリング・カクつき）を調査できる。DevTools の使い方、再レンダリングの原因追跡、重い処理の特定方法などが学べます。 React Native / Expo でアプリ開発をしているエンジニア。日々の開発で遭遇する「白い画面」「接続できない」などの不具合を素早く解決できます。 Firebase 認証機能を組み込んでいる開発者。React Native 固有の初期化方法や、インポート不整合など、はまりやすいポイントが分かります。 デバッグ環境を構築・改善したい開発チーム。ローカル Emulator の設定、エミュレータ・シミュレータの制限事項など、チーム全体の開発効率が上がります。 パフォーマンス最適化に取り組む開発者。再レンダリングやカクつきの原因追跡方法が分かり、アプリの応答性を改善できます。 React Native (Expo) アプリの総合デバッグガイド。不具合の切り分けフローとして、白い画面またはエラー発生時に Metro ログ確認 → 初期 loading 状態確認 → ネイティブモジュール問題確認 → Provider クラッシュ切り分けを順序立てて実施します。白い画面チェックリストでは Firebase Auth の場合、firebase/auth と @firebase/auth の混在がないか確認（バンドラーが別モジュール扱いになるため）、React Native 専用の initializeAuth + getReactNativePersistence(AsyncStorage) の使用を必須とします。ネイティブモジュール問題では RCTEventEmitter エラーの原因、Expo Go と dev-client の使い分け、要 dev-client パッケージ（react-native-purchases、expo-apple-authentication、react-native-maps など）の例示、npx expo prebuild 後のリビルド手順を解説。Firebase Emulator 接続では、iOS シミュレータは 127.0.0.1、Android エミュレータは 10.0.2.2 を使用し、Metro の IP を使わないこと、接続確認用の curl コマンド（Auth・Firestore・Storage 各エミュレータ）を提示します。

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形式レポートです。

chrome-devtools-mcp を使用する際に、Chrome に拡張機能を読み込んで有効にした状態でテスト・デバッグできるように設定します。 別プロセスで拡張機能対応の Chrome を起動し、MCP との通信と独立して拡張機能の動作検証ができます。 コード変更後に Chrome を再起動せず拡張機能だけリロードでき、開発サイクルを高速化できます。 Chrome 拡張機能の開発・テストを MCP 環境で行いたい開発者 拡張機能の動作確認をスクリプトで自動化したい方 Playwright などのブラウザ自動化ツールで拡張機能をテストしたい方 このスキルは4つのステップで構成されます。Step 1 では拡張機能つきの Chrome を別プロセスで起動します。コマンドラインは --remote-debugging-port=9223（MCP の 9222 と被らないようする）、--user-data-dir=/tmp/chrome-ext-test（一時ディレクトリで既存プロファイルと分離）、--load-extension=/path/to/dist（ビルド済みフォルダパス指定）、--no-first-run、--no-default-browser-check を含みます。Step 2 で curl http://localhost:9223/json/version で Chrome の起動確認。Step 3 では Playwright で chromium.connectOverCDP('http://localhost:9223') で接続し、chrome://extensions/ にアクセスして拡張機能ID を確認、chrome.developerPrivate API で拡張情報を取得します。Step 4 では chrome.storage.sync.set() で設定を書き込み、対象ページをリロードして拡張機能動作確認。コード変更後はビルド後に拡張機能だけリロードすれば Chrome 再起動は不要です。

生成されたタスク一覧（Markdown形式）のフォーマットを自動検証し、違反を検出できます。 構造・インデント・メタデータ・依存関係・ATDD・横切り・任意項目など、7カテゴリーの検証を実行します。 違反を発見した場合、エラーレポート（Markdown形式）を自動生成し、修正案を提示します。 「Task X-Y」形式の禁止ID表記や、太字でないメタデータキーなど、致命的なエラーは即座に検出します。 リトライ回数（デフォルト3回まで）を管理し、修正→再検証のサイクルをトラッキングできます。 GitHub Issueのタスク仕様書を自動生成しており、フォーマット品質を確保したい開発チーム ATDD（Acceptance Test Driven Development）に基づいたタスク管理を実践している方 「レイヤーごと」「画面ごと」といった横切り分割を検出し、縦切り（フルスタック）な粒度を強制したい方 Phase・タスクグループ・タスクの3階層構造を厳密に管理したい誰もが このスキルは、einja-issue-spec-create Skillから呼び出される tasks-validator サブエージェントが使用します。入力は検証対象のタスク一覧Markdown、現在のリトライ回数（0～）、最大リトライ回数（デフォルト3）です。 成功時は「バリデーション結果: SUCCESS」を返却。失敗時は「バリデーション結果: FAILURE」と共に、エラー一覧（タスク番号・エラー種別・問題説明・修正案）およびリトライ情報（現在の試行回数・最大回数・残り回数）を返却します。 検証項目: (0)構造前提チェック（最優先・即FAILURE）では、「Task X-Y」形式のID表記、太字でないメタデータキー、3階層構造の欠落を検出。(1)構造検証でPhase連番・タスクID形式をチェック。(2)インデント検証で2・4スペース規則を確認。(3)メタデータ検証で「要件」「実装AC」「依存関係」「完了条件」「対応設計」「シナリオテスト」の6項目を必須確認。(4)依存関係検証で参照先存在・循環依存・書式をチェック。(5)ATDDチェックでPhase数2～3個、タスクグループが縦切りか確認。(6)横切り検出（最重要）で、タスクグループ名に禁止ワード（Domain、Infra、API、UI、Repository、Entity等、レイヤー・クラス・画面単位の分割）が含まれていないか検査。(7)任意メタデータ検証で記載されている項目のみ形式チェック。

TOML構文の完全検証: 基本構文・文字列クォート・配列・テーブル・コメント形式をチェックし、構文エラーを自動検出できます。 スキーマ準拠性の確認: 必須フィールド・フィールド型・値の範囲・形式・一意性・整合性を検証できます。 複数設定ファイルの一括検証: team.toml・orchestrator.toml・evaluator.toml・judgment.tomlなど、複数ファイルを同時にチェックできます。 修正方法の自動提案: エラー検出時に具体的な修正内容をユーザーに提案できます。 段階的な検証実行: 特定ファイル指定・ファイルタイプ指定・全設定一括など、柔軟な検証方法を選択できます。 MixSeekプロジェクトの設定管理を担当するエンジニア ワークスペース初期構築時に設定の正確性を確認したい開発者 CI/CDパイプラインで設定エラーを事前に検出したい運用者 チーム開発で設定ファイルの一貫性を保ちたいテックリード 対応ファイル: team.toml(チーム設定)、orchestrator.toml(オーケストレーター設定)、evaluator.toml(評価設定)、judgment.toml(判定設定)。 使用方法: Step 1 検証対象確認(特定ファイルまたは全設定) → Step 2 検証実行(detect-python-command スキルの run-python.sh で validate-config.py 実行) → Step 3 結果報告(成功時は検証項目と結果表示、失敗時はエラー内容と修正方法提案)。 検証項目: TOML構文検証(基本構文・クォート・配列テーブル・コメント) + スキーマ検証(必須フィールド・フィールド型・値範囲・形式・一意性・整合性)。 前提条件: MixSeek-Core/Plus インストール済み、Python 3.13+、uv推奨。成功時は検証済みと表示、失敗時は エラー番号 + 修正手順を番号付きで出力。

エラーメッセージ、ログ、スタックトレースから不具合の原因を体系的に分析できます。 5 Why 分析（なぜなぜ分析）や Fishbone 図など、根本原因分析（RCA）の手法を活用して問題を掘り下げます。 メモリリーク、ロジックエラー、競合状態、パフォーマンス問題など、様々なバグタイプに対応した調査戦略を提案します。 ブレークポイント、ステップ実行、変数監視など IDE デバッガーを活用した効率的なトラブルシューティングを実施します。 原因不明のバグに困っている開発者 デバッグプロセスを効率化したいエンジニア エラーログから問題を素早く特定したい人 セキュリティ脆弱性や性能問題を調査したい人 Bug Hunter AI として、ログ解析（エラーログ、スタックトレース）、デバッグツール（ブレークポイント、ステップ実行、変数監視）、根本原因分析（5 Why、Fishbone 図、タイムライン分析）を専門とします。ロジックエラー、メモリリーク、競合状態、性能問題、セキュリティ脆弱性など複数のバグタイプに対応。 デバッグ戦略は二分探索デバッグ、ラバーダックデバッグ、分割統治、仮説検証などを活用。Browser DevTools、IDE デバッガー、ロギングフレームワーク、パフォーマンスプロファイラーといったツール類を駆使します。 MUSUBI エージェント補助モジュール StuckDetector でデバッグセッションのループを検出し、IssueResolver で GitHub Issue からバグ詳細を抽出します。

エラーを自動分類：タイムアウト、ネットワーク障害、認証エラーなど、DBエラーを5つのカテゴリに即座に判定できます。 ログから原因を読み解く：:timeout、:retry、:final-failure などのサフィックスからエラーの経過を追跡し、問題箇所を素早く特定できます。 リトライ戦略を理解：どのエラーが自動リトライ対象か、どのエラーはリトライしても無駄かが一目瞭然です。 3層のレジリエンス（復旧機構）を活用：リトライが失敗してもキャッシュやフォールバック対応により、サービスが停止しない仕組みを理解できます。 PostgreSQL/D1の詳細エラーコードを解析：エラーコードから原因となったテーブルやカラムを特定し、適切な対応が取れます。 本番環境でDBエラーが発生し、原因を素早く特定したいエンジニア KeepOnのDBロジックを理解して、より堅牢な実装を心がけたい開発者 Cloudflareで動くサーバーレス環境の接続エラーに悩んでいる人 ログを見てもどのエラーが重大なのか判断できていない人 KeepOnのDB診断ナレッジベース。D1（SQLite）/PostgreSQLエラーの分類、リトライ挙動、ログパターンをカバーします。 エラー分類：classifyConnectionError()により、timeout / network / connection / auth / unknown の5分類が行われます。timeout・network・connectionはリトライ対象、auth・unknownはリトライされません。 ログ命名規則：logSpanが出力するサフィックスは、:start（処理開始）、:end（正常完了）、:error（エラー発生）、:timeout（タイムアウト）、:retry（リトライ実行）、:final-failure（全リトライ失敗）などで構成され、各ログから処理の経過が追跡できます。 3層レジリエンス：①withDbRetryでDB接続をリセットして再試行、②リトライ失敗時にキャッシュデータで応答、③タイムアウト時にnullを返してスキップという3段階の復旧機構があります。診断フローでは、ログサフィックス→error.code→リトライ有無→遅延エラーの確認→Cloudflareログとの突き合わせという手順で問題を切り分けます。

コードベースをスキャンして、バグの原因となりやすい7つの構造的欠陥パターンを自動検出します。 検出した欠陥ごとに危険度を評価し、具体的なリファクタリング（コード改善）案を提示します。 過去に発生した不具合パターンを学習し、同じバグが繰り返される構造を予防的に改善する提案ができます。 品質保証・QAエンジニアで、再発バグを防ぎたい コードレビューを行う開発リーダー・アーキテクト バグの根本原因が構造にあると感じ、修正だけでなく予防したい 長期保守されるコードベースの技術負債を減らしたい このスキルの専門性は7つの構造的欠陥パターン検出です：(1)サイレント早期リターン（異常を握りつぶす）、(2)操作パスの分散（共通化漏れで副作用処理が漏れる）、(3)特殊分岐の増殖（新しい条件で分岐追加が必要になる）、(4)責務過大クラス（単一クラスが複数責務を持ち変更影響が広範）、(5)状態の非同期的不整合（複数データ構造の同期漏れ）が主要な対象です。スキルは調査→危険度評価→具体的リファクタリング案提示という3ステップで動作し、実装はTDDスキルやオーケストレータスキルに委譲する設計になっています。

報告されたバグの直接原因（コード上で何が起きているか）と根本原因（なぜ起きたか）を分けて明確に整理できます コードベース全体を調査して同じパターンの不具合がないか予防的に検出します 必要な修正と予防的リファクタを判断して、spec-change か plan-impl のどちらで進めるか自動判定します 修正計画書（docs/plans/）を構造化されたMarkdownで自動生成し、実装チームがすぐに着手できます バグ報告を受けた開発リード・QA担当者 不具合の本質的な原因を素早く把握したい開発チーム 修正だけでなく再発防止まで考慮したい品質管理担当 複数の関連バグを一括で対応方針を立てたいプロジェクト このスキルは分析と計画作成のみを担当し、実装は行いません。ワークフローは5ステップで構成されています。Step 1 で現象を理解（症状・期待値・再現条件・関連コード特定）、Step 2 で原因分析（直接原因と根本原因を分離、同パターンの調査）、Step 3 で対応方針決定（.kiro/steering/bug-fixing-policy.md に従い、単純ミスか構造的問題かで分岐、予防規模を small/medium/large/不要で整理、後続フローは spec-change か plan-impl かを決定）、Step 4 で計画ファイル生成（マークダウン形式で不具合分析・変更内容を構造化）、Step 5 で次アクション提示。出力は分析サマリーと計画ファイルパスを提示します。

エラーメッセージやスタックトレースから原因を自動特定。 SyntaxError・TypeError・ネットワークエラー・ファイル操作エラーなど、エラーの種類を自動分類。 スタックトレースのファイル・行番号を自動読み込みして、該当コードと周辺コードを確認。 原因の候補を「可能性：高/中/低」で複数提示し、確認手順と修正方法を段階的に提案。 再発防止策まで含めた包括的な解決ガイドを自動生成。 エンジニアで、頻繁に出会うエラーをすぐに理解・対処したい人 デバッグに時間をかけたくないプロダクト開発者 コードレビュー担当者で、エラーの原因をチーム内で素早く共有したい人 新人エンジニアで、エラーメッセージの読み方を学びたい人 ステップ1：$ARGUMENTS内のエラーメッセージ・スタックトレースを使用、なければユーザーに確認（エラーメッセージ全文・実行コマンド・直前の変更）。ステップ2：エラー分類（SyntaxError/TypeError/ImportError→コード問題、ConnectionError/TimeoutError→ネットワーク問題、PermissionError/FileNotFoundError→ファイルシステム問題、AssertionError/TestFailure→テスト失敗、ビルドエラー→設定・依存関係問題）。ステップ3：Readでスタックトレースのファイルパス・行番号を読み込み該当箇所と前後を確認、Grepでキーワード検索。ステップ4：出力は「エラーの概要」「原因の候補（可能性レベル・説明・確認方法・該当箇所）」「推奨解決手順」「再発防止策」で構成。注意：原因が確定していない場合は候補として提示し断定しない、複数候補は確認しやすい順に並べ、修正提案は自動適用しない。

マジックナンバーを排除：コード内の意味不明な数値を定数として定義することで、将来の修正時に数値の意図がすぐに理解でき、間違った値への修正ミスを防げます。 型安全性を大幅に向上：型アサーション（as）を避けて型ガード関数を使用することで、コンパイル段階でバグを検出でき、実行時エラーを減らせます。 重複コードを自動的に検出・統一：同じロジックが複数箇所に存在する場合を関数化することで、メンテナンス工数を削減し、バグ修正時の対応漏れを防げます。 テストの保守性を向上：実装コードと同じ定数をテストから参照することで、テストと実装のズレを防ぎ、テスト信頼性を高められます。 パフォーマンス問題を予防：ループ処理内での無駄な操作を事前に排除するルールで、不要な遅延を防げます。 チーム全体のコード品質を統一したい技術リード・アーキテクト バグの発生を事前に防ぎたい開発チーム コードレビューの基準を明確にしたいエンジニアリング組織 新しい開発者のオンボーディングを効率化したいプロジェクトマネージャー このスキルは6つの基本原則（マジックナンバーの排除、定数参照、ループ最適化、型安全性、マジック文字列の定数化、重複コード排除）とヘルパー関数の命名規則（is～は型ガード、get～は取得、to～は変換）を定義します。マジックナンバーの排除では「ドメイン知識としてみなせる数値」を特に強調し、テストコード内でも同じ定数をインポートして使用することで参照元が一元化されます。型ガード関数はasによる強制キャスト回避を徹底し、繰り返し使用される文字列リテラルも定数化対象に含めます。実装時の確認項目としてチェックリスト形式で7項目を示し、コードレビュー時にこの項目を確認することでチーム全体での規約遵守を促進します。

複数の視点からバグを自動検出：Ship チャットログ・ソースコード品質・E2E テスト結果の3つの情報を並行分析し、1つの視点では見落とすバグを多角的に発見できます。 本番環境到達前にバグを潰す：開発プロセス中のエラーパターン、コードの品質問題、テスト失敗を統合的に分析することで、ユーザーが遭遇する前にバグ報告を起票できます。 バグの根本原因を推測できる情報を集約：チャットログから開発中の迷いや試行錯誤、コードから構造的な問題、テストから実装漏れを把握し、Issue に「疑わしい原因」として記録できます。 チーム全体の開発品質を見える化：エラーの頻出パターン（Retry ループ、タイムアウト、Escort Gate の拒否パターン）を定量的に把握でき、チーム全体の改善課題を明確化できます。 手作業のバグ検査工数を大幅削減：3つの Dispatch を並行実行することで、複数人で担当していたレビュー・テスト検証業務を自動化できます。 品質保証・QA を強化したいプロダクトチーム AI による自動開発システムの出力品質を監視したいエンジニアリング組織 リリース前のバグ検出工数を削減したいプロジェクトマネージャー 開発プロセス全体の可視化と改善を推進したい技術リード /audit-bug は Dock（Commander）から呼び出されるスキルで、3つの Dispatch を並行起動してそれぞれの完了を待機します。（1a）チャットログ分析では Ship と Escort のログを読み、エラーメッセージ・異常な状態遷移・Retry ループ・未処理例外・Escort 拒否パターン・プロセスクラッシュ・タイムアウトパターンを検出。（1b）ソースコード品質分析では Engine のコード問題（型安全性、エラーハンドリング、複雑度）を検査。（1c）E2E テスト結果分析では テスト失敗パターンと環境問題を特定します。各分析結果はバグタイトル・ソース（ワークツリー/ログファイル）・エビデンス・カテゴリ（ERROR/RETRY_LOOP/TIMEOUT など）・重大度・説明・疑わしい根本原因をまとめて出力され、Commander が gh issue create で一括起票します。重複検出排除と既知 Issue との照合により、無駄な起票を防ぎます。

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

テスト駆動開発（TDD）の RED-GREEN-REFACTOR サイクルを実装し、テストを先に書くことで実装品質を高めバグを未然に防げます pytest の Fixture、パラメータ化テスト、モック機能を使い、単体テスト、統合テスト、E2E テストを効率よく作成・管理できます ユニットテスト、統合テスト、E2E テスト（Playwright や Selenium）を組み合わせて、機能全体の動作を包括的に検証できます テストカバレッジを測定し、エッジケースやエラーハンドリングを含めて 80～90% 以上の品質目標を達成できます テストは独立・高速に実行され、変更時に自動で全体の正当性を確認できるため、リファクタリング（コードの整理・改善）時の信頼度が向上します バグを事前に検出して修正コスト・納期遅延を防ぎたい開発チーム リファクタリングする際に壊れていないか確実に確認したい保守開発者 テストなしで不安定なコードから卒業して品質を上げたいエンジニア CI/CD パイプラインで自動テスト実行し、本番リリースの安全性を確保したい DevOps 担当者 テスト駆動開発（TDD）の 3 ステップ：RED（テスト先行・失敗確認）、GREEN（最小実装）、REFACTOR（改善）。pytest ベストプラクティス：テストファイル命名 test_*.py または *_test.py、テスト関数 test_ 接頭辞。Fixture 活用（依存関係管理）、パラメータ化テスト（複数入力テスト）、モック・スタブで外部依存を切り離し。カバレッジ目標最低 80%、推奨 90% 以上。テスト種類：Unit Test（関数単位）、Integration Test（複数コンポーネント、DB・API含む）、E2E Test（ユーザー視点全体テスト）。モック戦略 @patch 装飾子使用。テスト独立性、高速実行、テストコード保守を注意事項として記載。

自動テストが未整備な状況で、npm run lint・npm run buildと手動検証を組み合わせた効率的な動作確認フローを実行できます。 認証・WordPress連携・GSC（Google Search Console）連携・GA4連携・スタッフ招待・権限管理など、GrowMateの主要機能ごとに確認すべきチェックポイントを把握して、モレなく検証できます。 LIFFトークンエラー・SSE途切れ・WordPress投稿取得失敗・Supabase RLS権限エラーなど、よくある問題の原因調査手順と解決方法が分かります。 マイグレーション実行時のロールバック計画を立てられます。 GrowMateの新機能実装後に、手早く動作確認したい開発者 WordPress・GSC・GA4などの外部サービス連携をテストする際の確認方法を知りたいエンジニア トラブル発生時に原因を素早く特定し、対処できる保守担当者 基本方針：自動テスト未整備のため手動検証とlint・buildで対応。画面・機能ごとのチェックポイント：①認証周り（app/page.tsxの認証フロー、ログイン/アウト状態確認）、②WordPress連携（/analyticsで投稿表示確認、AnnotationPanelのcontent_annotations upsert確認）、③GSC連携（/gsc-dashboardのデータ表示、/gsc-importのインポート完了・データ取込確認）、④GA4連携（プロパティ設定反映、日次同期・イベント集計メトリクス確認）、⑤スタッフ招待・権限（参照・削除動作確認、閲覧専用ownerの編集不可確認）。代表的なトラブルシューティング：LIFFトークン（authMiddlewareログ・refresh endpoint確認）、SSE途切れ（ping間隔・idletimeout設定確認）、WordPress取得失敗（REST API URL・認証ヘッダ・ログ確認）、Supabase RLS権限（migrationsファイルで確認、Service Role切替またはポリシー修正）。マイグレーション・ロールバック方針をREADMe記載。