Create Issue

# Create Issue Command - Issue品質保証エージェント

このコマンドは**Issue作成時の品質を保証**し、プロジェクトのIssue管理標準に完全準拠したIssueを作成します。

**このエージェントは以下のドキュメントを完全に統合しています：**
- `docs/PROJECT_MANAGEMENT/ISSUE_CREATION_GUIDE.md`
- `docs/PROJECT_MANAGEMENT/ISSUE_LABELS.md`

## 🎯 基本方針

- **品質第一**: 作成前に必ず品質チェックを実行
- **標準準拠**: ラベル体系・命名規則・テンプレートを完全遵守
- **対話ベース**: ユーザーと議論しながら最適なIssue構造を決定
- **自動バリデーション**: 作成前に全項目を検証

## 📋 Issue作成の必須要件

### 1. タイトル規則

#### 通常のチケット
```
簡潔で具体的な説明（何が課題か一目でわかる）

✅ 良い例:
- ユーザー登録時のメール認証機能
- ログイン画面でパスワード保存が機能しない
- ダッシュボードページの読み込み速度改善

❌ 悪い例:
- バグあり
- 修正
- 改善案
```

#### 親チケット
```
[親チケット] 簡潔で具体的な説明

✅ 良い例:
- [親チケット] README.mdドキュメント整備・拡充
- [親チケット] ユーザー認証システム刷新
- [親チケット] パフォーマンス最適化プロジェクト

❌ 悪い例:
- [親チケット] いろいろ改善
- 親チケット: 機能追加（フォーマット違反）
```

### 2. 必須ラベル体系

すべてのIssueには以下の**3種類のラベル**が**必須**です：

#### A. 優先度ラベル（priority:）- 必須1つ

| ラベル | 色 | 説明 | 使用例 |
|--------|-----|------|--------|
| `priority:P0` | 🔴 | 最高優先度（緊急・重要）| 本番障害、セキュリティ脆弱性、リリースブロッカー |
| `priority:P1` | 🟡 | 高優先度（重要）| 主要機能追加、パフォーマンス改善、重要なリファクタリング |
| `priority:P2` | 🔵 | 中優先度（通常・デフォルト）| 機能改善、リファクタリング、ドキュメント、テスト |

**優先度の決定基準:**

**P0（最高優先度）**
- 本番環境に影響するバグ
- セキュリティ脆弱性
- リリースを阻害する問題
- ユーザー体験を著しく損なう問題

**P1（高優先度）**
- 新機能開発のメイン機能
- パフォーマンスの大幅改善
- 重要なリファクタリング

**P2（中優先度）**
- UI/UXの改善
- 小規模な機能追加
- ドキュメント整備
- テストカバレッジ向上

#### B. サイズラベル（size:）- 必須1つ

| ラベル | 色 | 目安時間 | 説明 |
|--------|-----|----------|------|
| `size:S` | 🔴 | 1-2日 | 単一ファイル修正、設定変更、小さなUI調整、簡単なバグ修正 |
| `size:M` | 🟡 | 3-5日 | 複数ファイル変更、新規コンポーネント作成、既存機能拡張、テスト追加 |
| `size:L` | 🔵 | 1週間以上 | 新しい主要機能開発、データベース変更、アーキテクチャ変更、CI/CD構築 |

#### C. 実装内容ラベル（type-*:）- 必須1つ以上

**基本的な作業（type-basic:）**

| ラベル | 色 | 説明 |
|--------|-----|------|
| `type-basic:bugfix` | 🔴 | バグ修正（機能不具合、エラー修正） |
| `type-basic:enhancement` | 🟠 | 既存機能改善（UI/UX改善、ユーザビリティ向上） |
| `type-basic:feature` | 🟢 | 新機能追加（新しい機能・ページの実装） |
| `type-basic:refactor` | 🟣 | リファクタリング（コード整理、構造改善） |

**インフラ・技術（type-infra:）**

| ラベル | 色 | 説明 |
|--------|-----|------|
| `type-infra:automation` | 🟠 | 自動化・スクリプト（ビルドスクリプト、自動化ツール） |
| `type-infra:ci-cd` | 🔵 | CI/CD・パイプライン（GitHub Actions、デプロイ設定） |
| `type-infra:performance` | 🔵 | パフォーマンス改善（速度最適化、メモリ効率化） |
| `type-infra:security` | 🔴 | セキュリティ（脆弱性修正、認証・認可強化） |

**品質・ドキュメント（type-quality:）**

| ラベル | 色 | 説明 |
|--------|-----|------|
| `type-quality:docs` | 🔵 | ドキュメント（README更新、コメント追加、仕様書作成） |
| `type-quality:test` | 🟡 | テスト関連（ユニットテスト、E2Eテスト、カバレッジ） |

#### D. コンポーネントラベル（component:）- 推奨

| ラベル | 説明 |
|--------|------|
| `component:auth` | 認証関連 |
| `component:ui` | UI/UXコンポーネント |
| `component:api` | API関連 |
| `component:database` | DB関連 |
| `component:security` | セキュリティ |
| `component:documentation` | ドキュメント関連 |
| `component:testing` | テスト関連 |

#### E. 特殊ラベル（z-）- オプション

| ラベル | 説明 |
|--------|------|
| `z-good-first-issue` | 初心者向けタスク |
| `z-help-wanted` | コミュニティ協力歓迎 |

### 3. 親チケット・子チケット管理

#### 親チケットの作成方針

- **大きな機能・改善の全体管理**: 複数の作業に分割される場合
- **子チケット統合・調整**: 各子チケットの進捗を統合
- **実装順序の管理**: 子チケット間の依存関係・推奨順序を明記
- **タイトル形式**: 必ず `[親チケット]` で開始
- **サイズ**: 通常 `size:L` または `size:M`

#### 子チケットの作成方針

- **具体的な実装タスク**: 1-2日で完了可能な作業単位
- **親チケット関連付け**: 本文に `親チケット: #XXX` を必ず記載
- **独立した価値提供**: 単体で意味のある成果物を作成
- **サイズ**: 通常 `size:S` または `size:M`

#### 作業優先度

1. **子チケットを優先的に実装** - 具体的な成果を早期に提供
2. **親チケットは統合・調整で使用** - 全体の進捗管理・品質保証

#### 命名規則例

```
親チケット: [親チケット] README.mdドキュメント整備・拡充
  子チケット: src/ディレクトリREADME.md作成
  子チケット: tests/ディレクトリREADME.md作成
  子チケット: docs/ディレクトリREADME.md作成

親チケット: [親チケット] ユーザー認証システム強化
  子チケット: パスワード強度チェック機能追加
  子チケット: 二段階認証システム実装
  子チケット: セッション管理機能改善
```

## 🔍 Issue作成前の品質チェック項目

このエージェントは以下を**自動的にチェック**します：

### 必須項目チェック
- [ ] タイトルが具体的で明確か
- [ ] 親チケットの場合、`[親チケット]` で開始しているか
- [ ] 優先度ラベル（priority:P0/P1/P2）が1つ設定されているか
- [ ] サイズラベル（size:S/M/L）が1つ設定されているか
- [ ] 実装内容ラベル（type-*:）が1つ以上設定されているか
- [ ] 子チケットの場合、親チケット番号（#XXX）が記載されているか

### 推奨項目チェック
- [ ] コンポーネントラベル（component:）が設定されているか
- [ ] 受け入れ条件が明確に記載されているか
- [ ] 技術的要件が記載されているか
- [ ] テスト要件が記載されているか

### 整合性チェック
- [ ] タイトルと説明文の内容が一致しているか
- [ ] ラベルの組み合わせが適切か（例: bugfix + size:L は通常不適切）
- [ ] 優先度とサイズが矛盾していないか

## 📝 Issueテンプレート

### 機能要求（Feature Request）

```markdown
## 📝 機能概要

[簡潔に機能の概要を説明]

## 🎯 目的・背景

[なぜこの機能が必要なのか]

## ✅ 受け入れ条件

- [ ] 条件1
- [ ] 条件2
- [ ] 条件3

## 🎨 UI/UX要件（該当時）

- デザインモックアップ
- ユーザビリティ要件

## 🔧 技術的要件

- 使用技術・ライブラリ
- パフォーマンス要件
- セキュリティ考慮事項

## 🧪 テスト要件

- [ ] ユニットテスト
- [ ] E2Eテスト
- [ ] セキュリティテスト

## 📚 参考資料

- 関連Issue
- 外部ドキュメント
- 技術記事等
```

### バグ報告（Bug Report）

```markdown
## 🐛 バグ概要

[バグの内容を簡潔に説明]

## 🔄 再現手順

1.
2.
3.

## 🎯 期待される動作

[正常に動作した場合の挙動]

## ❌ 実際の動作

[実際に発生している問題]

## 🖥️ 環境情報

- ブラウザ: Chrome 120.0
- OS: Windows 11
- Node.js: v18.17.0
- npm: v9.8.1

## 📸 スクリーンショット・ログ

(エラースクリーンショット、コンソールログ等)

## 🔧 調査情報

- エラーメッセージ
- スタックトレース
- 関連するコード箇所

## 🚨 影響度

- [ ] 機能停止
- [ ] パフォーマンス低下
- [ ] UI表示問題
- [ ] データ不整合
```

### 親チケットテンプレート

```markdown
## 📋 プロジェクト概要

[大規模機能・改善の全体像を説明]

## 🎯 目的

[なぜこのプロジェクトが必要なのか]

## 📦 子チケット一覧

- [ ] #XXX - [子チケット名1]
- [ ] #XXX - [子チケット名2]
- [ ] #XXX - [子チケット名3]

## 🔄 実装順序・依存関係

1. 最初に #XXX を実装（基盤）
2. 次に #XXX と #XXX を並行実装
3. 最後に #XXX で統合

## ✅ 全体の受け入れ条件

- [ ] すべての子チケットが完了
- [ ] 統合テストが通過
- [ ] ドキュメントが更新済み

## 📚 関連資料

- 設計ドキュメント
- 技術仕様書
```

## 🚀 実行フロー

### 1. 要件ヒアリング
- 何を実現したいかの議論
- 背景・目的の整理
- 技術的制約・要件の確認

### 2. Issue構造の提案
- 単一Issue vs 親子チケット構造の判定
- 適切な作業分割の提案
- 優先度・作業規模の相談

### 3. 品質チェック実行
- タイトル規則の確認
- 必須ラベルの確認
- テンプレート項目の確認
- 親子関係の整合性確認

### 4. 内容詳細化
- タイトル・説明文の作成
- 受け入れ条件の明確化
- テンプレート選択（feature/bug/parent等）

### 5. ラベル・メタデータ決定
- 優先度（P0/P1/P2）の決定
- 作業規模（S/M/L）の見積もり
- 実装内容タイプの分類
- コンポーネント・カテゴリの分類

### 6. 最終バリデーション
- すべての必須項目を再確認
- 推奨項目の確認
- 整合性の最終チェック

### 7. Issue作成実行
- GitHub CLIでIssue作成
- 親子関係がある場合は適切にリンク設定
- 作成結果の確認・レビュー

## 💻 使用方法

```bash
# Issue品質保証エージェントを起動
/create-issue
```

**引数なし**: 対話的にIssue内容を決定し、品質チェックを実行しながら作成

## 📌 実装例

### 例1: 通常のFeature Issue作成

```bash
gh issue create \
  --title "ダッシュボードに最近の日記一覧を表示" \
  --body "$(cat <<'EOF'
## 📝 機能概要
ダッシュボードページに最近の日記エントリ5件を表示する機能を追加

## 🎯 目的・背景
ユーザーが最近の振り返りを素早く確認できるようにする

## ✅ 受け入れ条件
- [ ] 最新5件の日記が表示される
- [ ] 日付順にソートされている
- [ ] クリックで詳細ページに遷移できる

## 🔧 技術的要件
- Vue 3 Composition API使用
- Supabaseからデータ取得
- ローディング状態の表示

## 🧪 テスト要件
- [ ] ユニットテスト作成
- [ ] E2Eテスト追加
EOF
)" \
  --label "priority:P2,size:S,type-basic:feature,component:ui"
```

### 例2: 親チケット作成

```bash
gh issue create \
  --title "[親チケット] 日記検索機能の実装" \
  --body "$(cat <<'EOF'
## 📋 プロジェクト概要
日記エントリの検索機能を実装し、ユーザーが過去の振り返りを効率的に見つけられるようにする

## 🎯 目的
大量の日記エントリから特定の内容を素早く検索できるようにする

## 📦 子チケット一覧
- [ ] #XXX - 検索UI実装
- [ ] #XXX - 検索APIエンドポイント作成
- [ ] #XXX - 全文検索インデックス構築

## 🔄 実装順序・依存関係
1. 最初に検索APIエンドポイント作成（基盤）
2. 次に全文検索インデックス構築
3. 最後に検索UI実装

## ✅ 全体の受け入れ条件
- [ ] すべての子チケットが完了
- [ ] 統合テストが通過
- [ ] パフォーマンステスト通過
EOF
)" \
  --label "priority:P1,size:L,type-basic:feature,component:api,component:ui"
```

### 例3: バグ修正Issue作成

```bash
gh issue create \
  --title "ログイン画面でパスワードが保存されない" \
  --body "$(cat <<'EOF'
## 🐛 バグ概要
ログイン画面で「パスワードを保存」をチェックしても次回ログイン時にパスワードが保存されていない

## 🔄 再現手順
1. ログインページにアクセス
2. メールアドレスとパスワードを入力
3. 「パスワードを保存」にチェック
4. ログイン成功
5. ログアウト
6. 再度ログインページにアクセス
7. パスワード欄が空白

## 🎯 期待される動作
パスワードが自動入力される

## ❌ 実際の動作
パスワード欄が空白のまま

## 🖥️ 環境情報
- ブラウザ: Chrome 120.0
- OS: Windows 11

## 🚨 影響度
- [x] UI表示問題
EOF
)" \
  --label "priority:P1,size:S,type-basic:bugfix,component:auth"
```

## 🔗 関連コマンド

```bash
# 既存Issue確認
gh issue list --state open

# ラベル一覧確認
gh label list

# Issue詳細確認
gh issue view [issue番号]

# Issue作成後の作業開始
/start-work
```

## 📚 参照情報

このエージェントは以下のドキュメントを統合しています：
- **ISSUE_CREATION_GUIDE.md** - Issue作成ルール・テンプレート
- **ISSUE_LABELS.md** - ラベル体系・分類基準

その他の参照ドキュメント：
- **[CLAUDE.md](../../CLAUDE.md)** - 開発フロー・技術方針
- **[開発ワークフロー](../../docs/DEVELOPMENT/DEVELOPMENT_WORKFLOW.md)** - ブランチ戦略・PR手順

## ⚠️ 重要な注意事項

1. **必須ラベルは絶対に省略しない**
   - priority:（P0/P1/P2）
   - size:（S/M/L）
   - type-*:（basic/infra/quality）

2. **親チケットは必ず `[親チケット]` で開始**
   - `[親チケット]` の前後にスペース不要
   - 日本語で統一

3. **子チケットは親チケット番号を記載**
   - 本文に `親チケット: #XXX` を必ず含める

4. **品質チェックを必ず実行**
   - 作成前に全項目を確認
   - 不備がある場合は修正してから作成

## 🎯 期待される成果

- **高品質なIssue**: 標準に完全準拠したIssue
- **明確な要件定義**: 議論を通じた要件の明確化
- **適切なIssue構造**: 単一 vs 親子チケットの最適判断
- **正確な見積もり**: 作業規模・優先度の適切な設定
- **実装可能性**: 技術的制約を考慮した現実的なタスク設計