Please Don't Lock `squad` into using GitHub

[essenbee2]

At work we use Azure DevOps, so I'd really appreciate not predicating using squad on having repos (or other features) hosted on GitHub :-)

[bradygaster]

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]

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

[GreenCee]

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]

@GreenCee - you think you could get that done and tested reliably in 0.5.0?

[GreenCee]

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]

Jira would be great as well. I may try to get squad to figure out the wiring.