Apply multiple plans sequentially

[MiloszKrajewski]

I'm new to OpenSpec, just exploring, but I have a question:

As sometimes planning requires most supervision while coding is relatively straight forward I would like to plan multiple changes and run implementation overnight / unsupervised.

Is there an option like this /opsx:apply-many?
Is there an option to merge multiple changes into one "virtual" change so I could simulate this?

[21st-connector]

Task completed.

The enrichment comment has been posted on issue #758. Here's a summary of what was covered:

Key findings:

• No /opsx:apply-many command exists — this is a genuinely new feature request with no duplicates
• /opsx:apply handles one change at a time; /opsx:bulk-archive is the closest batch operation but only handles post-implementation archiving
• Three related issues were identified (Proposal: The apply proposal should instruct the agent to delegate tasks to subagents #572 subagent delegation, Advanced Spec & Plan Generation #434 advanced plan generation, Backlog/issues feature? #429 backlog queuing)

The comment includes:

• Links to all relevant source files (apply workflow, bulk archive, skill templates, instructions generator, profiles)
• Three workaround ideas the author can use today (manual sequential prompting, merging changes, shell scripting)
• A sketch of how /opsx:apply-many could be implemented (new workflow template, change selection/ordering, error handling considerations)
• The key design question: what happens when apply pauses on a blocker mid-queue

Comment URL: #758 (comment)

---

View full conversation

Powered by 1Code

[21st-connector]

Issue Analysis

Thanks for the feature request! There is currently no /opsx:apply-many command and no built-in way to queue multiple changes for sequential, unsupervised implementation. This is a new feature request — no duplicate exists.

What exists today

/opsx:apply implements tasks from a single change at a time (src/core/templates/workflows/apply-change.ts). It reads tasks.md, works through pending checkboxes, and pauses on blockers or unclear requirements.

/opsx:bulk-archive is the closest batch operation (src/core/templates/workflows/bulk-archive-change.ts). It archives multiple completed changes at once with conflict detection, but it does not implement them — it only handles the post-implementation archive+sync step.

Relevant codebase references

Component	File
Apply workflow template	src/core/templates/workflows/apply-change.ts
Bulk archive workflow	src/core/templates/workflows/bulk-archive-change.ts
Skill template exports	src/core/templates/skill-templates.ts
Workflow documentation	docs/workflows.md (see "Parallel Changes" section)
Command reference	docs/commands.md
Apply instructions generator	src/commands/workflow/instructions.ts
Workflow profiles (core vs expanded)	src/core/profiles.ts

Workaround ideas (today)

Since the apply workflow is AI-agent-driven (not a programmatic CLI pipeline), there's no native queue. However:

1. Manual sequential prompting — After one /opsx:apply change-a completes, immediately run /opsx:apply change-b. The agent tracks progress via tasks.md checkboxes, so each apply is resumable.

2. Merge into one change — You could manually combine the tasks.md files from multiple planned changes into a single change's tasks.md and run /opsx:apply once. This loses per-change spec separation but achieves "one long unsupervised run." You'd need to also merge the context files (proposal, specs, design).

3. Shell scripting outside OpenSpec — Some AI coding tools (e.g., Claude Code with --print mode) support non-interactive invocation. You could script sequential apply calls at the shell level, though this bypasses the interactive pause-on-blocker behavior that /opsx:apply relies on.

Potential implementation approaches

If this were to be built as /opsx:apply-many:

• New workflow template in src/core/templates/workflows/ (similar pattern to bulk-archive-change.ts)
• Would need to: list changes → let user select/order → sequentially run apply for each → handle failures/blockers between changes
• The key design question is error handling: if apply pauses on change feat: add change proposal for openspec init command #2 (unclear task, blocker), should it skip to change feat: Update spec change format #3, stop entirely, or queue it for later review?
• Could reuse openspec list --json for change discovery and openspec instructions apply --change "<name>" --json for per-change status checks

Related issues

• Proposal: The apply proposal should instruct the agent to delegate tasks to subagents #572 — Proposal: apply should delegate tasks to subagents — related concept of batching/delegating within apply
• Advanced Spec & Plan Generation #434 — Advanced Spec & Plan Generation — multi-phase workflow generation
• Backlog/issues feature? #429 — Backlog/issues feature? — queuing planned work items

[TabishB]

@MiloszKrajewski Creating a skill/command for this wouldn't be great, you would most likely want to have each implementation to be run in a separate context window/session.

A few better options could be:

• Using the claude code agent teams feature (if you use claude code)
• Just create many instances of your coding agent and run apply in each (i.e a claude code instance in each terminal).
• Use something like conductor to run things in parallel in different worktrees.

There are a lot of current ways to run things in parallel.

[MiloszKrajewski]

However "ways to run things in parallel" are no solving the problem of "applying multiple plans sequentially".

I wanted sequentially as I wanted to build tasks on top of each other.

Is there a way to find out programmatically that task has been finished? Technically I would inject keyboard events. Feels dirty though.

[javigomez]

On this topic, I started with a document outlining the full product and asked an agent to run /openspec propose 20 changes based on the product document that are atomic enough. The results were quite good—it generated 20 change proposals.
After that, I asked it to implement them sequentially, but that turned out to be slow. I ended up manually assigning individual agents to implement each change.
I’m very interested in this idea of bulk spec development and would love to hear any thoughts or best practices.