# github-issue-creator

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

- Author: Shinya Sakae
- Repository: ss49919201/keeput
- Version: 20260119230637
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/ss49919201/keeput
- Web: https://mule.run/skillshub/@@ss49919201/keeput~github-issue-creator:20260119230637

---

---
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形式を確認する。

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

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

詳細なフォーマットガイドは [issue_template.md](references/issue_template.md) を参照。

### 3. 要件の解析

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

**論理的な境界を特定**：
- 各個別の機能または機能性
- 各独立したタスクまたは変更
- ドメインやコンポーネントに基づく自然なグループ化

**設計ドキュメントの場合**：
- セクションヘッダーを探す（## 1., ## 2., ### 機能A）
- 自己完結した仕様を特定
- 要件間の依存関係に注意

**会話コンテキストの場合**：
- 議論を振り返り、合意された要件を特定
- 要件を分割または結合すべきか、ユーザーに確認
- 曖昧な境界を明確化

### 4. Issueの作成

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

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

**タイトルのガイドライン**：
- 動作を表す動詞で始める（追加、実装、修正など）
- 何が変更または追加されるかを明確に記述
- 簡潔だが情報量のあるものにする

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

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

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

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

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

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

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

### 5. バッチ作成

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

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

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

### 6. ユーザーへの報告

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

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

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

## 一般的なパターン

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

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

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

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

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

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

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

```markdown
ユーザー: "この要件を実装用、テスト用、ドキュメント用の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の数が多すぎる/少なすぎる**:
- ユーザーと要件の分割について議論
- 作成前に望ましい粒度を確認