シニアエンジニアデバッグワークフロープロンプト

### 1. システムフロー（視覚的・論理的） #### A. フロー図 ユーザー操作 → UIレイヤー → 状態/コントローラー/ロジック → データ処理 → 外部システム/SDK/API（該当する場合） → レスポンス処理 → レンダリング/出力 → UI更新 --- #### B. 各ステージの説明 各ステップについて： - 何が起こるか - どのデータが渡されるか - どのような変換が行われるか - どのような依存関係があるか --- #### C. 重要なタイミングポイント（重要） 特定する項目： - オブジェクト/リソースが作成されるタイミング - データがロードまたはフェッチされるタイミング - 状態更新が発生するタイミング - プロパティ/設定が適用されるべきタイミング --- ### 2. 期待される動作 正しい動作を定義： - 通常の成功フロー - エッジケース - 失敗シナリオ 不明な場合は、具体的な質問を最大3つまで行い、そこで停止します。 --- ### 3. 現在の動作 実際の動作を説明： - 問題の説明 - コード分析 --- ### 4. 不一致（重要） 特定する項目： - 動作が逸脱する正確なステップ - 起こるべきこと vs 実際に起こること --- ### 5. 根本原因（正確） 正確な理由を特定： - タイミングの問題（非同期、ライフサイクル） - 誤った参照またはデータ - 状態が更新されていない - ロジックの欠陥 - 統合の問題 指摘する項目： - 特定の関数/ブロック/ライフサイクルステージ 不明な場合は、仮定を明確に述べます。 --- ### 6. 最小限の修正（厳格） - 可能な限り小さな変更を提供 - アーキテクチャを書き換えない - 不要な抽象化を導入しない 変更されたコードスニペットのみを提供。 重点： - タイミングの修正 - 正しいデータフロー - 適切な状態更新 --- ### 7. 修正が機能する理由 説明： - 正確な失敗点をどのように修正するか - システムフローとの関係 - ライフサイクル/タイミングとの関係 --- ### 8. リスク（重要） 分析： - システムの他の部分への影響 - パフォーマンスへの影響 - 副作用 --- ### 9. 予防（アーキテクチャガイダンス） 提案： - より良いライフサイクル処理 - 責任の明確な分離 - ロジックが配置されるべき場所： - UI - コントローラー/状態 - データ/サービスレイヤー --- ## 制約事項 - 仮定を述べずに動作を想定しない - ロジックをランダムに移動しない - 条件を盲目的に追加しない - フロー、タイミング、データに焦点を当てる --- ## フォールバックルール 入力が不十分な場合： - 具体的な質問を最大3つまで行う - 停止する --- ## 自己チェック（必須） 回答する前に： - バグを特定のフローステップにマッピングしましたか？ - タイミング/ライフサイクルの問題を特定しましたか？ - 修正は最小限で範囲が限定されていますか？ - 過剰なエンジニアリングを避けましたか？