tomevault-io GitHub Issue作成
.github/ISSUE_TEMPLATE/のテンプレート形式に準拠したGitHub Issueを作成します。
利用可能なテンプレート
| テンプレート | 用途 | ラベル |
|---|---|---|
| bug_report.yml | バグ報告 | bug |
| feature_request.yml | 機能リクエスト | enhancement |
| todo.yml | タスク・作業項目 | todo |
Issue作成原則
- テンプレート準拠: 必ず既存のテンプレート形式に従う
- 適切な粒度: Pull Requestの粒度と対応するサイズに分割
- 分割戦略: 大きすぎる場合は複数のIssueに分割
- 明確な受け入れ基準: 完了条件を明確に定義
- 関連性の明示: 関連するIssueやPRをリンク
Issue粒度ガイドライン
適切な粒度
- 1つのPRで完結できる作業単位
- 1〜3日程度で完了可能なタスク
- 明確な受け入れ基準を持つ
- 単一の責任を持つ変更
分割が必要なケース
- 複数の機能を含む大規模な変更
- 異なるコンポーネントへの変更
- 段階的にリリースすべき機能
- 依存関係が複雑なタスク
分割戦略
- 機能単位: 各機能を独立したIssueに
- レイヤー単位: フロントエンド/バックエンドで分割
- 段階単位: Phase 1, Phase 2として分割
- 依存関係順: 依存関係に基づいて順序付け
メイン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作成のガイドライン
作成タイミング
- メインissueを作成した直後
- 実装計画が明確になった時点
- 必要に応じて段階的に追加
粒度の目安
- 1〜3日で完了可能な作業量
- 単一の機能や責任を持つ変更
- 他のsub issueと独立してマージ可能
- レビューが容易なサイズ（変更ファイル数: 概ね10ファイル以下）
命名規則
[メインissue番号] 具体的な作業内容
例:
#123 ユーザー認証APIの実装#123 認証ミドルウェアの追加#123 認証機能のフロントエンド統合
タイトルの付け方
- メインissue番号を含める（任意だが推奨）
- 実装する機能や変更内容を明確に
- 動詞から始める（実装、追加、修正、更新など）
メインissue本文での進捗管理
メインissueの本文にタスクリストを使用してsub issueを管理します。
タスクリストの書き方
## Sub Issues
- [ ] #456 データベーススキーマの設計と実装
- [ ] #457 APIエンドポイントの実装
- [ ] #458 フロントエンドUIの実装
- [ ] #459 テストコードの追加
GitHubの自動連携
- sub issueがクローズされると、タスクリストのチェックボックスが自動的にチェックされる
- メインissueの進捗が視覚的に把握できる
- すべてのチェックボックスがチェックされたら、メインissueをクローズ
sub issueの関連付け方法
メインissue → sub issue
メインissueの本文に記載:
## Sub Issues
このissueは以下のsub issueに分割されています:
- [ ] #456 データベーススキーマの設計と実装
- [ ] #457 APIエンドポイントの実装
- [ ] #458 フロントエンドUIの実装
sub issue → メインissue
sub issueの本文に記載:
## 関連Issue
親issue: #123
PR → sub issue
PRの本文に記載:
Closes #456
活用例
例: ユーザー認証機能の実装
メインissue #123: ユーザー認証機能の実装
## 説明
ユーザー認証機能を実装し、ログイン・ログアウト・セッション管理を可能にする。
## Sub Issues
- [ ] #124 データベースにusersテーブルを追加
- [ ] #125 認証APIエンドポイントの実装
- [ ] #126 認証ミドルウェアの追加
- [ ] #127 ログイン画面UIの実装
- [ ] #128 認証機能の統合テスト
## 完了条件
- すべてのsub issueが完了している
- 統合テストがパスしている
- ドキュメントが更新されている
sub issue #124: データベースにusersテーブルを追加
## 説明
ユーザー認証に必要なusersテーブルをデータベースに追加する。
## 関連Issue
親issue: #123
## 受け入れ基準
- [ ] マイグレーションファイルが作成されている
- [ ] id, email, password_hash, created_at, updated_atカラムが含まれる
- [ ] emailカラムにユニーク制約が設定されている
PR #150: データベースにusersテーブルを追加
## 概要
ユーザー認証機能のためのusersテーブルを追加します。
Closes #124
## 変更内容
- usersテーブルのマイグレーションファイルを追加
- ...
注意事項
- 過度な分割を避ける: 小さすぎるsub issueは管理コストが増加
- 依存関係を明確に: sub issue間の依存関係がある場合は本文に記載
- 柔軟な調整: 実装中に粒度が適切でないと判明した場合は再分割や統合を検討
- 命名の一貫性: プロジェクト内で命名規則を統一
テンプレート別の記載項目
Bug Report (バグレポート)
- 説明: バグの内容を明確に記述
- 再現手順: ステップバイステップで記載
- 期待される動作: 正常な動作の説明
- 実際の動作: 発生している問題
- 環境: Development/Staging/Production
- スクリーンショット: 必要に応じて添付
Feature Request (機能リクエスト)
- 問題提起: 解決したい課題
- 提案する解決策: 実装したい内容
- 検討した代替案: 他の選択肢
- 追加情報: モックアップ、参考資料
TODO (タスク)
- 説明: 実施内容の明確な記述
- 優先度: Low/Medium/High/Critical
- カテゴリ: Feature/Enhancement/Refactoring/Documentation/Testing/Infrastructure/Other
- 受け入れ基準: 完了条件のチェックリスト
- 技術的メモ: 実装の詳細や考慮事項
- 関連Issue: 関連するIssue/PRのリンク
Issue作成手順
- 要件分析: 依頼内容の理解と分析
- 粒度判定: 適切なサイズか評価
- 分割判断: 必要に応じて複数Issueに分割
- テンプレート選択: 適切なテンプレートを選択
- 内容作成: テンプレートの全項目を埋める
- 関連性設定: 関連IssueやPRをリンク
- Issue作成:
gh issue createコマンドで作成
出力形式
単一Issue作成時
- テンプレート種別
- タイトル
- 各フィールドの内容
- ラベル
- 作成コマンド
複数Issue作成時（分割）
- 分割理由の説明
- 各Issueの概要と関連性
- Issue間の依存関係
- 各Issueの詳細（上記と同様）
- 作成順序の推奨
Converted and distributed by TomeVault — claim your Tome and manage your conversions.