AgentSkillsCN

bug-fix

从漏洞报告到调查、原因定位、修复以及回归测试，都进行系统化的处理。

SKILL.md
--- frontmatter
name: bug-fix
description: バグ報告から調査・原因特定・修正・回帰テストまでを体系的に行う。
user-invocable: true

bug-fix

バグ報告をもとに、再現確認 → 原因特定 → 修正 → 回帰テストを体系的に行うスキル。推測で修正せず、原因を確実に特定してから最小限の修正を行う。

引数

  • •Issue 番号 (例: /bug-fix #42): GitHub Issue からバグ報告を取得する。gh issue view で内容を読み取る
  • •Issue URL (例: /bug-fix https://github.com/owner/repo/issues/42): 同上
  • •テキスト (例: /bug-fix ログイン時に500エラー): テキストをそのままバグ報告として扱う
  • •引数なし: ユーザーにバグの症状をヒアリングしてから開始する

実行プロセス

フェーズ1: バグ報告の整理とブランチ作成

  1. •引数からバグ報告を取得する
    • •Issue が指定された場合: gh issue view で本文・コメント・ラベルを読み取る
    • •テキストが指定された場合: テキストをバグ報告として扱う
    • •引数なしの場合: ユーザーにヒアリングする
  2. •以下の情報を整理する（不足している場合はユーザーに確認する）
    • •症状: 何が起きているか
    • •期待される動作: 本来どうあるべきか
    • •再現手順: どうすれば再現できるか
    • •発生環境: ブラウザ、OS、環境（本番/ステージング/ローカル）
    • •発生頻度: 常に / 時々 / 特定条件で
  3. •現在のブランチをベースブランチとして記録する（PR のマージ先になる）
  4. •作業ブランチを作成する
    • •Issue が指定された場合: fix/#<Issue番号> （例: fix/#42）
    • •テキスト / 引数なしの場合: fix/<バグの要約> （例: fix/login-500-error）
  5. •TodoWrite でタスクを管理する

フェーズ2: 原因調査

  1. •

    再現確認

    • •バグ報告の再現手順に従い、実際にバグが再現することを確認する
    • •再現できない場合はユーザーに追加情報を求める
    • •ログ（gh でデプロイログ、ローカルのエラーログ等）を確認する
  2. •

    影響範囲の特定

    • •Explore エージェントや Grep / Glob で関連コードを調査する
    • •エラーメッセージ、スタックトレースから発生箇所を特定する
    • •関連するテストがあれば確認し、なぜテストで検出できなかったかを分析する
  3. •

    原因の特定

    • •根本原因（Root Cause）を特定する
    • •推測ではなく、コードの流れを追って原因を裏付ける
    • •原因と修正方針をユーザーに報告し、合意を得る

フェーズ3: 修正サイクル

ステップ3-1: 回帰テストの作成

  • •修正の前に、バグを再現するテストを作成する
  • •このテストが現時点で失敗することを確認する
  • •テストは最も近い既存のテストスイートに配置する

ステップ3-2: 修正

  • •最小限の変更でバグを修正する
  • •関連する箇所への副作用がないことを確認する

ステップ3-3: 検証

  • •回帰テストが通ることを確認する
  • •既存のテストスイートがすべて通ることを確認する
  • •修正が期待される動作と一致することを確認する

ステップ3-4: Review

  • •reviewer エージェントを利用し、修正内容をレビューする
  • •修正が最小限か、副作用がないか、テストが十分かを評価する

ステップ3-5: 改善サイクル

  • •レビューで指摘された問題がある場合：
    • •再度修正を行う
    • •再度レビューを行う
    • •指摘事項がなくなるまで繰り返す

ステップ3-6: Format & Lint

  • •プロジェクトの設定に従い、変更したファイルに対して format と lint を実行する
  • •format/lint の設定が見つからない場合はこのステップをスキップする

ステップ3-7: Commit

  • •修正内容をコミットする
  • •コミットメッセージは CLAUDE.md の規約に従う

フェーズ4: プルリクエスト

  1. •gh pr create --base <ベースブランチ> でプルリクエストを作成する
    • •ベースブランチはフェーズ1で記録した開始時のブランチを指定する
    • •Issue が指定された場合: タイトルに Issue 番号を含め、Closes #<番号> で紐付ける
    • •PR 本文に以下を含める：
      • •バグの症状と原因の説明
      • •修正内容のサマリー
      • •手動チェックリスト
  2. •修正内容のサマリーをユーザーに報告する

PR 手動チェックリスト

markdown
## バグ修正チェック

### 再現と修正
- [ ] 修正前にバグが再現することを確認した
- [ ] 修正後にバグが解消されることを確認した
- [ ] 回帰テストを追加した

### 影響範囲
- [ ] 関連する機能に副作用がない
- [ ] 既存のテストがすべてパスする

### 品質
- [ ] lint / format がパスする
- [ ] 400 行を超えるファイルがない

ルール

  • •推測で修正しない。原因を特定してから修正に着手すること
  • •修正の前に必ず回帰テストを書く（テストが失敗 → 修正 → テストが通る の流れ）
  • •修正は最小限に留める。バグに無関係なリファクタリングを混ぜない
  • •原因と修正方針は必ずユーザーに報告し、合意を得てから実装する
  • •🔴（重大）または🟠（重要）のレビュー指摘は必ず修正する
  • •🟡（提案）や🟢（軽微）は、明確なメリットがある場合のみ対応
  • •各フェーズの進捗は TodoWrite ツールで管理する