name: issue-to-task description: GitHub Issue→実装タスク生成（Issue分析→タスク分解→チェックリスト作成） version: 1.0.0 tools:

• Bash
• Read
• Grep skill_type: workflow auto_invoke: false

Issue→実装タスク生成

概要

GitHub Issueの内容から実装タスクリストとチェックリストを自動生成します。Issue分析→タスク分解の時間短縮と実装漏れ防止を目的とします。

入力形式

スキル呼び出し時にIssue番号を指定:

/issue-to-task <Issue番号>

または

/issue-to-task

Issue: #<番号>

実行プロセス

ステップ1: Issue情報取得

コマンド:

gh issue view <Issue番号> --json title,body,labels,assignees

取得情報:

• タイトル
• 本文
• ラベル
• アサイニー

出力例:

{
  "title": "日付セレクターを動的な開催日一覧に変更",
  "body": "現状の日付選択UIを、実際に開催があった日付のみを表示する形式に変更する。\n\n## 背景\n...",
  "labels": ["enhancement", "frontend"],
  "assignees": []
}

ステップ2: Issue分析

分類

Issue種別判定:

1. Feature（新機能）: feat: で始まる、enhancement ラベル
2. Bug（バグ修正）: fix: で始まる、bug ラベル
3. Refactor（リファクタリング）: refactor: で始まる
4. Docs（ドキュメント）: docs: で始まる
5. Test（テスト追加）: test: で始まる

影響範囲の特定

ラベルから判定:

• frontend → フロントエンド実装が必要
• backend → バックエンド実装が必要
• api → API拡張が必要
• infra → インフラ変更が必要
• database → DB変更が必要

ステップ3: タスク分解

タスク抽出パターン

Feature（新機能）の場合:

1. 設計

   • データモデル設計（必要に応じて）
   • UI/UX設計（フロントエンド）
   • API設計（バックエンド）

2. 実装

   • バックエンド実装
     • ports定義
     • provider実装
     • handler実装
     • テスト作成
   • フロントエンド実装
     • 型定義
     • APIクライアント
     • UIコンポーネント
     • ページ実装

3. 検証

   • ローカルテスト
   • デプロイ前チェック
   • 動作確認

4. ドキュメント

   • README更新（必要に応じて）
   • CLAUDE.md更新（必要に応じて）

Bug（バグ修正）の場合:

1. 原因調査

   • エラーログ確認
   • 再現手順確認
   • コードレビュー

2. 修正実装

   • バグ修正
   • テスト追加（再発防止）

3. 検証

   • 修正確認
   • 回帰テスト

ステップ4: ファイル特定

影響を受けるファイル一覧:

バックエンド:

- backend/src/domain/ports/<port_name>.py
- backend/src/infrastructure/providers/<provider_name>.py
- backend/src/api/handlers/<handler_name>.py
- backend/tests/**/<test_file>.py

フロントエンド:

- frontend/src/types/index.ts
- frontend/src/api/client.ts
- frontend/src/pages/<Page>.tsx
- frontend/src/components/<Component>.tsx

インフラ:

- cdk/lib/stacks/<stack_name>.ts

ステップ5: テスト項目の抽出

テストカテゴリー:

1. 単体テスト: 関数・メソッドレベル
2. 統合テスト: API・コンポーネントレベル
3. E2Eテスト: ユーザーシナリオレベル（手動）

テスト項目例:

- [ ] バックエンド: 開催日一覧取得APIが正しくデータを返す
- [ ] バックエンド: 存在しない日付範囲でエラーハンドリング
- [ ] フロントエンド: 開催日一覧が正しく表示される
- [ ] フロントエンド: 日付選択時にレース一覧が更新される
- [ ] E2E: ブラウザで日付選択→レース表示の流れを確認

出力形式

📋 実装タスク生成完了

Issue: #<番号> - <タイトル>
種別: <Feature/Bug/Refactor/etc>
影響範囲: <Frontend/Backend/API/etc>

## タスクリスト

### 1. 設計
- [ ] データモデル設計（開催日一覧のAPI仕様）
- [ ] UI設計（日付セレクターのデザイン）

### 2. バックエンド実装
- [ ] ports定義: get_race_dates メソッドを追加
- [ ] JRA-VAN Provider実装: get_race_dates を実装
- [ ] Mock Provider実装: get_race_dates のMock実装
- [ ] Handler実装: GET /races/dates エンドポイント作成
- [ ] テスト作成: test_get_race_dates.py

### 3. フロントエンド実装
- [ ] 型定義: ApiRaceDatesResponse 型を追加
- [ ] APIクライアント: getRaceDates メソッドを追加
- [ ] コンポーネント: DateSelector コンポーネント作成
- [ ] ページ更新: RacesPage に DateSelector を統合

### 4. 検証
- [ ] pytest 実行（バックエンド）
- [ ] npm run test 実行（フロントエンド）
- [ ] デプロイ前チェック実行
- [ ] ローカル動作確認

### 5. デプロイ
- [ ] PRレビュー対応
- [ ] mainブランチにマージ
- [ ] CDKデプロイ（--context jravan=true）
- [ ] 本番環境で動作確認

## 影響ファイル

**バックエンド**:
- `backend/src/domain/ports/race_data_provider.py`
- `backend/src/infrastructure/providers/jravan_race_data_provider.py`
- `backend/src/infrastructure/providers/mock_race_data_provider.py`
- `backend/src/api/handlers/races.py`
- `backend/tests/application/use_cases/test_get_race_dates.py`

**フロントエンド**:
- `frontend/src/types/index.ts`
- `frontend/src/api/client.ts`
- `frontend/src/components/DateSelector.tsx` (新規)
- `frontend/src/pages/RacesPage.tsx`

## テスト項目

**バックエンド**:
- [ ] 開催日一覧取得APIが日付範囲を正しく返す
- [ ] from_date, to_date パラメータが機能する
- [ ] データがない場合は空配列を返す
- [ ] 日付が昇順でソートされている

**フロントエンド**:
- [ ] 開催日一覧が正しく表示される
- [ ] 日付選択時にレース一覧APIが呼ばれる
- [ ] ローディング状態が正しく表示される
- [ ] エラー時にトースト通知が表示される

**E2E（手動）**:
- [ ] ブラウザで日付セレクターが表示される
- [ ] 開催日のみが選択可能
- [ ] 日付選択するとレース一覧が更新される
- [ ] モバイル画面でも正しく動作する

## 推奨実装順序

1. バックエンドAPI実装（TDD）
2. フロントエンド型定義・APIクライアント
3. フロントエンドUIコンポーネント
4. 統合テスト
5. デプロイ

## 推定工数

- バックエンド実装: 2時間
- フロントエンド実装: 3時間
- テスト・検証: 1時間
- 合計: 約6時間

使用例

例1: 新機能追加Issue

/issue-to-task 39

Issue取得中...

📋 実装タスク生成完了

Issue: #39 - 日付セレクターを動的な開催日一覧に変更
種別: Feature (enhancement)
影響範囲: Frontend, Backend, API

## タスクリスト
（上記の形式で出力）

次のアクション:
- [ ] git worktree add で作業ブランチ作成
- [ ] /api-extend スキルでバックエンド実装
- [ ] /ui-component スキルでフロントエンド実装

例2: バグ修正Issue

/issue-to-task 42

Issue取得中...

📋 実装タスク生成完了

Issue: #42 - レース詳細でオッズが正しく表示されない
種別: Bug (bug)
影響範囲: Frontend

## タスクリスト

### 1. 原因調査
- [ ] エラーログ確認
- [ ] オッズデータの型を確認
- [ ] マッピング関数を確認

### 2. 修正実装
- [ ] mapApiRunnerToRunner 関数を修正
- [ ] オッズのパース処理を追加
- [ ] テスト追加（再発防止）

### 3. 検証
- [ ] ユニットテスト実行
- [ ] ブラウザで動作確認

影響ファイル:
- `frontend/src/types/index.ts`
- `frontend/src/types/index.test.ts` (新規)

推定工数: 1時間

参照コマンド

# Issue一覧表示
gh issue list

# Issue詳細表示
gh issue view <Issue番号>

# Issueコメント表示
gh issue view <Issue番号> --comments

# Issue作成
gh issue create --title "タイトル" --body "本文"

注意事項

• Issue内容の明確性: 曖昧なIssueは詳細化を依頼
• スコープの適切性: 大きすぎるIssueは分割提案
• 既存実装の確認: 類似機能の実装パターンを参照
• テストの重要性: テスト項目は必ず含める