feat(agents): ADO Backlog Manager

[chaosdinosaur]

Summary

Add an ADO Backlog Manager orchestrator agent mirroring the GitHub Backlog Manager
pattern for Azure DevOps. This epic tracks the full feature across multiple PRs.

Scope

• Central orchestrator agent with 22 ADO MCP tools and 10 handoff buttons
• 9 workflow types: triage, discovery, PRD planning, sprint planning, execution,
  single work item, task planning, build info, and PR creation
• 3-phase Required Phases pattern (classify → dispatch → summarize)
• Three-tier autonomy model (Full/Partial/Manual)
• Content sanitization guards for .copilot-tracking/ paths
• Content format detection (Markdown for ADO Services, HTML for ADO Server)
• ADO interaction templates for work item descriptions and comments (Markdown + HTML variants)
• Collection manifest updates

Files

New (8)

• .github/agents/ado/ado-backlog-manager.agent.md
• .github/prompts/ado/ado-triage-work-items.prompt.md
• .github/prompts/ado/ado-sprint-plan.prompt.md
• .github/prompts/ado/ado-discover-work-items.prompt.md
• .github/prompts/ado/ado-add-work-item.prompt.md
• .github/instructions/ado/ado-backlog-triage.instructions.md
• .github/instructions/ado/ado-backlog-sprint.instructions.md
• .github/instructions/ado/ado-interaction-templates.instructions.md

Modified (10)

• .github/instructions/ado/ado-wit-planning.instructions.md (autonomy + sanitization + format detection)
• .github/instructions/ado/ado-update-wit-items.instructions.md (autonomy hook + dry run + dynamic format)
• .github/instructions/ado/ado-wit-discovery.instructions.md (autonomy hook)
• .github/prompts/ado/ado-process-my-work-items-for-task-planning.prompt.md (agent routing)
• .github/prompts/ado/ado-update-wit-items.prompt.md (agent routing + contentFormat input)
• .github/prompts/ado/ado-get-build-info.prompt.md (agent routing)
• .github/prompts/ado/ado-create-pull-request.prompt.md (agent routing)
• .github/prompts/ado/ado-get-my-work-items.prompt.md (agent routing + contentFormat input)
• collections/ado.collection.yml (8 new entries)
• collections/ado.collection.md (backlog management bullet)

PR Sequence

PR	Issue	Title	Dependency
1	#776	Shared infrastructure (autonomy, sanitization, format detection, templates)	None — merge first
2	#777	Triage workflow and prompt (with contentFormat input)	PR 1
3	#779	Sprint planning workflow and prompt (with contentFormat input)	PR 1
4	#778	Discovery, add-work-item, and existing prompt rewiring (with contentFormat input)	PR 1
5	#775	Orchestrator agent and collection updates	PRs 1–4

Acceptance Criteria

• IS002: Foundation merged (autonomy, sanitization, format detection, templates)
• IS003: Triage workflow merged (with contentFormat input)
• IS004: Sprint planning workflow merged (with contentFormat input)
• IS005: Discovery, add-work-item, and prompt rewiring merged (with contentFormat input)
• IS006: Orchestrator agent and collection updates merged
• Plugin generation passes (npm run plugin:generate)
• All markdown linting passes (npm run lint:md)

[WilliamBerryiii]

Technical Review: ADO Backlog Manager Epic

Thanks for the thorough design work on this, @chaosdinosaur. I ran a deep analysis across the existing ADO collection (12+ files), GitHub Backlog Manager (13 files), Agile Coach, and the parity gaps between PRD→ADO and PRD→GBM. Here's what I found, along with some suggested refinements.

---

1. Prompt Count — Correctly Sized, No Consolidation Needed

Initial concern was whether 4 new prompts + 5 modifications introduced too many artifacts. After mapping each against the GitHub Backlog Manager counterparts, they're justified:

Proposed ADO Prompt	GitHub Counterpart	Distinct Responsibility
ado-discover-work-items	github-discover-issues	Three-path discovery (User-Centric, Artifact-Driven, Search-Based)
ado-triage-work-items	github-triage-issues	Classify, label, prioritize raw work items
ado-sprint-plan	github-sprint-plan	Iteration-level coverage analysis, gap identification, priority ordering
ado-add-work-item	github-add-issue	Single work item creation with template guidance

The 5 modified prompts (ado-get-my-work-items, ado-process-my-work-items, ado-update-wit-items, ado-create-pull-request, ado-get-build-info) receive only agent: frontmatter routing metadata — zero logic changes. Each new prompt has distinct instruction dependencies, input/output contracts, and output artifacts. Merging any two would violate single-responsibility. No consolidation opportunities exist.

Post-change ADO prompt count: 9 (5 existing RPI pipeline + 4 new backlog management) vs GitHub's 5 — the delta is justified by ADO's richer operational surface (build info, PR creation, task planning).

---

2. Agile Coach Integration — Not Recommended for Sprint Planning

The Agile Coach and sprint planning operate at fundamentally different abstraction levels:

Dimension	Sprint Planning	Agile Coach
Abstraction level	Portfolio/sprint (N items)	Single story (1 item)
Interaction model	Deterministic 4-step workflow	Conversational, iterative
Tool requirements	Deep MCP integration (13+ tools)	None (tool-agnostic by design)
Platform dependency	Platform-specific (ADO iterations)	Platform-independent
Output type	Sprint plan artifacts (4 files)	Copy-paste-ready story markdown

They're complementary, not competing. The lifecycle docs already position both as complementary tools.

Suggestion: Instead of integrating them directly, consider a follow-up issue to extract shared story quality conventions (title patterns, acceptance criteria format, DoD checklist) into a standalone story-quality.instructions.md that both the Agile Coach and the ADO sprint prompt can reference when generating new work items during gap analysis. This shares quality patterns without coupling agents.

---

3. PRD→ADO vs PRD→GBM Parity — #774 Fills the Gaps

The parity gap is real and this epic fills it precisely:

Capability	GitHub	ADO Today	ADO After #774
Orchestrator agent	✅	❌	✅
Discovery (3 paths)	✅	❌ (agent only)	✅
Triage	✅	❌	✅
Sprint planning	✅	❌	✅
Single item creation	✅	❌	✅
Three-tier autonomy	✅	❌	✅
Content sanitization	✅	❌	✅
Similarity assessment	✅ (formalized)	❌	✅
Interaction templates	✅	❌	✅

After #774, ADO becomes a superset of GBM's capabilities (adding build info, PR creation, task planning, and the specialized PRD-to-WIT agent). This is the correct outcome given ADO's richer operational surface.

---

4. Suggested Refinements

4a. Resolve ado-prd-to-wit.agent.md Dispatch Overlap

The proposed ado-discover-work-items.prompt.md Path B (artifact-driven discovery) partially overlaps with the existing ado-prd-to-wit.agent.md. GitHub handles this entirely within the discovery prompt, but ADO's Epic→Feature→Story hierarchy and the PRD-to-WIT agent's 5-phase codebase analysis provide unique value.

Recommendation: Keep both with explicit delineation in the orchestrator dispatch table — route PRD-specific discovery to ado-prd-to-wit.agent.md as a sub-agent, and constrain the discovery prompt's Path B to non-PRD artifacts. The agents: frontmatter on the orchestrator should reference ado-prd-to-wit.agent.md as a sub-agent.

4b. ADO-Specific Sprint Planning Enhancements

Sub-issue #779 should explicitly call out quantitative capabilities ADO enables that GBM can't provide:

• Quantitative capacity planning using StoryPoints sum vs team velocity (not heuristic)
• Effort tracking via RemainingWork/CompletedWork for burndown analysis
• Explicit dependency graphs from Predecessor/Successor link types (stronger than GitHub cross-references)
• Hierarchical coverage analysis across Epic → Feature → Story → Task (4 levels vs GBM's 2)
• Priority field ordering via Microsoft.VSTS.Common.Priority (1-4 quantitative scale)

These are ADO advantages that should be leveraged in the sprint planning design.

4c. Interaction Templates — Internal Focus

GitHub's community-interaction.instructions.md has 14+ community-facing templates (duplicate closures, stale notifications, contributor onboarding). ADO work item comments are typically internal-facing. The ado-interaction-templates.instructions.md should define a different set appropriate for internal ADO communication — status updates, blocker escalation, sprint carry-over notes, dependency notifications — rather than mirroring the GitHub community templates.

4d. Clarify 10th Handoff Button

The epic lists 10 handoff buttons but only 9 workflow types. Can you clarify what the 10th maps to? (Checkpoint/save action?)

---

Summary

The design is architecturally sound and well-aligned with existing GBM patterns. No prompt consolidation is warranted — the 4 new prompts are correctly sized with 1:1 GBM parity. The Agile Coach should remain separate (with shared story-quality conventions extracted as a follow-up). The main items needing attention are the ado-prd-to-wit dispatch overlap resolution, ADO-specific sprint planning enhancements, and scoping interaction templates for internal use.

Happy to dig deeper into any of these areas.