一键导入
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 职业分类
| 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-completionUse 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