dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
37
21%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/dispatching-parallel-agents/SKILL.mdQuality
Discovery
7%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description only provides a vague trigger condition without ever stating what the skill does. It lacks concrete actions, natural user-facing keywords, and a clear 'what' component. A user or Claude selecting from many skills would struggle to understand the skill's purpose or when to prefer it over alternatives.
Suggestions
Add a clear 'what' statement describing the concrete action, e.g., 'Executes multiple tasks in parallel using concurrent subagents' or 'Runs independent subtasks simultaneously to speed up workflows'.
Include natural trigger terms users would actually say, such as 'parallel', 'at the same time', 'concurrently', 'multiple tasks', 'batch', 'speed up'.
Provide explicit examples of when to use it, e.g., 'Use when the user asks to do multiple things at once, run tasks in parallel, or when subtasks have no dependencies on each other'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description does not list any concrete actions or capabilities. It describes a condition for use but never says what the skill actually does — no verbs like 'runs', 'executes', 'parallelizes', etc. | 1 / 3 |
Completeness | The 'when' is partially addressed ('Use when facing 2+ independent tasks...'), but the 'what' — what the skill actually does — is entirely missing. Without knowing what it does, the description is fundamentally incomplete. | 1 / 3 |
Trigger Term Quality | There are no natural keywords a user would say. Terms like 'independent tasks', 'shared state', and 'sequential dependencies' are abstract/technical jargon, not phrases users naturally use in requests. | 1 / 3 |
Distinctiveness Conflict Risk | The concept of parallel/independent task execution is somewhat distinctive, but without naming the mechanism (e.g., parallel tool calls, subagents, concurrent execution), it could overlap with any multi-step or task-management skill. | 2 / 3 |
Total | 5 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill covers a useful pattern with a good concrete example and clear agent prompt template, but suffers from significant redundancy — the 'When NOT to Use' section duplicates 'Don't use when', and 'Real-World Impact' duplicates the earlier real example. Multiple sections explain concepts Claude already understands (parallelism, independence, focus). The actionability is moderate since the dispatch mechanism uses pseudocode rather than actual tool calls.
Suggestions
Cut redundant sections: merge 'When NOT to Use' into the 'When to Use' section, remove 'Real-World Impact' (duplicates the real example), and remove 'Key Benefits' (restates obvious advantages Claude already understands).
Replace the pseudocode `Task()` calls with the actual tool invocation syntax Claude should use for parallel agent dispatch, making the pattern copy-paste ready.
Add an explicit feedback loop in the verification section: what to do when agents' fixes conflict or when the integrated suite still fails (e.g., re-dispatch with additional constraints).
Remove the DOT graph notation — it consumes tokens and the bullet lists already convey the decision criteria more efficiently.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Significant verbosity throughout. The 'Key Benefits' section restates what's already obvious. 'Real-World Impact' duplicates the 'Real Example from Session' section. The decision flowchart in DOT notation adds tokens without clear value. Multiple sections repeat the same advice (When NOT to Use vs Don't use when). Claude already understands parallelism, independence, and task delegation. | 1 / 3 |
Actionability | The agent prompt structure example is concrete and useful, and the TypeScript dispatch snippet shows the pattern. However, the Task() calls are pseudocode rather than actual tool invocations, and there's no specification of which tool to use or exact API. The guidance is more illustrative than copy-paste executable. | 2 / 3 |
Workflow Clarity | The 4-step pattern (Identify → Create → Dispatch → Review) is clearly sequenced, and the verification section exists. However, the verification steps lack specificity — 'Check for conflicts' doesn't say how, and there's no explicit feedback loop for what to do when agents' fixes DO conflict or when the full suite still fails after integration. | 2 / 3 |
Progressive Disclosure | Content is organized with clear headers and sections, but it's entirely monolithic — everything is in one file with no references to external resources. The real example, common mistakes, and detailed prompt structure could be split out. For a skill this long (~150 lines of content), some progressive disclosure to separate files would be appropriate. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- obra/superpowers
- Commit
b7a8f76
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.