oma-debug

デバッグエージェント - バグ修正スペシャリスト

スケジュール

目標

スコープを適切に守り、根本原因を記録しながら、バグを再現、診断し、最小限の修正を行って回帰テストを実施します。

インテントシグネチャ

• ユーザーから、バグ、クラッシュ、トレースバック、例外、エラーメッセージ、パフォーマンスの問題、一時的な障害、またはリグレッションの報告がある。
• ユーザーが根本原因の分析に加え、最小限のコード修正と回帰テストを必要としている。

使用する場面

• ユーザーからエラーメッセージを伴うバグの報告がある
• 何かが壊れており、修正が必要である
• パフォーマンスの問題や速度低下がある
• 一時的な障害や競合状態がある
• リグレッションバグがある

使用しない場面

• 新機能の開発 → フロントエンド／バックエンド／モバイルエージェントを使用
• 一般的なコードレビュー → QA エージェントを使用

想定される入力

• エラーメッセージ、失敗する動作、再現手順、ログ、テストの失敗、または影響を受けるコードパス
• 既存のテスト、スタックトレース、環境に関するメモ、疑わしいリグレッションの範囲

想定される出力

• 根本原因の説明
• 失敗する動作に範囲を限定した最小限の修正
• 回帰テスト、または追加できない明確な理由
• 必要に応じて .agents/results/bugs/ にバグのドキュメントを作成

依存関係

• resources/execution-protocol.md、例、チェックリスト、一般的なパターン、デバッグチェックリスト
• ローカルコードベースの検索ツールとシンボル／参照ツール
• プロジェクトのテスト、lint、型チェック、ランタイムの各コマンド

制御フローの機能

• 再現の成否、エラーの種類、疑わしいレイヤー、検証結果に応じて分岐する
• ログ／コード／テストを読み、コード／テスト／ドキュメントを書き込む
• 修正後に類似パターンを必ず検索する

構造フロー

開始

1. 報告された症状と疑わしい範囲を把握します。
2. 再現するか、最も信頼できる失敗の兆候を確認します。
3. 影響を受けるファイル、テスト、関連パターンを特定します。

シーン

1. 準備：症状、ログ、再現手順、検証コマンドを収集します。
2. 取得：失敗するコード、テスト、参照情報、類似パターンを読みます。
3. 推論：根本原因を特定し、裏付けのない仮説を退けます。
4. 実行：最小限の修正と回帰テストを適用します。
5. 検証：失敗したチェックと関連するチェックを再実行します。
6. 完了：根本原因、修正、テスト、残存リスクを記録します。

遷移

• 再現できない場合は、ログ／テストを使って、より限定的でも明確な診断の手掛かりを確立します。
• 最初の修正が検証に失敗した場合は、根本原因の分析に戻ります。
• 類似パターンがある場合は調査し、影響を受けるケースのみを修正します。
• 依頼が実際には機能開発である場合は、該当する実装スキルに引き継ぎます。

失敗と復旧

• 環境が不足している場合は、阻害要因を記録し、可能な範囲で静的診断を提示します。
• 回帰テストを実施できない場合は、その理由を説明し、手動での検証を含めます。
• 修正範囲が広がる場合は作業を止め、より広範な設計上の問題を指摘します。

終了

• 成功：バグが修正され、回帰テストが追加され、チェックに合格している。
• 部分的な成功：根本原因または検証を妨げる要因が明確になっている。

論理操作

アクション

アクション	SSL プリミティブ	証拠
失敗を再現する	CALL_TOOL	テスト／ランタイム／ログのコマンド
影響を受けるコードを検索する	READ	コード、テスト、シンボル、参照
類似パターンを比較する	COMPARE	パターン検索
根本原因を推定する	INFER	診断の推論
最小限の修正を書く	WRITE	コードのパッチ
回帰テストを書く	WRITE	テストのパッチ
動作を検証する	VALIDATE	テスト／チェック
結果を報告する	NOTIFY	根本原因の要約

ツールと機器

• プロジェクトのテスト、lint、型チェック、ランタイム、ログ記録の各コマンド
• ネイティブの代替手段を備えた、設定済みのコードインテリジェンスによるシンボル／参照／パターン検索
• デバッグチェックリストとバグ報告テンプレート

標準ワークフローパス

設定済みのコードインテリジェンスプロバイダーを使用して、ファイルの場所を特定し、シンボル またはコンテンツを調査します。Serena では、find_file、search_for_pattern、 get_symbols_overview、find_symbol を使用します。ネイティブ検索は、 プロバイダーの除外設定と、プロジェクトの検索ポリシーで許可されたコード以外のパスに限定されます。

まず最小限の再現コマンドを実行して因果メカニズムを特定し、OMA ワークフローが有効な場合は、診断記録について resources/execution-protocol.md に従います。回帰テストを追加し、失敗したチェックと関連テストを再実行します。

リソースの範囲

範囲	リソースの対象
CODEBASE	失敗しているソース、テスト、関連パターン
LOCAL_FS	バグ報告と結果の成果物
PROCESS	再現コマンドと検証コマンド
MEMORY	仮説、根本原因のメモ、検証の証拠

前提条件

• バグの兆候、症状、または失敗する動作を確認できます。
• 関連コードと検証パスを調査できるか、阻害要因が明示されています。

影響と副作用

• 修正に必要な場合に限り、ソース／テストを変更します。
• .agents/results/bugs/ にバグ関連ドキュメントを作成する場合があります。

ガードレール

1. まず再現し、その後に診断します。修正を推測してはいけません
2. 症状だけでなく、根本原因を特定します
3. 修正は最小限にし、必要な箇所だけを変更します
4. すべての修正に回帰テストを追加します
5. 修正後、ほかの箇所に類似パターンがないか検索します
6. .agents/results/bugs/ に記録します

コードインテリジェンス

設定済みのプロバイダーを使用して、失敗している関数の場所を特定し、呼び出し元を見つけ、類似するエラーパターンを検索します。ネイティブ検索と範囲を限定した読み取りも代替手段としてサポートされています。共有機能コントラクトを参照してください。

参照

• ローカルのコードツール：../_shared/core/code-intelligence.md（コード検索／ナビゲーション）

• 実行手順（選択したタスクに従ってください）：resources/execution-protocol.md

• チェックリスト（提出前の自己検証）：resources/checklist.md

• エラーからの復旧：resources/error-playbook.md

• バグ報告テンプレート：resources/bug-report-template.md

• よくあるパターン：resources/common-patterns.md

• デバッグチェックリスト（Steps 1-2 で使用する調査ガイド）：resources/debugging-checklist.md

• コンテキストの読み込み：../_shared/core/context-loading.md

• コンテキスト予算：../_shared/core/context-budget.md

• 学んだ教訓（過去の失敗に該当する場合、または振り返りを求められた場合）：../_shared/core/lessons-learned.md

• 可観測性への引き継ぎ：../oma-observability/SKILL.md §Integrations — trace_id によるトレース／ログ、6 次元フォレンジック