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.mdsource 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種別判定:
- Feature(新機能):
で始まる、feat:
ラベルenhancement - Bug(バグ修正):
で始まる、fix:
ラベルbug - Refactor(リファクタリング):
で始まるrefactor: - Docs(ドキュメント):
で始まるdocs: - Test(テスト追加):
で始まるtest:
影響範囲の特定
ラベルから判定:
→ フロントエンド実装が必要frontend
→ バックエンド実装が必要backend
→ API拡張が必要api
→ インフラ変更が必要infra
→ DB変更が必要database
ステップ3: タスク分解
タスク抽出パターン
Feature(新機能)の場合:
-
設計
- データモデル設計(必要に応じて)
- UI/UX設計(フロントエンド)
- API設計(バックエンド)
-
実装
- バックエンド実装
- ports定義
- provider実装
- handler実装
- テスト作成
- フロントエンド実装
- 型定義
- APIクライアント
- UIコンポーネント
- ページ実装
- バックエンド実装
-
検証
- ローカルテスト
- デプロイ前チェック
- 動作確認
-
ドキュメント
- README更新(必要に応じて)
- CLAUDE.md更新(必要に応じて)
Bug(バグ修正)の場合:
-
原因調査
- エラーログ確認
- 再現手順確認
- コードレビュー
-
修正実装
- バグ修正
- テスト追加(再発防止)
-
検証
- 修正確認
- 回帰テスト
ステップ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: テスト項目の抽出
テストカテゴリー:
- 単体テスト: 関数・メソッドレベル
- 統合テスト: API・コンポーネントレベル
- 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は分割提案
- 既存実装の確認: 類似機能の実装パターンを参照
- テストの重要性: テスト項目は必ず含める