name: github-issue-creator description: 要件、設計ドキュメント、会話内容からGitHub Issueを作成する。ユーザーが計画ドキュメントからIssueを作成したい、要件をIssueに変換したい、タスクをIssueとして登録したい、または複数の関連するIssueをまとめて作成したい場合に使用。「この要件をIssueに登録」「plan.mdをIssueにして」「要件ごとにIssueを作って」などのリクエストでトリガーされる。

GitHub Issue Creator

要件ドキュメント、会話、設計仕様から適切な構造のGitHub Issueを作成します。

使用タイミング

以下の場合にこのSkillを使用：

• ユーザーが計画書や設計ドキュメントからIssueを作成したい
• 要件をGitHub Issueとして登録する必要がある
• 単一のソースから複数の関連Issueを作成する
• 会話の結果を追跡可能なIssueに変換したい

ワークフロー

1. 情報源の理解

要件がどこから来ているかを特定：

• 設計ドキュメント: plan.md、design.md、specification.md
• 会話コンテキスト: 現在の会話で議論された要件
• 既存Issue: 類似または関連するIssueの作成

2. リポジトリのIssue形式を学習

重要: 新しいIssueを作成する前に、必ずリポジトリの既存Issue形式を確認する。

# 既存Issueを取得して形式を理解
gh issue list --limit 3 --json number,title,body,labels --state all

分析項目：

• タイトルの慣習（言語、動詞の使い方、構造）
• 本文の形式（セクション、Markdownの使い方）
• 仕様、例、参照の使用方法
• 言語の選択（日本語/英語）

詳細なフォーマットガイドは issue_template.md を参照。

3. 要件の解析

複数の要件が含まれる場合：

論理的な境界を特定：

• 各個別の機能または機能性
• 各独立したタスクまたは変更
• ドメインやコンポーネントに基づく自然なグループ化

設計ドキュメントの場合：

• セクションヘッダーを探す（## 1., ## 2., ### 機能A）
• 自己完結した仕様を特定
• 要件間の依存関係に注意

会話コンテキストの場合：

• 議論を振り返り、合意された要件を特定
• 要件を分割または結合すべきか、ユーザーに確認
• 曖昧な境界を明確化

4. Issueの作成

各要件に対して、gh issue createを使用してIssueを作成：

gh issue create --title "タイトル" --body "$(cat <<'EOF'
[Issue本文の内容]
EOF
)"

タイトルのガイドライン：

• 動作を表す動詞で始める（追加、実装、修正など）
• 何が変更または追加されるかを明確に記述
• 簡潔だが情報量のあるものにする

本文の構造（リポジトリの形式に合わせて調整）：

[目的の1〜2文の概要]

## 仕様
- [主要な仕様1]
- [主要な仕様2]
- [主要な仕様3]

## [要件タイプに応じたオプションセクション]
### 計算方法
[該当する場合の計算詳細]

### 出力例
[期待される出力の例]

### 判定基準
[該当する場合の判定基準]

## 関連
[plan.mdや他のドキュメントへの参照]

5. バッチ作成

複数のIssueを作成する場合：

1. 一貫性を保つ: すべてのIssueで同じ形式を使用
2. 順次作成: 一度に1つのgh issue createコマンドを実行
3. 作成されたIssueを追跡: 返されたIssue番号を記録
4. 作成を確認: 最近のIssueをリストして確認

# すべてのIssueが作成されたことを確認
gh issue list --limit 5 --json number,title,state

6. ユーザーへの報告

作成したIssueの概要を提供：

✅ 4件のIssueを作成しました:

- #104: 週次/月次の記事公開数を集計する機能を追加
- #105: 平均公開間隔（日数）を計算する機能を追加
- #106: 最長無投稿期間を計算する機能を追加
- #107: 過去30日間の公開傾向を判定する機能を追加

一般的なパターン

パターン1: plan.mdからの作成

ユーザー: "plan.mdの要件をIssueに登録して"

手順:
1. plan.mdを読んで要件セクションを特定
2. `gh issue list`で既存Issue形式を確認
3. 要件セクションごとに1つのIssueを作成
4. 各Issueの本文でplan.mdを参照

パターン2: 会話からの作成

ユーザー: "今話した3つの機能をIssueにして"

手順:
1. 会話を振り返り、議論された3つの機能を抽出
2. 既存Issue形式を確認
3. 不明確な場合はユーザーに分割方法を確認
4. 会話のコンテキストを含めてIssueを作成

パターン3: 関連Issueの作成

ユーザー: "この要件を実装用、テスト用、ドキュメント用の3つのIssueに分けて"

手順:
1. ベースとなる要件を理解
2. 適切なスコープで3つのIssueを作成:
   - 実装Issue
   - テストIssue
   - ドキュメントIssue
3. Issueの本文で相互参照

ベストプラクティス

1. 常に既存形式を最初に確認: 推測せず、実際のIssueを検査
2. 本文にはheredocを使用: 適切なフォーマットと特殊文字の処理を保証
3. Issueを焦点を絞ったものにする: 1つの論理的な作業単位ごとに1つのIssue
4. 例を含める: 具体的な例で要件をより明確に
5. ソースにリンク: 計画ドキュメントや会話を参照
6. 作成を確認: すべてのIssueが正常に作成されたことを確認
7. リポジトリの言語を使用: 既存Issueの言語に合わせる（通常は日本語）

トラブルシューティング

Issue作成が失敗する:

• gh CLIが認証されているか確認
• gitリポジトリ内にいることを確認
• heredoc構文が正しいか確認

形式が間違っている:

• gh issue view <number>で既存Issueを再確認
• 観察されたパターンに基づいてテンプレートを調整

Issueの数が多すぎる/少なすぎる:

• ユーザーと要件の分割について議論
• 作成前に望ましい粒度を確認