OpenSpec Parallel Agents

Overview

1. New OPSX commands (

   /opsx:*

   )
2. Legacy commands (

   /openspec:*

   )
3. Codex CLI prompt commands (

   /prompts:*

   )

Command Compatibility Matrix (Mandatory Recognition)

/opsx:explore

/opsx:new

/opsx:continue

/opsx:ff

/opsx:apply

/opsx:verify

/opsx:sync

/opsx:archive

/opsx:bulk-archive

/opsx:onboard

/openspec:proposal

/openspec:apply

/openspec:archive

/prompts:opsx-explore

/prompts:opsx-new

/prompts:opsx-continue

/prompts:opsx-ff

/prompts:opsx-apply

/prompts:opsx-verify

/prompts:opsx-sync

/prompts:opsx-archive

/prompts:opsx-bulk-archive

/prompts:opsx-onboard

~/.codex/prompts/opsx-<id>.md

/prompts:openspec-proposal

/prompts:openspec-apply

/prompts:openspec-archive

Legacy Command to New Workflow Mapping

1. /openspec:proposal

   or

   /prompts:openspec-proposal

• Equivalent to the semantics of "create planning artifacts".
• Recommended mapping:

  /opsx:new

  +

  /opsx:ff

  (or

  /opsx:continue

  for step-by-step creation as needed).

1. /openspec:apply

   or

   /prompts:openspec-apply

• Directly mapped to

  /opsx:apply

  .

1. /openspec:archive

   or

   /prompts:openspec-archive

• Directly mapped to

  /opsx:archive

  .

Codex CLI Special Handling

1. The prompt file directory prioritizes

   $CODEX_HOME/prompts

   ; if not available,

   ~/.codex/prompts

   is used.
2. If both new and old aliases for synonymous commands exist, OPSX semantics are prioritized for execution, and "triggered via compatible entry point" is noted in the summary.
3. For

   /prompts:*

   entry points, parameters may be passed as a whole string; when the change cannot be uniquely identified, a change selection must be performed first, and guessing is not allowed.

Trigger Conditions

1. Processing 2 or more changes simultaneously, with some tasks that can be executed independently.
2. Need for bulk archiving or pre-archiving checks (especially

   /opsx:bulk-archive

   ).
3. Tasks contain both parallelizable nodes and strong dependency chains.
4. The user uses any of the new or old commands listed in the table above, and explicitly requests parallel subagent execution.

Concurrent Execution Rules

1. Default split into 3-6 subtasks per round; if fewer than 3, the reason for switching to serial execution must be explained.
2. Only nodes without pre-dependencies are executed concurrently; strong dependency chains must be executed serially.
3. Concurrent writes to overlapping areas of the same file are prohibited; if a conflict risk is detected, immediately downgrade to serial execution.
4. When archiving and specification merging involve shared indexes, the final submission must be done serially.
5. All results from a round of concurrent execution must be returned in full before unified aggregation; it is not allowed to proceed across rounds while returning results incrementally.

Command-Level Strategies

New Commands (

/opsx:*

)

• /opsx:new

  : Can concurrently create independent changes.

• /opsx:ff

  : Group by changes and generate planning artifacts concurrently.

• /opsx:apply

  : Implement concurrently by module boundaries.

• /opsx:verify

  : Can verify each change concurrently, then make a unified decision.

• /opsx:archive

  : Pre-archiving checks can be done concurrently, while the final archiving submission must be serial.

• /opsx:bulk-archive

  : First perform health checks concurrently, then archive serially in conflict order.

Legacy Commands (

/openspec:*

)

• Keep the user entry point; do not force users to change commands.
• Convert to OPSX semantics according to "Legacy to New Mapping" during execution and apply the same concurrency rules.

Codex CLI (

/prompts:*

)

• Recognize both new and old prompt names.
• Scheduling rules are consistent with

  /opsx:*

  , only the entry aliases are different.

Standard Cycle

1. Identify the entry type (OPSX / Legacy / Codex Prompt).
2. Standardize to OPSX semantics (perform legacy command mapping if necessary).
3. Analyze dependencies and split into 3-6 conflict-free task cards.
4. Execute parallelizable nodes concurrently.
5. Aggregate conflicts, blocks, and risks, then decide whether to proceed with parallel execution or switch to serial execution in the next round.

Round Summary Template

## Round {N} Summary

### Trigger Entry
- Original Command: {e.g., /openspec:proposal or /prompts:opsx-apply}
- Normalized Semantics: {corresponding /opsx:*}

### Round Goal
- {One-sentence goal}

### Subtask Status (3-6)
1. {Task A} | {Completed/Blocked/Failed} | Output: {File or Result}
2. {Task B} | {Completed/Blocked/Failed} | Output: {File or Result}
3. {Task C} | {Completed/Blocked/Failed} | Output: {File or Result}

### Conflicts and Handling
- Write Conflict Check: {None/Exists, Location}
- Handling Action: {Rearrange Concurrency/Switch to Serial/Split Boundaries}

### Dependency Chain Status
- Serial Chain: {A -> B -> C}
- Current Progress: {Node}

### Next Round Plan
- Parallel Tasks: {List}
- Serial Tasks: {List}
- Archiving Preparation Status: {Ready for Archiving/Not Ready + Reason}