Claude-skill-registry issue-to-task

GitHub Issue→実装タスク生成(Issue分析→タスク分解→チェックリスト作成)

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/issue-to-task" ~/.claude/skills/majiayu000-claude-skill-registry-issue-to-task && rm -rf "$T"
manifest: skills/data/issue-to-task/SKILL.md
source content

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は分割提案
  • 既存実装の確認: 類似機能の実装パターンを参照
  • テストの重要性: テスト項目は必ず含める