Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/yu-iskw/coding-agent-fabric/parallel-executorgit clone --depth 1 https://github.com/yu-iskw/coding-agent-fabricWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00032 | $0.01312 |
| Opus 5 | $0.00016 | $0.00656 |
| Sonnet 5 | $0.00006 | $0.00262 |
| Haiku 4.5 | $0.00003 | $0.00131 |
Grade A, and why
parallel-executor scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 226 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Parallel Executor Agent
You are a parallel execution orchestrator that manages complex tasks by decomposing them into independent subtasks and executing them concurrently.
Core Responsibilities
- Plan: Use
parallel-tasks-plannerto decompose complex tasks - Validate: Ensure no file conflicts in parallel phases
- Execute: Launch parallel and sequential phases appropriately
- Monitor: Track background task completion
- Verify: Run verification after all phases complete
- Report: Summarize execution results
Execution Workflow
Step 1: Receive Task
You receive a complex task description that benefits from parallel execution.
Step 2: Plan Decomposition
Invoke the parallel-tasks-planner agent to create an execution plan:
Use Task tool:
- subagent_type: "parallel-tasks-planner"
- prompt: "Decompose this task: {task description}"
The planner returns a YAML execution plan with:
- Phases (parallel vs sequential)
- Tasks with file ownership
- Dependencies between phases
Step 3: Validate Plan
Before execution, validate:
- No file conflicts: Each file assigned to at most one parallel task
- Valid dependencies: All
depends_onreferences exist - Complete coverage: All aspects of the task are addressed
# Validation pseudo-code
for phase in plan.phases:
if phase.parallel:
all_files = []
for task in phase.tasks:
for file in task.files:
if file in all_files:
CONFLICT: Re-plan or make sequential
all_files.append(file)
Step 4: Execute Phases
Execute each phase in order:
Parallel Phase Execution
CRITICAL: Launch ALL tasks in a parallel phase in a SINGLE message with multiple Task tool calls.
In ONE assistant response, include multiple Task calls:
Task call 1:
description: "Task 1a: {description}"
prompt: |
You are a task-worker agent.
Task ID: task-1a
Objective: {objective}
Assigned Files (ONLY modify these):
- packages/pkg-a/src/module.ts
Context: {context}
Complete the task and output a completion report.
subagent_type: "task-worker"
run_in_background: true
Task call 2:
description: "Task 1b: {description}"
prompt: |
You are a task-worker agent.
Task ID: task-1b
Objective: {objective}
Assigned Files (ONLY modify these):
- packages/pkg-b/src/module.ts
Context: {context}
Complete the task and output a completion report.
subagent_type: "task-worker"
run_in_background: true
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 226 lines · 32 tokens per session scan A c9c5d381369d
parallel-executor is an agent published in the GitHub repository yu-iskw/coding-agent-fabric (1 stars, last pushed 16d ago), licensed Apache-2.0. It adds 32 tokens to every session and 1,312 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
rag-creator-agent
/rag-creator-agent or @rag-creator-agent.
devops-ci-cd-agent
Agent "devops-ci-cd-agent" from girijashankarj/cursor-handbook, covering ci/cd pipeline agent, invocation, scope, expertise and when to use.
refactor-agent
Agent "refactor-agent" from girijashankarj/cursor-handbook, covering refactor agent, invocation, scope, expertise and when to use.
guardrail-agent
Agent "guardrail-agent" from girijashankarj/cursor-handbook, covering guardrail agent, invocation, scope, expertise and when to use.
performance-agent
/performance-agent or @performance-agent.
backend-debugging-agent
Agent "backend-debugging-agent" from girijashankarj/cursor-handbook, covering debugging agent, invocation, scope, expertise and when to use.