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
right now that's the plan - to not lock any git providers out. thank you for the issue and the interest. zero intent on locking out any git providers. ideally your only requirement will be Copilot.
Thanks for raising this, @essenbee2. This is something we've been designing for from early on.
We have a provider abstraction architecture in progress. The key decisions so far:
Provider abstraction is prompt-level, not code-level. Squad's coordinator is a prompt that executes shell commands. Abstracting providers means swapping command templates (e.g., gh issue create → az boards work-item create → glab issue create), not building a JavaScript runtime layer. The CLI installer (index.js) has near-zero platform coupling today.
Capability negotiation per provider. Each provider declares what it supports (issues, PRs, labels, project boards, etc.). If a capability isn't available, Squad skips it gracefully rather than failing.
Local-mode fallback. If no platform CLI is installed or authenticated, Squad works offline — proposals as markdown files, no issue tracking, no PRs. This is the current default behavior and will remain as graceful degradation.
Day 1 = GitHub, Day 2 providers are additive. GitHub ships first because it's where we can validate end-to-end. ADO and GitLab are designed in from the start but ship when there's demand. The architecture supports adding providers without refactoring existing functionality.
Label taxonomy already maps cross-platform. Our label system (which drives Squad's workflow state machine) maps to ADO states + tags and GitLab scoped labels. The translation layer is documented.
Your only hard requirement will be a Copilot-compatible environment. The git provider is a pluggable surface, not a locked dependency.
I observed that ralph uses gh commands, but it was able to recreate the functionality for ADO on the fly. It may need an improvement when you want to use ADO work items as the source of truth.
I did it in a major project where I set some guardrails (ONLY work in EPIC ####) which may be needed since there isn't the same repo>Issue mapping as Github
Reacted by Stu Bonham, Brady Gaster and Marcus Felling
I'll revisit Tuesday, I want to get a few more example flows captured in terms of correctly identifying the right ADO items.
Right now I'm not confident in the selection not running rampant over entire ADO orgs out of the box
Thanks so much for raising this! We hear you on Azure DevOps concerns. The good news: Squad is already architecture-agnostic at its core. Our new MCP (Model Context Protocol) integration means Squad can now connect to external services like Trello, Notion, and Azure via MCP servers — see .squad/skills/mcp-tool-discovery/SKILL.md for details.
Plus, the SDK mode (defineSquad() in squad.config.ts) provides a typed abstraction layer that teams can extend. We're exploring pluggable backends for history and decisions too (see #162). GitHub remains the default, but the foundation is intentionally extensible. We'll keep this in mind as we evolve! 🙌
Activity
[-]Please Don't Lock `squad` into using GuitHub[/-][+]Please Don't Lock `squad` into using GitHub[/+]bradygaster commentedon Feb 10, 2026
right now that's the plan - to not lock any git providers out. thank you for the issue and the interest. zero intent on locking out any git providers. ideally your only requirement will be Copilot.
bradygaster commentedon Feb 11, 2026
Thanks for raising this, @essenbee2. This is something we've been designing for from early on.
We have a provider abstraction architecture in progress. The key decisions so far:
Provider abstraction is prompt-level, not code-level. Squad's coordinator is a prompt that executes shell commands. Abstracting providers means swapping command templates (e.g.,
gh issue create→az boards work-item create→glab issue create), not building a JavaScript runtime layer. The CLI installer (index.js) has near-zero platform coupling today.Capability negotiation per provider. Each provider declares what it supports (issues, PRs, labels, project boards, etc.). If a capability isn't available, Squad skips it gracefully rather than failing.
Local-mode fallback. If no platform CLI is installed or authenticated, Squad works offline — proposals as markdown files, no issue tracking, no PRs. This is the current default behavior and will remain as graceful degradation.
Day 1 = GitHub, Day 2 providers are additive. GitHub ships first because it's where we can validate end-to-end. ADO and GitLab are designed in from the start but ship when there's demand. The architecture supports adding providers without refactoring existing functionality.
Label taxonomy already maps cross-platform. Our label system (which drives Squad's workflow state machine) maps to ADO states + tags and GitLab scoped labels. The translation layer is documented.
Your only hard requirement will be a Copilot-compatible environment. The git provider is a pluggable surface, not a locked dependency.
— 🎯 Keaton (Lead) · Posted by Squad
docs(ai-team): issue triage session - #8 and #6
GreenCee commentedon Feb 12, 2026
I observed that ralph uses gh commands, but it was able to recreate the functionality for ADO on the fly. It may need an improvement when you want to use ADO work items as the source of truth.
I did it in a major project where I set some guardrails (ONLY work in EPIC ####) which may be needed since there isn't the same repo>Issue mapping as Github
bradygaster commentedon Feb 13, 2026
@GreenCee - you think you could get that done and tested reliably in 0.5.0?
GreenCee commentedon Feb 13, 2026
I'll revisit Tuesday, I want to get a few more example flows captured in terms of correctly identifying the right ADO items.
Right now I'm not confident in the selection not running rampant over entire ADO orgs out of the box
matthewDDennis commentedon Feb 20, 2026
Jira would be great as well. I may try to get squad to figure out the wiring.
feat: add remote squad mode, hub management, and doctor command
fix: apply P0+P1 security audit findings for remote-control
fix: add EISDIR, NaN, stream error, non-JSON PTY, and decodeURI guards
2 remaining items
essenbee2 commentedon Mar 5, 2026
This sounds perfect to me. Looking forward to the implementation!
bradygaster commentedon Mar 7, 2026
Thanks so much for raising this! We hear you on Azure DevOps concerns. The good news: Squad is already architecture-agnostic at its core. Our new MCP (Model Context Protocol) integration means Squad can now connect to external services like Trello, Notion, and Azure via MCP servers — see .squad/skills/mcp-tool-discovery/SKILL.md for details.
Plus, the SDK mode (defineSquad() in squad.config.ts) provides a typed abstraction layer that teams can extend. We're exploring pluggable backends for history and decisions too (see #162). GitHub remains the default, but the foundation is intentionally extensible. We'll keep this in mind as we evolve! 🙌
fix: SDK init trio — #337 config sync, #338 Ralph in init, #339 remov…
fix: SDK init trio — #337 config sync, #338 Ralph in init, #339 remov…
fix: SDK init trio - routing, Ralph, and config wiring (#337, #338, #339
docs: add squad doctor troubleshooting guidance
docs: add squad doctor troubleshooting guidance
docs: Add nap, reskill, and compact behavior documentation (#448)
samples: standardize READMEs, naming, and add template
samples: standardize READMEs, naming, and add template
samples: standardize READMEs, naming, and add template (#484)
feat: runtime role registration API and custom universe loading (gith…
feat: add FIDO routing rules for PR requirements enforcement
Add Coordinator Restraint rules to squad agent prompt (#587)