一键在 Manus 中运行任何 Skill

parallel-issues

星标3

分支0

更新时间2026年7月6日 04:21

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

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

zeero

zeero/dotfiles

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

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）

issue を読み、関連コードを実際に調べたうえで sub-issue 案を作る。コードを読まずに issue 本文だけから分解しない（分解の妥当性はコードの実態が決める）。
各 sub-issue に対し「触るはずのファイル・モジュール範囲」を明記する。範囲が重なる sub-issue は並行させず、統合するか依存関係として直列化する。
分解案（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: 合流（コンフリクト検知とマージ順序）

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

Phase 5: 報告

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

## parallel-issues 結果

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

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

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

同仓库更多 Skills

同仓库

user invoke only

user invoke only

agent-skill-reference

zeero/dotfiles

Official Claude Code reference for agent skills. Use this when configuring frontmatter or other settings for agent skills.

user invoke only

Use this to consult the official Pi coding agent reference when investigating, designing, or implementing Pi — setup, configuration, providers/models, skills, extensions, packages, prompt templates, sessions, SDK, RPC, JSON event stream, and terminal setup.

2026-07-153

visualize

zeero/dotfiles

trigger is `visualize`

2026-07-143

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

parallel-issues

なぜこの手順か

Phase 0: 前提確認

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

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

Phase 1: 分解（codebase-verified）

issue を読み、関連コードを実際に調べたうえで sub-issue 案を作る。コードを読まずに issue 本文だけから分解しない（分解の妥当性はコードの実態が決める）。
各 sub-issue に対し「触るはずのファイル・モジュール範囲」を明記する。範囲が重なる sub-issue は並行させず、統合するか依存関係として直列化する。
分解案（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: 合流（コンフリクト検知とマージ順序）

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

Phase 5: 報告

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

## parallel-issues 結果

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

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

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