一键导入
parallel-execution
Parallel execution pattern: Multiple agents work simultaneously on independent sub-tasks. Best for embarrassingly parallel workloads.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Parallel execution pattern: Multiple agents work simultaneously on independent sub-tasks. Best for embarrassingly parallel workloads.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Formal reasoning via FOL theorem proving, model finding, and categorical logic
Use modern, token-efficient command-line tools (fd, ripgrep, ast-grep, bat, sd, jq, yq, tokei, eza, dust, procs, delta, hyperfine, just) instead of legacy coreutils (find, grep, cat, sed, ls, du, ps) for any shell, file, or codebase task — on any platform (Linux/macOS/Windows) and through any executor (a terminal, Claude Code's bash tool, Desktop Commander, or an MCP shell bridge). Trigger whenever you are about to search files, grep for text, read or inspect files, find-and-replace, refactor code, traverse a repository, process JSON/YAML, or inspect disk usage or processes — even if the user did not name a specific tool. These tools are faster, .gitignore-aware, and emit clean structured output that protects the context window. For installation across operating systems and platform-specific quirks, see references/. If you run commands specifically through the LocalREPL MCP bridge, also consult the local-repl-cli skill for environment-specific gotchas.
Operating guide for the AGEM reasoning engine: native tools, honest metric interpretation, formal-logic verification via mcp-logic, and the meta-tool MCP interface.
Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks.
Master orchestrator for the five-question decision tree that selects the right agentic pattern from Sequential, ReAct, Planning, Reflection, or Multi-Agent.
Multi-agent pattern for tasks requiring specialization or scale beyond single-agent capacity. Covers topology, routing, and coordination design.
| name | parallel-execution |
| description | Parallel execution pattern: Multiple agents work simultaneously on independent sub-tasks. Best for embarrassingly parallel workloads. |
[!IMPORTANT] When to use: When sub-tasks are independent and can be executed simultaneously. Maximizes throughput for parallelizable workloads.
Does the task require multiple specialized capabilities?
├── YES
│ └── Are subtasks independent (no shared state/collaboration)?
│ ├── YES → Parallel Execution (you're here)
│ └── NO, need shared context?
│ └── YES → supervisor-orchestrator
└── NO → single-agent
| ✅ Use Parallel When | ❌ Avoid When |
|---|---|
| Subtasks are truly independent | Subtasks share state/artifacts |
| You need maximum throughput | Order dependency exists |
| Each subtask is self-contained | Errors in one affect others |
| Subtasks are embarrassingly parallel | Result synthesis is complex |
┌─────────────────────────────────────────────────────┐
│ Dispatcher │
│ (Splits task, aggregates results) │
└────────────────────┬───────────────────────────────┘
│
┌────────────────┼────────────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ Agent 1│ │ Agent 2│ │ Agent 3│ ← All simultaneous
│(Doc A) │ │(Doc B) │ │(Doc C) │
└────────┘ └────────┘ └────────┘
│ │ │
└────────────────┼────────────────┘
▼
┌─────────────┐
│ Aggregator │
│ (Synthesize) │
└─────────────┘
│
▼
Final Output
You are a dispatcher for parallel execution.
Task: {user_task}
1. Identify N independent subtasks
2. Launch all subtasks simultaneously
3. Wait for all completions
4. Aggregate results
Subtasks identified: {list}
| Question | If NO, Use Another Pattern |
|---|---|
| Do subtasks need shared state? | ❌ → supervisor-orchestrator |
| Do subtasks depend on each other's output? | ❌ → supervisor-orchestrator |
| Is there an execution order requirement? | ❌ → supervisor-orchestrator |
| Do subtasks need to collaborate? | ❌ → supervisor-orchestrator |
| Mistake | Why It's Bad |
|---|---|
| Faking independence | Race conditions, corrupted outputs |
| No aggregation plan | Results pile up without synthesis |
| Uneven workload | Some agents idle, others overwhelmed |
| Ignoring partial failures | Incomplete results, wasted compute |
| Strategy | Use When |
|---|---|
| Simple concatenation | Results are independent, list format OK |
| Weighted scoring | Some results more important than others |
| Consensus voting | Multiple perspectives on same question |
| Hierarchical synthesis | Results themselves need synthesis |
Need some coordination between parallel tasks?
├── YES, light handoffs?
│ └── YES → supervisor-orchestrator (light version)
└── YES, hierarchical control?
└── YES → hierarchical-supervisor
Is parallelism actually overkill?
├── YES, one LLM can handle it?
│ └── YES → single-agent
└── YES, simple routing by type?
└── YES → supervisor-delegation
| Factor | Parallel Execution |
|---|---|
| Latency | Low (limited by slowest subtask) |
| Cost | Higher (N agents running) |
| Complexity | Low-Moderate |
| Reliability | Partial failure possible; others continue |
| Best for | Independent batch workloads |
Pattern ID: parallel-execution | AGEM-compatible