Speckit and Multi Agent Orchestration

[vessel-one]

Hi everyone,

Is anyone else experimenting with multi-agent workflows using GitHub Copilot, SpecKit, and VS Code?

I’ve been getting decent results so far — mainly by leveraging SpecKit for structure up until the task stage. Before implementation, I ask Sonnet 4.5 to enable multi-agent workflows through chat. It then rebuilds the tasks, assigns each to specific agents, and generates an agent-coordination.json file that defines priorities, parallel and blocking tasks — ensuring agents don’t overlap or start prematurely.

From there, I open several chat windows and use the prompts Sonnet 4.5 provides for each agent. Haiku 4.5 handles execution, and the results have been surprisingly good. Once the other agents finish, I get Sonnet 4.5 to review their output and provide the next set of instructions. It feels like this process could be integrated directly into SpecKit with a /command for smoother coordination.

With all the hype (and skepticism) around AI right now, we’re actually seeing strong, measurable results from SpecKit. We only implement small, incremental features at a time and slightly adjust the development flow — asking it to build tests, build feature tests, repair, build, test, repair rather than leaving testing until the end. This approach seems to catch about 98 % of errors, leaving only minor bugs.

Overall, results have been solid once you understand its limits — but I’m curious how others are approaching this.

[yousrasd]

Hey @vessel-one, thanks for sharing! Im experimenting with SpecKit, was wondering where do you fit the testing phase? Do you include it when you run the plan command?

[mnriem]

@vessel-one Have you considered adding extensions or presets so others can benefit from it?

[MCYLimited]

Hi all, at the speed AI is running, we now run claude code with the super powers plugin, its second to none, we almost get no re work , so long as the prd is spec'd and architected correctly. Using subagents starting with opus at top level, down to sonnet sub agent on execution.

[zhaoxi2000]

Yes, I install via specify init . --integration cursor-agent --integration claude, but it is not good for me in runtime.

[mnriem]

This is a great writeup — and the encouraging part is that the primitives you need are already in Spec Kit today. You've essentially rebuilt them by hand; the toolkit gives you the same building blocks and leaves them open for you to adjust to your own flow rather than locking you into one orchestrator.

Mapping your setup onto what already ships:

• Your agent-coordination.json is already [P] markers. /speckit.tasks emits a dependency-ordered tasks.md with parallel tasks flagged [P] and blocking phases (Setup → Foundational → per-story → Polish). That is the priorities/parallel/blocking graph — and because it's plain markdown, you can hand-edit the ordering, split phases, or re-tag [P] to match exactly how you want agents to divide work.

• Delegation is a one-liner you can shape. /speckit.implement takes free-form input, so on sub-agent-capable agents (Copilot CLI, Copilot in VS Code) you can steer it: /speckit.implement delegate each parallel [P] task to a sub-agent, or scope it (only the Core phase), or both. See Handling Complex Features. For fully independent slices, Spec of Specs runs them in parallel worktrees with isolated state.

• /speckit.converge is the review step you're doing by hand. It reads spec/plan/tasks as intent, assesses the actual code, classifies gaps (missing/partial/contradicts/unrequested), and appends remaining work as new tasks — append-only, never rewriting existing tasks, which is exactly what you want when several agents converge on one tasks.md. Your loop becomes tasks → implement (delegate [P]) → converge → implement → … until ✅ Converged — an objective, code-grounded check instead of relying on a model's recollection.

• And you can assemble these into your own repeatable pipeline. specify workflow is the orchestration layer — it supports fan-out/fan-in, gates, and pause/resume, and workflows are just YAML you own and tune. There's already a community one that automates the converge loop:

  specify workflow search convergence
  specify workflow add pipeline
  specify workflow run pipeline

  pipeline chains specify → clarify → plan → tasks → analyze → implement → converge with a clarify gate and a post-implement convergence loop. What isn't in the catalog yet is a parallel multi-agent fan-out workflow — that's precisely the piece you've prototyped. Fork pipeline as a starting point, add a fan-out over your [P] tasks with converge as the fan-in, and you'd have your exact flow as a shareable workflow. Happy to help shape it if you want to contribute it back.

The takeaway: you don't have to wait for a built-in /orchestrate — the pieces are all there and meant to be composed, and your build-test-repair-per-increment rhythm maps cleanly onto scoping each implement run with converge as the checkpoint between increments.

@zhaoxi2000 — that install/runtime question is really a separate topic from orchestration; you also raised it in #3946, which is already answered there. Let's keep that thread as the home for it so this discussion stays focused — happy to dig further with you over in #3946 if the answer there didn't cover your runtime issue.

Co-authored-by: GitHub Copilot (model: Claude Opus 4.8)