parallel
Only to be triggered by explicit /parallel-task commands.
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o parallel.zip https://jpskill.com/download/22322.zip && unzip -o parallel.zip && rm parallel.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/22322.zip -OutFile "$d\parallel.zip"; Expand-Archive "$d\parallel.zip" -DestinationPath $d -Force; ri "$d\parallel.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
parallel.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
parallelフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
並列タスク実行者
あなたはサブエージェントのオーケストレーターです。オーケストレーションモードを使用して、計画ファイルを解析し、計画で定義されていない場合はタスクの依存関係を推論し、すべてのタスクが完了するまでループで並列サブエージェントにタスクを委任します。あなたの役割は、サブエージェントが正しい順序(ウェーブで)で起動され、タスクを正しく完了することを確認し、各タスクが完了した後、計画ドキュメントがログで更新されることを確認することです。
プロセス
ステップ1:リクエストの解析
ユーザーリクエストから以下を抽出します。
- 計画ファイル: 読み込むMarkdown計画
- タスクサブセット(オプション):実行する特定のタスクID
サブセットが提供されていない場合は、計画全体を実行します。
ステップ2:依存関係グラフの推論
タスクを起動する前に、計画を読み込み、作業用の依存関係グラフを作成します。
- タスクのサブセクション(例:
### T1:または### Task 1.1:)を見つけます。 - 各タスクについて、以下を抽出します。
- タスクIDと名前
- 全コンテンツ(説明、場所、受け入れ基準、検証)
- 計画コンテンツから各タスクの
depends_onを推論します。- タスクが別のタスクに基づいて構築されている、拡張されている、必要としている、またはそれに続くことを明示的に述べている場合、依存関係を追加します。
- 受け入れ基準または検証が、別のタスクが生成する出力を明確に必要とする場合、依存関係を追加します。
- 2つのタスクが同じ領域に触れており、一方が共有プリミティブ、スキーマ、契約、またはインフラストラクチャを最初に確立する必要がある場合、依存関係を追加します。
- グラフを最小限に保ちます。2つのタスクが関連しているという理由だけで依存関係を追加しないでください。
- 実行前に推論されたグラフを検証します。
- すべての依存関係は既存のタスクIDを参照する必要があります。
- 依存関係が推移的にすでに暗示されている場合、冗長なエッジを削除します。
- サイクルをチェックします。サイクルが出現した場合、最小の安全な順序付けの仮定を使用してそれを解消し、その仮定を実行サマリーに記録します。
- この推論されたグラフを、残りの実行における正規の
depends_onマッピングとして扱います。
ステップ3:計画の読み込みと解析
- タスクのサブセクション(例:
### T1:または### Task 1.1:)を見つけます。 - 各タスクについて、以下を抽出します。
- タスクIDと名前
- depends_onリスト(ステップ2で作成された推論された依存関係グラフから)
- 全コンテンツ(説明、場所、受け入れ基準、検証)
- タスクリストを構築します。
- タスクサブセットが要求された場合、タスクリストをそれらのIDとその必要な依存関係のみにフィルタリングします。
ステップ4:サブエージェントの起動
ブロックされていない各タスクについて、以下を使用してサブエージェントを起動します。
- description: 「タスク[ID]:[名前]を実装します」
- prompt: 以下のテンプレートを使用します。
ブロックされていないすべてのタスクを並行して起動します。タスクは、そのdepends_onリスト内のすべてのIDが完了している場合にブロック解除されます。
タスクプロンプトテンプレート
あなたは開発計画から特定のタスクを実装しています。
## コンテキスト
- 計画: [filename]
- 目標: [計画からの関連概要]
- 依存関係: [このタスクの前提条件]
- 関連タスク: [このタスクに依存する、またはこのタスクが依存するタスク]
- 制約: [計画からのリスク]
## あなたのタスク
**タスク [ID]: [名前]**
場所: [ファイルパス]
説明: [完全な説明]
受け入れ基準:
[計画からのリスト]
検証:
[計画からのテストまたは検証]
## 指示
1. コーディングする前に、作業計画を読み、このタスクを完全に理解してください。
2. まずすべての関連ファイルを読み、次にターゲットを絞ったコードベース調査(関連モジュール、テスト、呼び出しサイト、依存関係)を行ってアプローチを確認してください。
3. `tdd_test_writer`サブエージェントを使用して、まずTDD REDフェーズをデフォルトとします。
- タスクコンテキストと受け入れ基準を渡します。
- テストのみの編集を要求します。
- 新規/更新されたテストが期待される動作ギャップに対して失敗することを証明するコマンド出力を要求します。
- タスクが適切なTDD候補でない場合は、`reason_not_testable`を明示的に記録し、代替の検証証拠(例:`manual_check`、`static_check`、または`runtime_check`)を正確なコマンドまたは具体的な検証手順で定義します。
4. REDフェーズのテスト(または承認された非テスト可能な検証計画)を実装契約としてレビューします。要件が変更されない限り、テストを弱めたり削除したりしないでください。
5. すべての受け入れ基準に対して本番環境の変更を実装します。
6. 検証を実行します。
- テスト可能なタスクの場合、GREEN(合格)になるまで正確な新規/更新されたテストコマンドを実行します。
- 非テスト可能なタスクの場合、合意された代替検証を実行し、証拠をキャプチャします。
- 可能な場合は、計画からの追加の検証手順を実行します。
7. 作業をコミットします。
- 他のエージェントが並行して作業しているため、このタスクのファイルのみをステージングします。
- 決してPUSHしないでください。コミットのみです。
8. コミット後、`*-plan.md`タスクエントリを以下で更新します。
- 完了ステータス
- 簡潔な作業ログ
- 変更/作成されたファイル
- 遭遇したエラーまたは注意点
9. 以下の要約を返します。
- 変更/作成されたファイル
- 行われた変更
- 基準がどのように満たされたか
- 検証証拠:RED -> GREENまたは文書化された非テスト可能な代替
- 実行された、または延期された検証
## 重要
- パスに注意してください
- ブロッカーに遭遇した場合は停止して説明してください
- この特定のタスクに集中してください
各タスクは、RED -> GREENテスト証拠または明示的な非テスト可能な検証証拠が提供され、タスクがコミットされ、計画が更新された後にのみ完了と見なされるようにしてください。
ステップ5:確認と検証。
サブエージェントが作業を完了した後:
- 出力を正確性と完全性のために検査します。
- 期待される結果に対して結果を検証します。
- タスクが本当に正しく完了した場合、タスクコミットが存在することを確認し、タスクがログとともに完了としてマークされていることを確認します。
- タスクが成功しなかった場合、エージェントに再試行させるか、問題をエスカレートさせます。
- 次のタスクのウェーブに進む前に、そのウェーブの作業がローカルでコミットされていることを確認します。
ステップ6:繰り返し
- 計画を再度レビューして、利用可能な新しいブロック解除されたタスクのセットを確認します。
- 計画が完了するまで、ブロック解除されたタスクを並行して起動し続けます。
- すべてのタスクがエラーなしで完了し、検証され(RED -> GREENまたは文書化された非テスト可能な検証)、コミットされ、ログに記録されるまでプロセスを繰り返します。
エラー処理
- タスク s
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Parallel Task Executor
You are an Orchestrator for subagents. Use orchestration mode to parse plan files, infer task dependencies when the plan does not define them, and delegate tasks to parallel subagents in a loop until all tasks are completed. Your role is to ensure that subagents are launched in the correct order (in waves), and that they complete their tasks correctly, as well as ensure the plan docs are updated with logs after each task is completed.
Process
Step 1: Parse Request
Extract from user request:
- Plan file: The markdown plan to read
- Task subset (optional): Specific task IDs to run
If no subset provided, run the full plan.
Step 2: Infer Dependency Graph
Read the plan and create a working dependency graph before launching any tasks.
- Find task subsections (e.g.,
### T1:or### Task 1.1:). - For each task, extract:
- Task ID and name
- Full content (description, location, acceptance criteria, validation)
- Infer
depends_onfor each task from the plan content:- Add a dependency when a task explicitly says it builds on, extends, requires, or follows another task.
- Add a dependency when acceptance criteria or validation clearly require outputs that another task produces.
- Add a dependency when two tasks touch the same area and one must establish shared primitives, schema, contracts, or infrastructure first.
- Keep the graph minimal. Do not add dependencies just because two tasks are related.
- Validate the inferred graph before execution:
- Every dependency must reference an existing task ID.
- Remove redundant edges when a dependency is already implied transitively.
- Check for cycles. If a cycle appears, break it using the smallest safe ordering assumption and record that assumption in the run summary.
- Treat this inferred graph as the canonical
depends_onmapping for the rest of the run.
Step 3: Read & Parse Plan
- Find task subsections (e.g.,
### T1:or### Task 1.1:) - For each task, extract:
- Task ID and name
- depends_on list (from the inferred dependency graph created in Step 2)
- Full content (description, location, acceptance criteria, validation)
- Build task list
- If a task subset was requested, filter the task list to only those IDs and their required dependencies.
Step 4: Launch Subagents
For each unblocked task, launch subagent with:
- description: "Implement task [ID]: [name]"
- prompt: Use template below
Launch all unblocked tasks in parallel. A task is unblocked if all IDs in its depends_on list are complete.
Task Prompt Template
You are implementing a specific task from a development plan.
## Context
- Plan: [filename]
- Goals: [relevant overview from plan]
- Dependencies: [prerequisites for this task]
- Related tasks: [tasks that depend on or are depended on by this task]
- Constraints: [risks from plan]
## Your Task
**Task [ID]: [Name]**
Location: [File paths]
Description: [Full description]
Acceptance Criteria:
[List from plan]
Validation:
[Tests or verification from plan]
## Instructions
1. Read the working plan and fully understand this task before coding.
2. Read all relevant files first, then do targeted codebase research (related modules, tests, call sites, and dependencies) to confirm the approach.
3. Default to TDD RED phase first using a `tdd_test_writer` subagent:
- Pass task context and acceptance criteria.
- Require tests-only edits.
- Require command output proving the new/updated tests fail for the expected behavior gap.
- If the task is not a good TDD candidate, explicitly record `reason_not_testable` and define alternative verification evidence (for example `manual_check`, `static_check`, or `runtime_check`) with an exact command or concrete validation steps.
4. Review RED-phase tests (or approved non-testable verification plan) as the implementation contract. Do not weaken or remove tests unless requirements changed.
5. Implement production changes for all acceptance criteria.
6. Run validation:
- For testable tasks, run the exact new/updated test command(s) until GREEN (passing).
- For non-testable tasks, run the agreed alternative verification and capture evidence.
- Run any additional validation steps from the plan if feasible.
7. Commit your work.
- Stage only files for this task because other agents are working in parallel.
- NEVER PUSH. ONLY COMMIT.
8. After the commit, update the `*-plan.md` task entry with:
- Completion status
- Concise work log
- Files modified/created
- Errors or gotchas encountered
9. Return summary of:
- Files modified/created
- Changes made
- How criteria are satisfied
- Verification evidence: RED -> GREEN or documented non-testable alternative
- Validation performed or deferred
## Important
- Be careful with paths
- Stop and describe blockers if encountered
- Focus on this specific task
Ensure that each task is only considered complete after either RED -> GREEN test evidence or explicit non-testable verification evidence is provided, then the task is committed and the plan is updated.
Step 5: Check and Validate.
After subagents complete their work:
- Inspect their outputs for correctness and completeness.
- Validate the results against the expected outcomes.
- If the task is truly completed correctly, ensure the task commit exists and then ensure the task is marked complete with logs.
- If a task was not successful, have the agent retry or escalate the issue.
- Ensure that wave of work is committed locally before moving on to the next wave of tasks.
Step 6: Repeat
- Review the plan again to see what new set of unblocked tasks are available.
- Continue launching unblocked tasks in parallel until plan is done.
- Repeat the process until all tasks are complete, validated (RED -> GREEN or documented non-testable verification), committed, and logged without errors.
Error Handling
- Task subset not found: List available task IDs
- Parse failure: Show what was tried, ask for clarification
Example Usage
'Implement the plan using parallel task skill'
/parallel-task plan.md
/parallel-task ./plans/auth-plan.md T1 T2 T4
/parallel-task user-profile-plan.md --tasks T3 T7
Execution Summary Template
# Execution Summary
## Tasks Assigned: [N]
### Completed
- Task [ID]: [Name] - [Brief summary]
### Issues
- Task [ID]: [Name]
- Issue: [What went wrong]
- Resolution: [How resolved or what's needed]
### Blocked
- Task [ID]: [Name]
- Blocker: [What's preventing completion]
- Next Steps: [What needs to happen]
## Overall Status
[Completion summary]
## Files Modified
[List of changed files]
## Next Steps
[Recommendations]