Feature Request: Provider-Agnostic Multi-Agent Orchestration (Inspired by Anthropic's feature-dev)

[rodrigotanco]

I’ve been tracking the new official feature-dev plugin implemented by the Anthropic Claude Code team(https://github.com/anthropics/claude-plugins-official/tree/main/plugins/feature-dev ). The core concept is incredibly similar to the Spec-Driven Development philosophy of the OpenSpec (OPSX) workflow, but with a major architectural twist: it uses isolated, specialized sub-agents for different stages of the lifecycle.

Instead of a single chat thread, it routes the task through three distinct backend agents:

code-explorer (Strictly maps dependencies/code paths—keeps context clean)
code-architect (Drafts the implementation plan/spec)
code-reviewer (Runs post-change verification with confidence scoring)

Why OpenSpec is the perfect home for this:
Right now, this multi-agent separation is locked behind the Anthropic ecosystem. If we can bring this Multi-Agent Orchestration Layer into OpenSpec, we can make it completely provider-agnostic.

Proposal for Discussion:
Could we define an agents.md or a standard metadata block inside the .spec/ directory to declaratively assign specific roles, prompts, and LLM providers to different phases of the OPSX lifecycle (/opsx:new, /opsx:apply, /opsx:verify)?

This would prevent token bloat/context poisoning and give developers complete control over a cross-provider agentic stack.

Would love to hear the maintainers' and community's thoughts on implementing an orchestration layer like this! Maybe this is already on the plans.

[devnomad-byte]

This is very close to the direction I have been exploring from the project-governance side.

I agree that the orchestration layer should probably stay provider-agnostic. The pattern that has worked best for me is to keep one canonical project contract, then let each tool act as a thin adapter around it:

• AGENTS.md as the shared project constitution
• task.md as the task ledger and evidence trail
• tool adapters such as CLAUDE.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, .opencode/AGENTS.md, and .trae/rules/*.md
• role definitions for product, research, architect, UI/UX, frontend, backend, QA, DevOps, and governance
• a verification harness before any task can be marked done

I packaged that experiment as a small open-source initializer called Cosmosmith:

https://github.com/devnomad-byte/cosmosmith

It installs with:

npx cosmosmith@latest init --all

The part that may be useful to this OpenSpec discussion is not the exact implementation, but the adapter shape: OpenSpec could stay focused on proposal/spec/change lifecycle, while an orchestration layer declares which role owns each phase, what context is loaded, and what harness proves the phase is complete.

In Cosmosmith terms, I describe the loop as Prompt / Context / Harness / Loop:

• Prompt: the current role instruction and expected output
• Context: selected specs, files, research, and constraints
• Harness: tests, lint, build, browser checks, or review gates
• Loop: the feedback/evidence used before completion

I would be curious whether OpenSpec maintainers see this living inside .spec/ metadata, in AGENTS.md, or as an adapter/plugin layer that points back to OpenSpec. My bias is to avoid making every agent tool own the workflow independently; one canonical governance layer plus thin adapters seems easier to audit across Claude Code, Codex, Cursor, OpenCode, Trae, etc.