analyze-issue

GitHub の issue #$ARGUMENTS を分析し、技術仕様書を作成してください。

以下の手順に従ってください。

1. issue がすでに読み込まれているか確認します。

   • ./specs/issues/ フォルダー内で issue ファイルを探します。
   • ファイル名の形式：<3 桁のゼロ埋め番号>-<ケバブケースのタイトル>.md
   • 見つからない場合は、GitHub から issue の詳細を取得します（手順 2 を参照）。

2. issue の詳細を取得します（まだ読み込まれていない場合）。

   • .claude/commands/load-issues.md を読み、issue の詳細の取得方法を確認します。
   • load-issues.md の形式に従って issue ファイルを保存します。

3. 要件を十分に把握します。

4. 関連するコードとプロジェクト構造を確認します。

5. 以下の形式で技術仕様書を作成します。

Issue #$ARGUMENTS の技術仕様書

Issue の概要

• タイトル：[GitHub の issue のタイトル]
• 説明：[issue の簡単な説明]
• ラベル：[issue のラベル]
• 優先度：[issue の内容に基づく高／中／低]

問題の説明

[問題を説明する 1～2 段落]

技術的アプローチ

[詳細な技術的アプローチ]

実装計画

1. [手順 1]
2. [手順 2]
3. [手順 3]

テスト計画

1. 単体テスト：
   • [テストシナリオ]
2. コンポーネントテスト：
   • [テストシナリオ]
3. 統合テスト：
   • [テストシナリオ]

変更するファイル

• [ファイルパス]：[変更内容]

作成するファイル

• [ファイルパス]：[目的]

活用する既存のユーティリティ

• [ユーティリティ名／パス]：[目的]

成功基準

• [基準 1]
• [基準 2]

対象外

• [項目 1]
• [項目 2]

厳格な TDD の原則、KISS の方針、および 300 行のファイル上限に従ってください。

重要：分析の完了後、技術仕様書の全文を次の場所に保存してください。 ./specs/issues/<3 桁のゼロ埋め番号>-<ケバブケースのタイトル>.specs.md

たとえば、タイトルが「Make code review trigger on any *.SQL and .sh file changes」の issue #7 の場合、次の場所に保存します。 ./specs/issues/007-make-code-review-trigger-on-sql-sh-changes.specs.md

保存後、以下を確認する簡潔な概要をユーザーに提示してください。

• 分析した issue の番号とタイトル
• 仕様書を保存したファイルパス
• 仕様書の主なポイント（2～3 個の箇条書き）