parallel-issues

name	parallel-issues
description	GitHub issue を sub-issue に分解し、worktree 分離した並行エージェントで実装、読み取り専用の検証ゲートを経て、コンフリクト検知とマージ順序決定まで行う並行開発オーケストレーション手順。/parallel-issues <issue番号 or タスク概要> で起動する。
disable-model-invocation	true

parallel-issues

1つの issue（または大きめのタスク）を複数の sub-issue に分解し、worktree 分離した並行エージェントで実装して安全に合流させる。あなたはコーディネーターであり、実装はすべてサブエージェントに委譲する。

なぜこの手順か

並行開発の失敗は「実装そのもの」ではなく、(1) 分解の粒度ミスによる作業衝突、(2) 完了申告と実態の乖離、(3) 合流順序の誤りによるコンフリクト連鎖、で起きる。この手順は3点それぞれに独立したゲートを置く。

Phase 0: 前提確認

作業開始前に以下を確定させる。不明なものは推測せずユーザーに確認する。

• ベースブランチとテストコマンド（プロジェクト固有のため、CLAUDE.md やタスクランナー定義から候補を挙げてユーザーに確認する）
• 作業ツリーがクリーンであること（git status）
• 対象 issue の内容（gh issue view などで実際に読む。タイトルだけで分解しない）

Phase 1: 分解（codebase-verified）

1. issue を読み、関連コードを実際に調べたうえで sub-issue 案を作る。コードを読まずに issue 本文だけから分解しない（分解の妥当性はコードの実態が決める）。
2. 各 sub-issue に対し「触るはずのファイル・モジュール範囲」を明記する。範囲が重なる sub-issue は並行させず、統合するか依存関係として直列化する。
3. 分解案（sub-issue 一覧・依存関係・並行度）をユーザーに提示し、承認を得てから fan-out する。ここが人間の判断を挟む唯一の必須ポイント。

Phase 2: fan-out（worktree 分離）

• 1 sub-issue = 1 エージェントとし、それぞれを worktree 分離で起動する（Agent tool の worktree isolation など、利用中のエージェント環境が提供する分離機構を使う）。
• 各エージェントへの指示には必ず含める:
  • sub-issue の完了条件と「触ってよいファイル範囲」
  • テストコマンドと「テストが通るまで完了申告しないこと」
  • 返答フォーマット: 変更ファイル一覧・変更概要・テスト実行結果（生ログではなく要約）
• 依存関係のある sub-issue は先行タスクの検証ゲート通過後に起動する。

Phase 3: 検証ゲート（申告を信用しない）

各エージェントの完了申告ごとに、読み取り専用の検証を通す。

• verifier エージェント定義が利用可能ならそれを使う。なければ、同等の内容（変更ファイルの実読・破損チェック・git diff 照合・テスト再実行・申告との差分報告）を読み取り専用のサブエージェントに直接指示する。
• 検証には「申告された変更ファイル一覧・変更意図・テストコマンド」を明示的に渡す。
• FAIL / PARTIAL は該当エージェントに差し戻す。2回差し戻しても解消しない場合は自力で直そうとせず、ユーザーにエスカレーションする（分解の前提が崩れているサイン）。

Phase 4: 合流（コンフリクト検知とマージ順序）

1. 全 worktree の変更ファイル一覧を突き合わせ、重なりを検出する。重なりがあれば、その組は同時マージせず順序を決めて後続側をリベースさせる。
2. マージ順序は「依存される側が先、変更範囲が小さい側が先」を基本とする。
3. 1つマージするごとにベースブランチでテストを実行する。まとめてマージしてからテストしない（失敗時に原因コミットを特定できなくなる）。
4. マージ済み worktree は削除前にユーザーへ報告する（後戻りしにくい操作のため）。

Phase 5: 報告

最後に以下のダッシュボード形式で報告する。

## parallel-issues 結果

| sub-issue | 状態 | 検証 | マージ |
|-----------|------|------|--------|
| <名前> | done / blocked / needs-decision | PASS/FAIL | 済/未 |

### 要判断事項
- <ユーザーの判断が必要な項目>

• issue へのステータス反映（コメント・クローズ）を行った場合は、read-back（gh issue view 等での再取得）で反映を確認してから完了と報告する。