Multi-Provider: ADO + Jira

How the Abstraction Works

• **Single config switch** — One value in .ai/config.yaml (tracker.provider: ado or jira) routes all skills to the correct MCP backend. No code changes, no skill duplication.
• **Business logic stays the same** — Requirements analysis, planning, and implementation logic is identical regardless of where the ticket lives. Only the API calls to fetch and update tickets differ between providers.
• **Field name abstraction** — ADO calls it 'Acceptance Criteria,' Jira calls it 'Description.' The shared/provider-config.md file maps these fields so skills can reference generic names like 'acceptance criteria' everywhere.
• **Practical adoption strategy** — Start with one provider and get all skills working perfectly. Then add the second provider as an abstraction layer. Don't try to build both at once.

Provider Mapping Details

1. 1 **Provider mapping examples**
   • › ADO: mcp__ado__wit_get_work_item, mcp__ado__wit_update_work_item
   • › Jira: mcp__atlassian__get_issue, mcp__atlassian__update_issue
2. 2 **Quick switch** — Check your .ai/config.yaml for the tracker.provider value. Changing this one line switches the entire pipeline.
3. 3 **Customize field mappings** — Review shared/provider-config.md if your Jira instance uses custom field names that differ from the defaults
4. 4 **Test both paths** — After adding a second provider, run /dx-req <ticket-id> with each provider setting to verify field mapping works correctly