원클릭으로
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use before any DevOps build, change, or new feature — refine requirements through dialogue before touching infrastructure or code
Use when working with Docker — building images, writing Dockerfiles, debugging container issues
Use to execute a written implementation plan via subagents with review checkpoints
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when working with Kubernetes or Helm — authoring, reviewing, hardening, or debugging manifests, Deployments, Services, Ingress, RBAC, NetworkPolicy, or cluster operations
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
| name | dispatching-parallel-agents |
| description | Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies |
Delegate independent tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed. They should never inherit your session's context — you construct exactly what they need. This also preserves your own context for coordination work.
When you have multiple unrelated failures (different infra components, different services, 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 the network config doesn't affect the image build.
Each agent gets:
Use the Task tool with all independent agents at once:
Task("Investigate health check failures for service A")
Task("Fix image build failure for service B")
Task("Correct alert threshold for service C")
// All three run concurrently
When agents return:
Good agent prompts are:
Investigate the health check failures for service A in the staging environment.
Symptoms:
- /healthz returns 502 since last deploy (2025-05-18 14:30 UTC)
- Upstream logs show "connection refused" on port 8080
Your task:
1. Check the service's container logs and recent config changes
2. Identify root cause — is it the port binding, a crash loop, or network policy?
3. Fix the issue or provide a clear diagnosis with reproduction steps
Do NOT modify other services or shared infrastructure.
Return: Root cause, what you changed (if anything), and how to verify the fix.
Too broad: "Fix all the failing services" — agent gets lost. Specific: "Fix service A health checks" — focused scope.
No context: "Fix the 502" — agent doesn't know where. With context: Paste the error messages and recent change timeline.
No constraints: Agent might refactor shared config. With constraints: "Do NOT change shared network policies."
Vague output: "Fix it" — you don't know what changed. Specific: "Return summary of root cause and changes made."
Related failures: Fixing one might fix others — investigate together first.
Need full context: Understanding requires seeing entire system state.
Exploratory: You don't know what's broken yet — use systematic-debugging first.
Shared state: Agents would interfere (editing same Terraform state, same config map).
After agents return:
verification-before-completion