---

name: github-issue description: "GitHub Issue作成スキル。.github/ISSUE_TEMPLATE/のテンプレート形式に準拠したIssueを作成。Use when: Issue作成、タスク管理、バグ報告、機能提案を依頼された時。"

GitHub Issue作成

.github/ISSUE_TEMPLATE/のテンプレート形式に準拠したGitHub Issueを作成します。

利用可能なテンプレート

Issue作成原則

1. テンプレート準拠: 必ず既存のテンプレート形式に従う
2. 適切な粒度: Pull Requestの粒度と対応するサイズに分割
3. 分割戦略: 大きすぎる場合は複数のIssueに分割
4. 明確な受け入れ基準: 完了条件を明確に定義
5. 関連性の明示: 関連するIssueやPRをリンク

Issue粒度ガイドライン

適切な粒度

• 1つのPRで完結できる作業単位
• 1〜3日程度で完了可能なタスク
• 明確な受け入れ基準を持つ
• 単一の責任を持つ変更

分割が必要なケース

• 複数の機能を含む大規模な変更
• 異なるコンポーネントへの変更
• 段階的にリリースすべき機能
• 依存関係が複雑なタスク

分割戦略

1. 機能単位: 各機能を独立したIssueに
2. レイヤー単位: フロントエンド/バックエンドで分割
3. 段階単位: Phase 1, Phase 2として分割
4. 依存関係順: 依存関係に基づいて順序付け

メインissueとsub issueの活用

大きな機能や改善を複数のPRに分割して実装する場合、メインissueとsub issueの親子関係を活用します。

メインissueとsub issueの定義

メインissue

• 目的: 全体として達成したい大きな機能や改善を表現
• 役割:
  • プロジェクト全体の目的と背景を説明
  • すべてのsub issueの進捗を一元管理
  • 完了条件（Definition of Done）を明確化
• 粒度: 複数のPRに分割される大規模な作業
• 完了条件: すべてのsub issueが完了した時点でクローズ

sub issue

• 目的: メインissueを実装可能な単位に分割したタスク
• 役割:
  • 個別のPRと1対1で対応
  • 具体的な実装内容を詳細に記述
  • 独立してレビュー・マージ可能な作業単位
• 粒度: 1つのPRで完結できるサイズ（1〜3日程度）
• 完了条件: 対応するPRがマージされた時点でクローズ

sub issueとPRの関係

• 1対1の原則: 1つのsub issueは必ず1つのPRに対応
• 自動クローズ: PRマージ時に Closes #123 で自動的にsub issueをクローズ
• 進捗の可視化: メインissueのタスクリストでsub issueの完了状況を追跡

sub issue作成のガイドライン

作成タイミング

1. メインissueを作成した直後
2. 実装計画が明確になった時点
3. 必要に応じて段階的に追加

粒度の目安

• 1〜3日で完了可能な作業量
• 単一の機能や責任を持つ変更
• 他のsub issueと独立してマージ可能
• レビューが容易なサイズ（変更ファイル数: 概ね10ファイル以下）

命名規則

Copy[メインissue番号] 具体的な作業内容

例:

• #123 ユーザー認証APIの実装
• #123 認証ミドルウェアの追加
• #123 認証機能のフロントエンド統合

タイトルの付け方

• メインissue番号を含める（任意だが推奨）
• 実装する機能や変更内容を明確に
• 動詞から始める（実装、追加、修正、更新など）

メインissue本文での進捗管理

メインissueの本文にタスクリストを使用してsub issueを管理します。

タスクリストの書き方

Copy## Sub Issues

- [ ] #456 データベーススキーマの設計と実装
- [ ] #457 APIエンドポイントの実装
- [ ] #458 フロントエンドUIの実装
- [ ] #459 テストコードの追加

GitHubの自動連携

• sub issueがクローズされると、タスクリストのチェックボックスが自動的にチェックされる
• メインissueの進捗が視覚的に把握できる
• すべてのチェックボックスがチェックされたら、メインissueをクローズ

sub issueの関連付け方法

メインissue → sub issue

メインissueの本文に記載:

Copy## Sub Issues

このissueは以下のsub issueに分割されています:

- [ ] #456 データベーススキーマの設計と実装
- [ ] #457 APIエンドポイントの実装
- [ ] #458 フロントエンドUIの実装

sub issue → メインissue

sub issueの本文に記載:

Copy## 関連Issue

親issue: #123

PR → sub issue

PRの本文に記載:

CopyCloses #456

活用例

例: ユーザー認証機能の実装

メインissue #123: ユーザー認証機能の実装

Copy## 説明

ユーザー認証機能を実装し、ログイン・ログアウト・セッション管理を可能にする。

## Sub Issues

- [ ] #124 データベースにusersテーブルを追加
- [ ] #125 認証APIエンドポイントの実装
- [ ] #126 認証ミドルウェアの追加
- [ ] #127 ログイン画面UIの実装
- [ ] #128 認証機能の統合テスト

## 完了条件

- すべてのsub issueが完了している
- 統合テストがパスしている
- ドキュメントが更新されている

sub issue #124: データベースにusersテーブルを追加

Copy## 説明

ユーザー認証に必要なusersテーブルをデータベースに追加する。

## 関連Issue

親issue: #123

## 受け入れ基準

- [ ] マイグレーションファイルが作成されている
- [ ] id, email, password_hash, created_at, updated_atカラムが含まれる
- [ ] emailカラムにユニーク制約が設定されている

PR #150: データベースにusersテーブルを追加

Copy## 概要

ユーザー認証機能のためのusersテーブルを追加します。

Closes #124

## 変更内容

- usersテーブルのマイグレーションファイルを追加
- ...

注意事項

1. 過度な分割を避ける: 小さすぎるsub issueは管理コストが増加
2. 依存関係を明確に: sub issue間の依存関係がある場合は本文に記載
3. 柔軟な調整: 実装中に粒度が適切でないと判明した場合は再分割や統合を検討
4. 命名の一貫性: プロジェクト内で命名規則を統一

テンプレート別の記載項目

Bug Report (バグレポート)

• 説明: バグの内容を明確に記述
• 再現手順: ステップバイステップで記載
• 期待される動作: 正常な動作の説明
• 実際の動作: 発生している問題
• 環境: Development/Staging/Production
• スクリーンショット: 必要に応じて添付

Feature Request (機能リクエスト)

• 問題提起: 解決したい課題
• 提案する解決策: 実装したい内容
• 検討した代替案: 他の選択肢
• 追加情報: モックアップ、参考資料

TODO (タスク)

• 説明: 実施内容の明確な記述
• 優先度: Low/Medium/High/Critical
• カテゴリ: Feature/Enhancement/Refactoring/Documentation/Testing/Infrastructure/Other
• 受け入れ基準: 完了条件のチェックリスト
• 技術的メモ: 実装の詳細や考慮事項
• 関連Issue: 関連するIssue/PRのリンク

Issue作成手順

1. 要件分析: 依頼内容の理解と分析
2. 粒度判定: 適切なサイズか評価
3. 分割判断: 必要に応じて複数Issueに分割
4. テンプレート選択: 適切なテンプレートを選択
5. 内容作成: テンプレートの全項目を埋める
6. 関連性設定: 関連IssueやPRをリンク
7. Issue作成: gh issue createコマンドで作成

出力形式

単一Issue作成時

• テンプレート種別
• タイトル
• 各フィールドの内容
• ラベル
• 作成コマンド

複数Issue作成時（分割）

• 分割理由の説明
• 各Issueの概要と関連性
• Issue間の依存関係
• 各Issueの詳細（上記と同様）
• 作成順序の推奨