Proposal: Make /speckit.implement multi-agent by protocol, not by runtime

[RbBtSn0w]

I’d like to propose a direction for the implementation stage in Spec Kit, based on recent practice with modern agent engines.

Thesis

Spec Kit should treat multi-agent implementation primarily as a process contract, not as a specific runtime feature.

In other words:

• Define roles, status protocol, review loops, and escalation rules as the core.
• Let execution engines decide whether to run those contracts serially or in parallel.

Why this matters

Today, agent runtimes vary:

• Some support true parallel subagents.
• Some only support serial agent/task execution.
• Many teams use mixed environments.

If the contract is stable, the same Spec Kit artifacts can run across all of them with different throughput, while preserving quality and governance.

Proposed model for /speckit.implement

1. Coordinator role

• Owns task ordering, dependency checks, context packaging, and final merge decisions.

2. Worker role(s)

• Implements one bounded task with minimal context.
• Returns structured status: DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, BLOCKED.

3. Reviewer role(s)

• Stage 1: Spec compliance (did we build exactly what was requested?)
• Stage 2: Code quality (testability, maintainability, safety, clarity)
• Loop back to worker on failure.

4. Runtime policy

• If engine supports parallel subagents: fan-out independent tasks.
• If engine is serial-only: execute same contract sequentially.
• Same protocol, different scheduling.

Why this aligns with current Spec Kit strengths

Spec Kit already has:

• Task dependency and parallel markers [P]
• Workflow orchestration primitives (including fan-out/fan-in)
• Extension ecosystem for engine-specific behavior

This proposal focuses on formalizing an implementation protocol that those capabilities can consistently execute.

Concrete, incremental next step

Add an optional “implementation orchestration profile” for /speckit.implement (or workflow mode) that standardizes:

• Role definitions
• Status vocabulary
• Review gates
• Retry/escalation behavior

This can start as documentation + template conventions, then evolve into workflow presets and extension hooks.

If maintainers think this is useful, I’d be happy to help draft a concrete RFC skeleton with examples for both serial and parallel runtimes.