# issue-fixer

> GitHub Issueの内容を分析して改修計画を自動作成するスキル。「issue XXを改修」「issueから改修して」「issue対応して」「issue番号XXを修正して」と依頼された時に使用。開発ワークフローに従ってブランチ作成から改修計画立案までを実行

- Author: suu3
- Repository: suu3play/.claude
- Version: 20260105083541
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/suu3play/.claude
- Web: https://mule.run/skillshub/@@suu3play/.claude~issue-fixer:20260105083541

---

---
name: issue-fixer
description: GitHub Issueの内容を分析して改修計画を自動作成するスキル。「issue XXを改修」「issueから改修して」「issue対応して」「issue番号XXを修正して」と依頼された時に使用。開発ワークフローに従ってブランチ作成から改修計画立案までを実行
---

# Issue Fixer - GitHub Issue自動改修スキル

GitHub Issueの内容を分析し、開発ワークフローに従った改修計画を自動作成します。

## 使用タイミング

以下のキーワードでIssue対応を依頼された時に起動:
- 「issue XXを改修」「issueから改修して」
- 「issue対応して」「issue番号XXを修正して」
- 「GitHub IssueのXXを対応して」

## 実行フロー（10ステップ）

### 1. 開発ワークフロー読み込み
`.claude/rules/development-workflow.md`と関連ルールを読み込む

### 2. プロジェクトとIssue番号特定
- ユーザー依頼からプロジェクト名とIssue番号を抽出
- 指定なしの場合はユーザーに確認

### 3. GitHub Issue取得と分析
- プロジェクトディレクトリに移動
- `gh issue view [issue番号]`で内容取得
- Issue内容を分析（問題種類、影響範囲、必要ファイル特定）

### 4. ブランチ作成
- mainブランチに移動して最新取得
- `feature/issue-[issue番号]`ブランチを作成

### 5. 改修計画立案
- Issue内容から実装要件を整理
- 開発ワークフロー基準の作業計画を策定
- **TodoWriteツールで作業計画を作成**

### 6. ユーザー確認① - 改修計画承認
- 作成した改修計画を提示
- ブランチ名、実装内容、Todoリストを報告
- **承認を待つ**（「問題なし」「続行」などの指示まで待機）

### 7. 実装実行
- 改修計画に従って実装
- 各タスク進行時にTodoリスト更新

### 8. ユーザー確認② - 修正内容確認
- **実装完了後、自動コミットせずユーザー確認を待つ**
- 修正内容サマリー表示（変更ファイル、品質チェック結果）
- **指示を待つ**（「コミット」「続行」で次へ、修正依頼で修正）

### 9. コミット実行
- **ユーザー承認後のみ実行**
- Conventional Commits形式でコミットメッセージ生成
- コミット結果を報告
- **指示を待つ**（「PR作成」「プッシュ」で次へ）

### 10. プッシュとPR作成
- **ユーザー指示後のみ実行**
- リモートへプッシュ
- `gh pr create`でPR作成
- 完了報告

詳細な実行手順は`references/issue-fix-workflow.md`を参照

## 使用例

**ユーザー**: growth-diary の issue 8 を改修して

**動作**:
1. 開発ワークフロー読み込み
2. `[プロジェクトルート]/growth-diary`に移動
3. Issue 8の内容取得・分析
4. `feature/issue-8`ブランチ作成
5. 改修計画作成（TodoWrite使用）
6. **改修計画提示 → 承認待ち**

**ユーザー**: 問題なし

7. 実装実行
8. **修正内容報告 → 確認待ち**

**ユーザー**: コミット

9. コミット実行
10. **コミット完了報告 → 指示待ち**

**ユーザー**: PR作成

11. プッシュとPR作成
12. 作業完了報告

## ユーザー確認フェーズ（重要）

### 確認フェーズ①: 改修計画承認
- **タイミング**: 改修計画立案後、実装前
- **承認キーワード**: 「問題なし」「作業開始」「続行」「OK」
- **修正指示**: 具体的な修正内容を指示
- **中止**: 「中止」「キャンセル」

### 確認フェーズ②: 修正内容確認
- **タイミング**: 実装完了後、コミット前
- **承認キーワード**: 「コミット」「続行」「問題なし」
- **修正指示**: 該当箇所の修正内容を指示
- **中止**: 「中止」「キャンセル」

### 確認フェーズ③: PR作成指示
- **タイミング**: コミット完了後、プッシュ前
- **実行キーワード**: 「PR作成」「プッシュ」「続行」
- **その他作業**: 別の指示があれば対応

**絶対に自動で次のステップに進まない**

## エラーハンドリング

主なエラー:
- **プロジェクトディレクトリ未存在**: プロジェクト名の確認を促す
- **GitHub Issue未存在**: Issue番号の確認を促す
- **Gitリポジトリではない**: git init実行を促す
- **ブランチ既存**: 既存ブランチ使用または新規ブランチ名を確認
- **未コミット変更あり**: コミットまたはスタッシュを促す
- **リモート通信エラー**: ネットワーク・認証情報の確認を促す

詳細なエラー対処法は`references/issue-fix-errors.md`を参照

## 注意事項

1. **ユーザー確認必須**: 改修計画承認、修正内容確認、PR作成指示の3段階で必ず確認
2. **開発ワークフロー遵守**: 必ず開発ワークフローを読み込んでからルールに従う
3. **TodoWrite使用**: 作業計画は必ずTodoリストとして管理（進捗可視化）
4. **GitHub CLI必要**: `gh`コマンド使用（事前に`gh auth login`で認証）
5. **権限確認**: リポジトリアクセス権限を確認（プライベートリポジトリは認証必須）

## リファレンス

- **詳細ワークフロー**: `references/issue-fix-workflow.md` - 各ステップの詳細ガイド、コマンド例、TodoWrite活用方法
- **エラーと対処法**: `references/issue-fix-errors.md` - 全エラーの詳細説明とトラブルシューティング