بنقرة واحدة
arc-dispatching-parallel
Use when dispatching multiple independent features within a worktree session
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Use when dispatching multiple independent features within a worktree session
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when running autonomous unattended loops — cross-session execution of DAG tasks without human intervention
Use when converting design documents to structured specs, when spec quality is below threshold, or when requirements need formal acceptance criteria
Use when you need to verify work is complete before making completion claims
Use when maintaining ArcForge itself by creating, editing, or verifying ArcForge skills before deployment
Use when optional learning is enabled and observations should become reviewable candidates, inactive drafts, and explicitly activated artifacts.
Use when user asks about behavioral patterns, requests instinct status, or wants to confirm/contradict a detected pattern
| name | arc-dispatching-parallel |
| description | Use when dispatching multiple independent features within a worktree session |
Dispatch multiple agents for independent tasks in parallel.
digraph when_to_use {
"Multiple tasks or failures?" [shape=diamond];
"Independent?" [shape=diamond];
"DAG context available?" [shape=diamond];
"Use DAG readiness path" [shape=box];
"Use independent failures path" [shape=box];
"Use sequential/other skill" [shape=box];
"Multiple tasks or failures?" -> "Independent?" [label="yes"];
"Multiple tasks or failures?" -> "Use sequential/other skill" [label="no"];
"Independent?" -> "DAG context available?" [label="yes"];
"Independent?" -> "Use sequential/other skill" [label="no"];
"DAG context available?" -> "Use DAG readiness path" [label="yes"];
"DAG context available?" -> "Use independent failures path" [label="no"];
}
Use when:
Don't use when:
Group by independence:
Independence checks (examples):
Each agent gets:
Prompt template:
Fix <problem-domain> in <file-or-subsystem>.
Context:
- Failure 1: <name> (<error/message>)
- Failure 2: <name> (<error/message>)
Constraints:
- Don't change unrelated files
- Avoid refactors outside this scope
Return:
- Root cause
- Fix summary
- Files changed
Dispatch one general-purpose subagent per task — all in a single batch so they run concurrently — using whatever subagent mechanism your platform provides:
subagent: "Fix issue A in file X"
subagent: "Fix issue B in file Y"
subagent: "Fix issue C in file Z"
verifier agent with the project test command — runs the suite from an
empty context and returns raw output.spec-reviewer agent with the relevant
specs/<spec-id>/.../*.md attached — it confirms every acceptance criterion
in the integrated branch.When dag.yaml exists (from /arc-planning), use this structured workflow.
If you don't have a DAG, skip to Without DAG: Independent Failures below.
Identify the spec you are working within (from the worktree's .arcforge-epic marker or the --spec-id argument passed by the lead), then:
cat specs/<spec-id>/dag.yaml
Parse the structure to understand:
A feature is ready when it is pending and every feature it depends_on is
completed. Don't hand-parse the dag for this — the engine computes it:
node "${ARCFORGE_ROOT}/scripts/cli.js" parallel --features --json
Output is the set of parallelizable features in the in-progress epic(s):
{ "count": 2, "features": [{ "id": "feat-001", "name": "...", "epic": "epic-001" }] }
count: 0 means nothing is ready right now — complete a blocking feature
first, or fall back to arcforge next for the single next task.
Features are independent when:
Example:
Features A, B, C have no dependencies → Group 1 (parallel)
Feature D depends on A → Must wait for Group 1
Feature E depends on B and C → Must wait for Group 1
─────────────────────────────────────────────────
✅ Parallelization analysis complete
**Can run in parallel NOW:**
- Feature A: <description>
- Feature B: <description>
- Feature C: <description>
**Must wait (blocked):**
- Feature D: <description> (depends on: A)
- Feature E: <description> (depends on: B, C)
**Execution approach:**
Option 1: Sequential (safer)
Implement A → B → C → D → E
Option 2: Parallel Group 1 (faster)
Dispatch A, B, C in parallel
Then implement D, E after Group 1 complete
Which approach? (1-2)
─────────────────────────────────────────────────
Use arc-implementing to implement features one at a time in dependency order.
For each feature in the parallel group, dispatch a separate subagent — all in one message so they run concurrently:
subagent: "Implement feature <feature-id> from specs/<spec-id>/epics/<epic>/features/<feature>.md"
subagent: "Implement feature <feature-id> from specs/<spec-id>/epics/<epic>/features/<feature>.md"
Wait for all to complete, then run the Step 4 verification gate (the verifier
agent, plus the spec-reviewer agent when a spec exists) before proceeding to
the next group.
Fetch the next work from the engine (the arc-coordinating skill owns the full
lifecycle; these are the underlying CLI calls):
# Get the next parallelizable features
node "${ARCFORGE_ROOT}/scripts/cli.js" parallel --features --json
# Or get the next single task
node "${ARCFORGE_ROOT}/scripts/cli.js" next --json
When you have multiple independent failures but no dag.yaml:
Review found 3 independent issues:
1. Missing validation in auth.py
2. Wrong error message in api.py
3. Missing test for utils.py
[Dispatch 3 agents in parallel]
Agent 1: Fixed auth.py validation
Agent 2: Fixed api.py error message
Agent 3: Added utils.py test
[Verify no conflicts]
[Run full test suite]
All fixes integrated successfully.
| Excuse | Reality |
|---|---|
| "Sequential prevents conflicts" | Parallel is safe when no deps |
| "Parallelization too complex" | DAG makes it clear |
| "User knows the dependencies" | Present structured analysis |
| "Worktrees handle parallelization" | That's epic-level, not feature-level |
─────────────────────────────────────────────────
✅ Parallel execution planned
Group 1: [Features A, B, C] (in parallel)
Group 2: [Features D, E] (after Group 1)
Approach: [Sequential/Parallel]
Next feature: [Feature ID]
Next: Begin implementation with `/arc-implementing`
─────────────────────────────────────────────────
─────────────────────────────────────────────────
⚠️ Parallelization analysis blocked
Issue: [dag.yaml not found / No features ready / Parse error]
Location: [file or epic]
To resolve:
1. Create dag.yaml with `/arc-planning`
2. Complete dependency features first
3. Fix dag.yaml syntax
Then retry: `/arc-dispatching-parallel`
─────────────────────────────────────────────────
The subagent: lines above are notation, not a specific tool — this skill works
on any platform that can run a fresh subagent (Claude Code, Codex, Gemini CLI,
OpenCode). Dispatch each parallel task with whatever subagent mechanism your
harness provides; the only requirement is that independent tasks run in their
own fresh contexts and report back. The verifier and spec-reviewer agents in
the verification gate are pre-built where your platform supplies them; otherwise
dispatch a general-purpose subagent with the equivalent verify command and
spec-check instructions.
/arc-planning creates dag.yaml/arc-implementing executes features/arc-coordinating owns the DAG lifecycle (wraps parallel, next)| Type | Scope | Skill |
|---|---|---|
| Epic-level | Multiple epics at once | arc-dispatching-teammates (multi-epic via DAG) / arc-coordinating (lifecycle) |
| Feature-level | Multiple features within epic | This skill (arc-dispatching-parallel) |
Example:
arc-dispatching-teammates / arc-coordinating