CommandMate: Command for Claude Code

Issue一括作成コマンド

概要

Issue分割計画書（issue-split.md）を解析し、GitHubにIssueを一括作成します。 親Issue（Feature）と子Issue（実装単位）の関連付けを自動で行い、進捗を可視化します。

使用方法

/issue-create <親Issue番号> [issue-split.mdのパス]

例:

/issue-create 152
/issue-create 152 dev-reports/feature/issue/152/issue-split.md

引数:

• <親Issue番号>: Feature Issue番号（必須）
• [issue-split.mdのパス]: Issue分割計画書のパス（省略時は自動検索）

実行内容

あなたはプロジェクトマネージャーです。Issue分割計画書から子Issueを一括作成し、親Issueと関連付けてください：

1. 事前確認

親Issueの検証

gh issue view <親Issue番号>

• 親Issueが存在するか確認
• Feature Issueであることを確認（ラベルに "feature" が含まれる）
• 既に子Issueが作成済みでないか確認

issue-split.mdの検索

引数で指定されない場合、以下の優先順位で検索：

1. dev-reports/feature/issue/<親Issue番号>/issue-split.md
2. カレントディレクトリの issue-split.md
3. dev-reports/**/issue-split.md（最新のもの）

2. issue-split.mdの解析

抽出する情報

• Issue一覧セクション:

  • Issue番号（例: #152-1）
  • タイトル
  • 概要
  • サイズ（S/M/L）
  • 優先度（High/Medium/Low）
  • 作業見積（時間）
  • 担当候補
  • スコープ
  • 技術スタック
  • 受入基準（2層構造）

• Phase情報:

  • Phase番号
  • Phase名
  • 各Issueの所属Phase
  • Phase完了条件
  • Phaseの実行順序（Week情報）
  • 並列実行マーク（⚡）の有無

• 依存関係:

  • 依存先Issue（ブロックされる側）
  • ブロック対象Issue（ブロックする側）
  • 並列実行可能性
  • 依存関係マトリクスからの情報

3. 子Issueの一括作成

Issue作成ループ

各Issueについて以下を実行：

gh issue create \
  --title "Issue #<親Issue番号>-<連番>: <タイトル>" \
  --body "$(cat /tmp/issue-body-<連番>.md)" \
  --label "<サイズ>,<優先度>,feature,<Phase>" \
  --assignee "@me" \
  --project "MyCodeBranchDesk"

Issue本文のテンプレート

**親Issue**: #<親Issue番号>
**Phase**: <Phase名>
**サイズ**: <サイズ> (<作業見積>)
**優先度**: <優先度>

## 概要
<概要>

## 依存関係
<依存先Issueのリスト>

## ブロック対象
<ブロックするIssueのリスト>

## スコープ
<スコープのチェックリスト>

## 技術スタック
<技術スタック>

## 受入基準 (Acceptance Criteria)

### 🤖 自動検証可能な基準（pm-auto-devが実施）

**機能要件**:
<機能要件のチェックリスト>

**品質基準**:
<品質基準のチェックリスト>

> **`npm run test:unit`（テスト全体）を受入基準に書くときは「検証ゲートが実行する」と添える。**
> 添えないと、`/orchestrate` のオーケストレーターが受入基準をそのままワーカーの goal へ写し、
> ワーカーのテスト全体と検証ゲートが同じマシンで競合する（`verify` は `mutex: cpu.heavy` を取るが
> ワーカーの直接実行は取らない）。2026-09-20 の run では、これで通っているはずのゲートが
> 失敗テスト 0 件のまま exit 1 になった。詳細は `/orchestrate` の 2-4-2「差し替えの条件」。

**テストケース**:
<テストケースのチェックリスト>

### 👤 手動検証が必要な基準（ユーザーが実施）

**UX/UI検証**:
<UX/UI検証のチェックリスト>

**ビジネスロジック検証**:
<ビジネスロジック検証のチェックリスト>

**運用検証**:
<運用検証のチェックリスト>

## 逸脱時の扱い

**本文に書かれていない変更が必要に見えた場合は、そのファイルを変更せず報告すること**（勝手に直さない）。
コミットメッセージ本文に「本文に無い指摘: `<file>:<line>` `<内容>`」と書く。どう扱うかはオーケストレーターが決める。

このIssueで実際に起こりうる逸脱:

<このIssue固有の逸脱を列挙する。汎用の定型文にしない。例:
- 本文が「既存の型エラーは 0 件」を前提にしているが、実際には残っていた → **型エラーを直さず**報告する
- 本文に挙げた <N> 件以外の指摘が同じルールで出た → そのファイルを変更せず報告する
- 本文が引用している既存コード（`<file>:<line>`）が、実コードと食い違っていた>

いずれの場合も、**実コードを正とし、判断をコミットメッセージ本文に書く**。

---

📄 **詳細**: [Issue分割計画書](<issue-split.mdへのリンク>)