103 lines
3.0 KiB
Markdown
103 lines
3.0 KiB
Markdown
# GitHub IssueのURLまたは番号から内容を取得し、実装計画を立案します
|
||
|
||
GitHub Issueの内容を取得し、詳細な実装計画を立案してください。
|
||
|
||
## 実行手順
|
||
|
||
### 1. Issue情報の取得
|
||
|
||
引数として渡されたIssue番号またはURLから情報を取得します。
|
||
|
||
- **Issue番号の場合**: `gh issue view <番号> --json title,comments,body,labels,assignees,milestone`
|
||
- **URLの場合**: URLから番号を抽出して取得
|
||
|
||
### 2. Issue内容の分析
|
||
|
||
取得したIssue情報から以下を分析してください:
|
||
|
||
- **目的**: このIssueで達成すべきゴールは何か
|
||
- **要件**: 必須要件とオプション要件の整理
|
||
- **制約条件**: 技術的制約、期限、依存関係など
|
||
- **影響範囲**: 変更が及ぶファイル・モジュールの推定
|
||
|
||
### 3. 既存コードベースの調査
|
||
|
||
実装に関連する既存コードを調査してください:
|
||
|
||
- 類似機能の実装パターンを確認
|
||
- 変更が必要なファイルを特定
|
||
- 使用すべき既存ライブラリ・ユーティリティを確認
|
||
- テストの既存パターンを確認
|
||
|
||
**重要**: 必ず既存実装を確認してから新規実装を検討すること
|
||
|
||
### 4. 実装計画の立案
|
||
|
||
以下の構造で実装計画を作成してください:
|
||
|
||
#### 4.1 概要
|
||
- Issueの要約
|
||
- 実装方針の概要
|
||
|
||
#### 4.2 タスク分解
|
||
実装を具体的なタスクに分解します:
|
||
|
||
1. **調査・設計フェーズ**
|
||
- 必要な技術調査
|
||
- 設計判断が必要な項目
|
||
|
||
2. **実装フェーズ**
|
||
- ファイル・モジュールごとの実装タスク
|
||
- 優先度と依存関係を明記
|
||
|
||
3. **テストフェーズ**
|
||
- ユニットテスト
|
||
- 統合テスト
|
||
- E2Eテスト（必要な場合）
|
||
|
||
4. **品質チェックフェーズ**
|
||
- 型チェック (`pnpm typecheck:all`)
|
||
- Lint (`pnpm lint`)
|
||
- ビルド確認 (`pnpm build`)
|
||
|
||
#### 4.3 技術的考慮事項
|
||
- 使用する技術・ライブラリ
|
||
- アーキテクチャ上の判断
|
||
- パフォーマンスへの影響
|
||
- セキュリティ上の注意点
|
||
|
||
#### 4.4 リスクと対策
|
||
- 想定されるリスク
|
||
- 各リスクへの対策
|
||
|
||
### 5. TodoListの作成
|
||
|
||
TodoWriteツールを使用して、実装タスクをTodoListとして登録してください。
|
||
タスクは以下の形式で:
|
||
- content: 実施すべきタスク（命令形）
|
||
- activeForm: 実施中の状態（進行形）
|
||
- status: pending
|
||
|
||
### 6. ユーザーへの確認
|
||
|
||
計画内容をユーザーに提示し、以下を確認してください:
|
||
- この計画で進めて良いか
|
||
- 優先度や順序の調整が必要か
|
||
- 追加で考慮すべき点はないか
|
||
|
||
## 出力形式
|
||
|
||
計画書はMarkdown形式で、見やすく構造化して出力してください。
|
||
|
||
## 注意事項
|
||
|
||
- `any`型の使用は厳禁
|
||
- 場当たり的な対応は禁止（「一時的」「とりあえず」等の表現は使わない）
|
||
- 根本的な解決を目指す
|
||
- 既存の実装パターンを必ず確認する
|
||
- プライドを持って設計を行う
|
||
|
||
---
|
||
|
||
Issue: $ARGUMENTS
|