ワンクリックで
sh-parallel
Break tasks into independent subagents for parallel execution when no shared state or sequential dependencies exist
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Break tasks into independent subagents for parallel execution when no shared state or sequential dependencies exist
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Multi-expert AI/ML specification review with scoring gate — model architecture, evaluation rigor, safety/alignment, and production readiness for AI systems and LLM apps
Multi-expert architecture review — boundaries, integration patterns, failure modes, evolvability
Multi-expert business analysis with advisory recommendations (no scoring gate)
Multi-expert intelligence pipeline review — discovery quality, ingestion resilience, scoring validity, platform compliance, taxonomy coherence, cost efficiency
Multi-expert mobile/native app specification review with scoring gate — Android, iOS, Swift, SwiftUI
Multi-expert personal-development review with scoring gate — learnability, adoption, human-centeredness, and capability impact for talent/learning/AI-augmentation designs
| name | sh-parallel |
| description | Break tasks into independent subagents for parallel execution when no shared state or sequential dependencies exist |
You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history -- you construct exactly what they need. This also preserves your own context for coordination work.
When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
Core principle: Dispatch one agent per independent problem domain. Let them work concurrently.
Use when:
Don't use when:
Group failures by what's broken:
Each domain is independent -- fixing tool approval doesn't affect abort tests.
Each agent gets:
Task("Fix agent-tool-abort.test.ts failures")
Task("Fix batch-completion-behavior.test.ts failures")
Task("Fix tool-approval-race-conditions.test.ts failures")
// All three run concurrently
When agents return:
Good agent prompts are:
Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
1. "should abort tool with partial output capture" - expects 'interrupted at' in message
2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
3. "should properly track pendingToolCount" - expects 3 results but gets 0
These are timing/race condition issues. Your task:
1. Read the test file and understand what each test verifies
2. Identify root cause - timing issues or actual bugs?
3. Fix by:
- Replacing arbitrary timeouts with event-based waiting
- Fixing bugs in abort implementation if found
- Adjusting test expectations if testing changed behavior
Do NOT just increase timeouts - find the real issue.
Return: Summary of what you found and what you fixed.
Too broad: "Fix all the tests" - agent gets lost No context: "Fix the race condition" - agent doesn't know where No constraints: Agent might refactor everything Vague output: "Fix it" - you don't know what changed
Instead:
Related failures: Fixing one might fix others -- investigate together first Need full context: Understanding requires seeing entire system Exploratory debugging: You don't know what's broken yet Shared state: Agents would interfere (editing same files, using same resources)
After agents return:
/sh:verify)Works with:
/sh:plan - Plans can identify parallelizable task groups/sh:execute - Individual agents follow execution skill/sh:tdd - Each agent follows TDD within their scope/sh:verify - Verification after integrationsuperpowers:finishing-a-development-branch - Complete the branch after all agents finish/sh:worktree - Worktrees can isolate parallel agent work