fix-bug-issue

name	fix-bug-issue
description	GitHubのIssueに記載されたバグ報告をもとに修正計画を立て、TDD（テスト駆動開発）を用いてバグ修正を実施します。Issue番号やURLが与えられた際に使用してください。

Fix Bug Issue with TDD Workflow Skill

このスキルは、GitHubのIssueとして報告されたバグチケットに対して、原因調査・修正計画の策定を行い、TDD（テスト駆動開発）のプロセスに則って修正を実施するためのワークフロー定義です。 ユーザーから特定のIssueに対するバグ修正を依頼された場合、以下の手順に従って作業を進めてください。

ワークフロー

1. Issueの情報を取得・理解する

GitHub MCPサーバー経由でIssueの情報を取得し、バグの事象を把握します。

• mcp_github_issue_read (method: get): 対象のリポジトリ(owner, repo)と issue_number を指定し、Issueのタイトルや本文(Body)を取得します。
• バグの把握: 報告されている不具合の事象、再現手順、期待される動作(Expected Behavior)、および環境などの情報を読み解きます。

2. 原因調査と修正計画の策定 (Planning Mode)

いきなりコードを修正するのではなく、リポジトリ内の関連コードを調査し、修正方針とテスト方針を計画します。

• コード調査: grep_search や view_file 等を用いて関連するソースコードを特定し、なぜバグが発生しているのか（根本原因）を分析します。
• テストパターンの設計: プロジェクトのルール（TDD形式を採用する。必ず実現したい振る舞いをテストコードで表現してから実装する）に従い、このバグを再現させ、かつ修正を確認するためのテストケース（入力と期待される出力・状態）を設計します。
• Implementation Planの作成: implementation_plan.md を作成し、以下を記述します。
  • バグの原因
  • プロダクトコードの修正方針
  • 追加・修正するテストケースの設計（TDDの要件を満たすこと）
• ユーザーの承認: ArtifactMetadataの RequestFeedback を true に設定し、ユーザーに計画のレビューと承認を求めます。承認が得られるまでは実装に進まないでください。

3. 作業ブランチの作成と実装準備 (Preparation)

ユーザーからImplementation Planの承認が得られたら、実装を開始する前に最新のデフォルトブランチから作業ブランチを作成します。

• git checkout main (またはプロジェクトのデフォルトブランチ) を実行し、git pull でリモートの最新状態を取得します。
• git checkout -b <ブランチ名> でIssueに対応する新しい作業ブランチを作成します。（例: fix/issue-123-bug-description）
• Taskを作成し（task.md）、実装の進捗を管理する準備をします。

4. TDDによる実装 (Execution)

作業ブランチの準備ができたら、TDDのサイクル（Red -> Green -> Refactor）に沿って実装を開始します。

1. Red（テストの作成）:
   • 計画したテストパターンに基づき、まずは失敗するテストコードを実装します。
   • ユニットテストを実行し、意図通りにテストが失敗（Red）することを確認します（バグが再現していることの証明）。
2. Green（バグ修正の実装）:
   • テストをパスさせるための最小限のプロダクトコードの修正を行います。
   • プロダクトコード修正後、再度テストを実行し、テストが成功（Green）することを確認します。
3. Refactor（リファクタリング）:
   • テストが通ることを維持したまま、コードをプロジェクトの規約に合わせて整理・リファクタリングします。

5. 動作確認と完了報告

• バグ修正のコミットを作成する前に、プロジェクトのフォーマットツール（例: format-code スキル）等があれば実行し、静的解析・整形を行います。
• walkthrough.md を作成または更新し、以下の内容を含めてユーザーに報告します。
  • どのようなテストパターンを追加したか
  • どのようなプロダクトコードの修正を行ったか
  • 最終的なテスト実行結果（成功したことの証跡）

指示事項

• 実装時は必ずTDDの手順（先にテストを書き、その後にプロダクトコードを直す）を守ってください。
• バグの修正によって既存の他のテストが壊れていないか（リグレッション）もあわせて確認してください。
• ファイル内に含める自然言語（コメントやドキュメント）はプロジェクトのルール通り英語で記述してください。ただし、アーティファクト（PlanやWalkthrough）やユーザーとの会話は日本語で行ってください。