fix

修正

スコープゲート（開始前に必須）

以下の条件をすべて満たす場合にのみ、このスキルを使用します。

1. 具体的な問題の兆候がある

   • 明確な不具合、エラー、またはリグレッションが特定されている
   • 診断を開始するのに十分な証拠（ログ、スタックトレース、失敗するテスト、または再現手順）がある

2. 修正箇所が限定されている可能性が高い

   • 問題が小さな範囲に限定されているように見える
   • システム横断の再設計や移行は想定されない

3. アーキテクチャ上のリスクが低〜中程度である

   • 基盤となる変更なしで修正できる
   • 段階的なロールアウトやフィーチャーフラグの戦略は想定されない

4. 検証方法が明確である

   • 実際的な範囲で再現と修正後の確認を実行できる
   • 成功基準を直接検証できる

条件を1つでも満たさない場合は、brainstorm または write-plan にエスカレーションしてください。

即時停止してエスカレーションする条件

次のいずれかに該当した場合は、直ちに停止して計画策定に切り替えてください。

• 集中的に調査しても根本原因が不明なままである
• 修正にシステム横断のアーキテクチャ変更またはデータモデル変更が必要である
• スコープが大規模なリファクタリングや複数モジュールの移行に拡大する
• セキュリティまたはコンプライアンスに関わる動作が含まれる
• 検証で段階的な緩和が必要な広範なリグレッションが見つかる
• 根本原因にたどり着けないまま、複数回の修正が失敗する

エスカレーション時の対応：

1. すべての実装作業を停止します。
2. 次のメッセージをそのまま出力します："This fix exceeds safe single-pass debugging limits. Ask, Recommend brainstorm or write-plan first to define phased diagnosis, implementation, and risk controls."

ワークフロー

ステップ 1：受け付けと状況の把握

1. 報告されたバグを理解し、期待される動作を明確に定義します。
2. バグ報告に必要な最低限の項目を収集・確認します。
   • タイトル
   • 期待される動作
   • 実際の動作
   • 再現手順
   • 証拠（ログ、トレース、スクリーンショット、失敗したテストの出力）
   • 環境（該当する場合はブランチ／OS／ランタイム／バージョン）
   • 影響度／重大度
3. バグに関連するプロジェクトのコンテキストのみを読み込みます。
   • docs/SUMMARY.md が存在する場合は、最初に読みます。
   • タスクに関連する詳細ドキュメントのみを読み込みます。
   • 実装規約については、Code Standard ドキュメントを優先します。
   • ドキュメントとコードまたはユーザーの意図が矛盾する場合は、広範な変更を加える前に、利用可能な入力／質問ツールを使用します。

ステップ 2：再現と診断

1. 問題を一貫して再現します。
2. 失敗箇所（ファイル／関数／行の範囲／サブシステム）を特定します。
3. 制御フローとデータフローを追跡して、根本原因を特定します。
4. 修正の仮説を立て、観察された動作を説明できることを確認します。

ガイドライン：

• 失敗している行だけでなく、周辺のコードも読みます。
• 症状への対処より、根本原因の修正を優先します。
• 一時的な診断処理は必要な場合にのみ追加し、使用後に削除します。

ステップ 3：小規模な修正か、より大きな修正かを判断

コーディングの前に作業を分類します。

小規模な修正（このスキルを続行）

次の項目の大半を満たします。

• 根本原因が明確で、検証済みである
• 変更範囲が限定されている（通常は数個のファイル）
• リグレッションのリスクが限定的で、迅速にテストできる

大規模またはリスクの高い修正（brainstorm または write-plan にエスカレーション）

次のいずれかに該当します。

• 根本原因が不確かである
• 複数のサブシステムを連携して変更する必要がある
• 移行、ロールアウトの順序付け、または広範なリファクタリングが必要である
• 1回の作業でリスクを合理的に制御できない

大規模な修正の場合は、即時停止してエスカレーションする条件に従ってください。

ステップ 4：実装（小規模な修正の場合）

1. 実装計画を1〜3個の簡潔な箇条書きで示します。
2. 根本原因を解決するため、対象を絞った最小限の変更を適用します。
3. スコープを厳守し、無関係なリファクタリングは避けます。
4. 該当する場合は、リグレッションテストを追加または更新します。

ステップ 5：検証

検証は範囲を段階的に広げて実行します。

1. 変更した動作／モジュールに対する重点的なチェック
2. 周辺のリグレッションチェック
3. 必要に応じた、関連するプロジェクトのチェック（リンター／型チェック／テスト／ビルド）

次の条件を満たした場合にのみ、修正が完了したと判断します。

• 問題を再現できなくなった
• 期待される動作を確認できた
• 重大なリグレッションが発生していない

検証でより広範な影響が示された場合は、brainstorm または write-plan にエスカレーションしてください。

ステップ 6：完了報告

以下を含む簡潔な完了報告を提示します。

• 根本原因
• 変更内容
• この修正が有効な理由
• 実施した検証と結果
• 残存リスク／今後の対応

動作やドキュメントに関わるルールを変更した場合は、関連する最小限のドキュメントを更新してください。アーキテクチャを変更する場合は、エスカレーションが必要です。

ルール

• 重要なコンテキストが不足している場合は、推測しないでください。
• 常に根本原因の修正を優先してください。
• 影響範囲は最小限に抑えてください。
• 検証せずに完了としないでください。
• スコープやリスクがこのスキルの範囲を超える場合は、早めにエスカレーションしてください。

任意のバグ報告テンプレート

報告に不備がある場合に使用してください。

• タイトル：
• 期待される動作：
• 実際の動作：
• 再現手順：
• エラーログ／スタックトレース：
• 環境：
• 影響／深刻度：
• 追加のコンテキスト：