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.

[mnriem]

Would love to see something like that. Note that there will probably be some parts that would be coding agent specific and other parts that can be done by integration, extension, preset or workflow. So please let me know what you need from the Spec Kit core to make this a reality. Maybe it can be done completely using the primitives we already have?

[RbBtSn0w]

Thanks, this is exactly the distinction I’ve been trying to sharpen in some of my recent work in superb.

I’ve been doing some work in superb around this boundary, especially borrowing lessons from superpowers without trying to replace Spec Kit’s own stage ownership.

What I’ve learned from superpowers is that the important part is usually not “multi-agent runtime support” by itself, but whether the workflow exposes a stable contract across planning, task shaping, and execution.

My current view is:

Spec Kit probably does not need to make a specific coding-agent runtime a core dependency.

But Spec Kit should consider whether plan, tasks, and implement need a more explicit model for modern SDD-style execution, so that extensions/presets can build on a stronger shared contract instead of re-inventing it per agent stack.

Concretely, I think the split is something like this:

What can likely stay in integrations/extensions/presets:

• engine-specific subagent invocation
• parallel vs serial scheduling policy
• review backend choice
• prompt packaging details
• local evidence capture / journaling implementation

What may be worth making more explicit in Spec Kit core:

• task boundaries that are safe for bounded workers
• dependency semantics that are useful not only for humans, but also for agent dispatch
• a small status/outcome vocabulary for implementation work
• a clean handoff shape from plan -> tasks -> implement
• explicit retry / escalation / review loop points
• a place for evidence or verification results to flow back into the task lifecycle

The reason I think this matters is that modern SDD is not only an implement concern.

If we wait until implement, we’re already too late for a lot of the important structure:

• plan needs to produce execution-oriented slices
• tasks needs to encode bounded ownership, dependency, and reviewability
• implement then executes that contract, either serially or in parallel depending on the runtime

That has been one of the main takeaways from the superb work so far: the best portability comes from making the protocol stable before runtime decisions are made.

So my current instinct is:

• keep the actual orchestration runtime out of Spec Kit core
• but consider a lightweight, first-class SDD-oriented contract across plan / tasks / implement

In other words, not “Spec Kit should become a multi-agent framework,” but rather:
“Spec Kit should expose enough execution-shaping structure that modern agent systems can plug into it cleanly.”

[mnriem]

Note on the lightweight-ness checkout the lean preset ;)

[devnomad-byte]

I strongly agree with the protocol-first framing here.

I have been testing a similar shape in a small open-source initializer called Cosmosmith:

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

The relevant part is that it treats multi-agent work as a portable contract rather than assuming a specific runtime. It generates a shared AGENTS.md, tool adapters (CLAUDE.md, Cursor rules, Copilot instructions, OpenCode/Trae adapters), and a task.md ledger where each task records:

• role
• prompt
• context
• expected output
• harness
• loop
• evidence
• status

That maps pretty closely to your coordinator / worker / reviewer split. The important constraint I found is that the protocol needs a completion gate: no task should be marked done unless the harness and evidence are recorded. Otherwise multi-agent execution becomes a faster way to create unverifiable drift.

If Spec Kit formalizes this, I would love to see the protocol stay runtime-neutral:

• parallel runtimes can fan out independent tasks
• serial runtimes can execute the same contract sequentially
• review gates and evidence format remain the same
• agent-specific files stay as adapters, not the source of truth

The smallest useful first step may be a template/profile that defines status vocabulary and evidence requirements, even before any runtime orchestration is added.