You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ATM we're truly focusing on Copilot and making sure folks who use it have a simple onramp for multi-agency. Whilst I'm not opposed to it, I don't know how much of a diversion it'd be. I'll take it up with the Squad. :)
Tossed this into Windsurf and this is what it had to say. Kind of a bummer they don't have subagents yet:
Feasibility Assessment: Supporting Windsurf in Squad
Summary
Yes, it's feasible to support Windsurf, but it requires moderate architectural changes. The good news: Squad already has a platform abstraction pattern in place (CLI vs VS Code), so extending to Windsurf follows an established pattern.
Current Copilot-Specific Dependencies
I identified three categories of Copilot coupling:
1. Agent Spawning Mechanism (Medium Effort)
The core orchestration in @/.github/agents/squad.agent.md relies on Copilot-specific tools:
CLI: task tool with agent_type, mode, model, description, prompt parameters
VS Code: runSubagent / agent tools
Windsurf equivalent: Windsurf's Cascade doesn't expose a sub-agent spawning API. It has:
Tool calling (MCP, terminal, search, etc.) — up to 20-25 calls per prompt
AGENTS.md files for directory-scoped instructions
Memories & Rules for persistent context
No task/runSubagent equivalent — Cascade is a single-agent system
2. GitHub Copilot Coding Agent Integration (Low Effort to Remove/Abstract)
Windsurf: AGENTS.md or agents.md (directory-scoped, no frontmatter)
Key Architectural Difference
Aspect
Copilot
Windsurf
Multi-agent spawning
✅ task / runSubagent
❌ Single-agent (Cascade)
Agent file format
.agent.md with YAML frontmatter
AGENTS.md plain markdown
Background execution
✅ mode: "background"
❌ Synchronous only
Per-spawn model selection
✅ Dynamic
❌ Session model only
MCP support
✅
✅
Tool calling
✅
✅ (20-25 per prompt)
The fundamental blocker: Squad's core value proposition is multi-agent orchestration — spawning specialized agents (Lead, Frontend, Backend, Tester, Scribe) in parallel. Windsurf's Cascade is a single-agent system with no sub-agent spawning API.
Feasibility Options
Option A: Full Windsurf Support (High Effort)
Redesign Squad to work as a single-agent with role-switching:
Cascade reads .squad/team.md and "becomes" each agent sequentially
Use Windsurf's Workflows feature to encode multi-step processes
Use Skills (.windsurf/skills/) for agent-specific knowledge
Extend the existing platform detection pattern in squad.agent.md
## Platform Detection1. CLI mode — `task` tool available
2. VS Code mode — `runSubagent` available
3. Windsurf mode — neither available, use inline execution
4. Fallback mode — work inline
This already exists! See @/.github/agents/squad.agent.md:402-416. Windsurf would fall into "Fallback mode" — the coordinator works inline without delegation.
Effort: ~3-5 days to formalize and test Trade-off: Windsurf users get a degraded but functional experience
Recommendation
Start with Option C (Platform Abstraction Layer):
Windsurf already falls into the existing "Fallback mode" pattern
Create a Windsurf-compatible AGENTS.md that imports Squad's coordinator logic
Abstract the copilot subcommand to a generic "coding agent" concept
Document the degraded experience for Windsurf users
Concrete changes needed:
Add windsurf detection to @/index.js
Create AGENTS.md template alongside .agent.md
Abstract copilot-swe-agent references to a configurable "coding agent" identity
Update @/docs/scenarios/client-compatibility.md with Windsurf column
Thanks for raising this — and honestly, thanks for coming back with that detailed feasibility breakdown. That's an impressive amount of homework and it tells us a lot about what you're thinking.
Before we go further, I'd love to understand more about what you're after. Reading your analysis, I see two distinct directions, and they have very different implications:
Option A: Squad's structured team prompting → brought to Windsurf/Cursor
In this scenario, you'd still have GitHub Copilot as the LLM backend, but Squad's team roster, routing, decision logging, and multi-agent coordination would work inside Windsurf or Cursor as the editor surface. Essentially: Squad's brains, different editor shell.
Option B: Squad's experience running atop Claude/other models natively
Here, you'd want the full Squad workflow — team definitions, agent charters, fan-out orchestration — but powered by whatever model Windsurf or Cursor uses natively (Claude, GPT, etc.), with no Copilot dependency at all.
These are meaningfully different asks. Option A is about editor portability. Option B is about model portability.
Where we are today: Squad is focused on enhancing the GitHub Copilot developer experience. That's where our testing, our integration points, and our validation all live right now. We want to be transparent about that — not because we're closing doors, but because that's where we can deliver the most reliable experience today.
Your feasibility analysis actually surfaced something really valuable: the "fundamental blocker" you identified — that Windsurf's Cascade is a single-agent system with no sub-agent spawning API — is exactly the kind of constraint that determines whether this is a "degrade gracefully" story or a "rethink the architecture" story. The existing fallback mode in squad.agent.md (lines 402–416, as you found) already handles the single-agent case, but as you noted, it loses Squad's parallel fan-out advantage, which is... kind of the point of having a team.
So: which of those two directions resonates more with what you're looking for? And is there a specific workflow you're trying to enable — something concrete where you'd say "if Squad worked in Cursor/Windsurf, I could do this"? That context would help us think about what's worth building versus what's a nice-to-have.
Great question! Squad's .squad/ directory structure (team.md, agent charters, decisions) is completely IDE-agnostic — any AI coding assistant can read plain markdown. The squad.agent.md file is currently Copilot-specific, but the underlying team data is universal. Windsurf and Cursor support is a natural next step, but we're focusing on Copilot's CLI first. The architecture is ready; it's a matter of adapting the agent prompt for other IDEs. Thanks for thinking ahead! 💡
Activity
bradygaster commentedon Feb 16, 2026
ATM we're truly focusing on Copilot and making sure folks who use it have a simple onramp for multi-agency. Whilst I'm not opposed to it, I don't know how much of a diversion it'd be. I'll take it up with the Squad. :)
NapalmCodes commentedon Feb 20, 2026
Tossed this into Windsurf and this is what it had to say. Kind of a bummer they don't have subagents yet:
Feasibility Assessment: Supporting Windsurf in Squad
Summary
Yes, it's feasible to support Windsurf, but it requires moderate architectural changes. The good news: Squad already has a platform abstraction pattern in place (CLI vs VS Code), so extending to Windsurf follows an established pattern.
Current Copilot-Specific Dependencies
I identified three categories of Copilot coupling:
1. Agent Spawning Mechanism (Medium Effort)
The core orchestration in
@/.github/agents/squad.agent.mdrelies on Copilot-specific tools:tasktool withagent_type,mode,model,description,promptparametersrunSubagent/agenttoolsWindsurf equivalent: Windsurf's Cascade doesn't expose a sub-agent spawning API. It has:
task/runSubagentequivalent — Cascade is a single-agent system2. GitHub Copilot Coding Agent Integration (Low Effort to Remove/Abstract)
Files with
copilot-swe-agentreferences:@/index.js:598-713—copilotsubcommand@/templates/workflows/squad-issue-assign.yml— assignscopilot-swe-agent[bot]@/templates/workflows/squad-heartbeat.yml— auto-assigns @copilot@/templates/workflows/squad-triage.yml— routes to @copilot@/templates/copilot-instructions.md— Copilot-specific instructions3. Agent File Discovery (Low Effort)
.github/agents/*.agent.mdAGENTS.mdoragents.md(directory-scoped, no frontmatter)Key Architectural Difference
task/runSubagent.agent.mdwith YAML frontmatterAGENTS.mdplain markdownmode: "background"The fundamental blocker: Squad's core value proposition is multi-agent orchestration — spawning specialized agents (Lead, Frontend, Backend, Tester, Scribe) in parallel. Windsurf's Cascade is a single-agent system with no sub-agent spawning API.
Feasibility Options
Option A: Full Windsurf Support (High Effort)
Redesign Squad to work as a single-agent with role-switching:
.squad/team.mdand "becomes" each agent sequentially.windsurf/skills/) for agent-specific knowledgeEffort: ~2-3 weeks, significant prompt engineering
Trade-off: Loses Squad's parallel fan-out advantage
Option B: Windsurf-Lite Support (Medium Effort)
Support Windsurf for the non-orchestration features:
.squad/team.md).squad/decisions.md).squad/routing.md)copilotsubcommandCascade would read Squad state files but work as a single agent informed by team context.
Effort: ~1 week
Trade-off: No multi-agent spawning, but team context is preserved
Option C: Platform Abstraction Layer (Medium-High Effort)
Extend the existing platform detection pattern in
squad.agent.mdThis already exists! See
@/.github/agents/squad.agent.md:402-416. Windsurf would fall into "Fallback mode" — the coordinator works inline without delegation.Effort: ~3-5 days to formalize and test
Trade-off: Windsurf users get a degraded but functional experience
Recommendation
Start with Option C (Platform Abstraction Layer):
AGENTS.mdthat imports Squad's coordinator logiccopilotsubcommand to a generic "coding agent" conceptConcrete changes needed:
windsurfdetection to@/index.jsAGENTS.mdtemplate alongside.agent.mdcopilot-swe-agentreferences to a configurable "coding agent" identity@/docs/scenarios/client-compatibility.mdwith Windsurf columnComplexity Rating
squad.agent.mdtemplates/index.js, 4 workflow filesdocs/bradygaster commentedon Mar 5, 2026
Hey @NapalmCodes 👋
Thanks for raising this — and honestly, thanks for coming back with that detailed feasibility breakdown. That's an impressive amount of homework and it tells us a lot about what you're thinking.
Before we go further, I'd love to understand more about what you're after. Reading your analysis, I see two distinct directions, and they have very different implications:
Option A: Squad's structured team prompting → brought to Windsurf/Cursor
In this scenario, you'd still have GitHub Copilot as the LLM backend, but Squad's team roster, routing, decision logging, and multi-agent coordination would work inside Windsurf or Cursor as the editor surface. Essentially: Squad's brains, different editor shell.
Option B: Squad's experience running atop Claude/other models natively
Here, you'd want the full Squad workflow — team definitions, agent charters, fan-out orchestration — but powered by whatever model Windsurf or Cursor uses natively (Claude, GPT, etc.), with no Copilot dependency at all.
These are meaningfully different asks. Option A is about editor portability. Option B is about model portability.
Where we are today: Squad is focused on enhancing the GitHub Copilot developer experience. That's where our testing, our integration points, and our validation all live right now. We want to be transparent about that — not because we're closing doors, but because that's where we can deliver the most reliable experience today.
Your feasibility analysis actually surfaced something really valuable: the "fundamental blocker" you identified — that Windsurf's Cascade is a single-agent system with no sub-agent spawning API — is exactly the kind of constraint that determines whether this is a "degrade gracefully" story or a "rethink the architecture" story. The existing fallback mode in squad.agent.md (lines 402–416, as you found) already handles the single-agent case, but as you noted, it loses Squad's parallel fan-out advantage, which is... kind of the point of having a team.
So: which of those two directions resonates more with what you're looking for? And is there a specific workflow you're trying to enable — something concrete where you'd say "if Squad worked in Cursor/Windsurf, I could do this"? That context would help us think about what's worth building versus what's a nice-to-have.
Genuinely curious to hear more.
— McManus (DevRel) · Posted by Squad
bradygaster commentedon Mar 7, 2026
Great question! Squad's .squad/ directory structure (team.md, agent charters, decisions) is completely IDE-agnostic — any AI coding assistant can read plain markdown. The squad.agent.md file is currently Copilot-specific, but the underlying team data is universal. Windsurf and Cursor support is a natural next step, but we're focusing on Copilot's CLI first. The architecture is ready; it's a matter of adapting the agent prompt for other IDEs. Thanks for thinking ahead! 💡
Merge pull request github#79 from jbenami_microsoft/squad/78-repo-con…