microsoft/hve-core
Publicmirrored fromhttps://github.com/microsoft/hve-coreAvailable
docs/agents/github-backlog/README.md
110lines · modecode
| 1 | --- |
| 2 | title: GitHub Backlog Manager |
| 3 | description: Automated issue discovery, triage, sprint planning, and execution for GitHub repositories |
| 4 | sidebar_position: 1 |
| 5 | author: Microsoft |
| 6 | ms.date: 2026-02-12 |
| 7 | ms.topic: concept |
| 8 | keywords: |
| 9 | - github backlog manager |
| 10 | - issue management |
| 11 | - triage |
| 12 | - sprint planning |
| 13 | - github copilot |
| 14 | estimated_reading_time: 5 |
| 15 | --- |
| 16 | |
| 17 | The GitHub Backlog Manager automates issue lifecycle management across GitHub repositories. It coordinates five specialized workflows (discovery, triage, sprint planning, execution, and quick add) through planning files and handoff artifacts, applying consistent labels, detecting duplicates, and organizing issues into milestones with configurable autonomy levels. |
| 18 | |
| 19 | > Backlog management is a constraint-satisfaction problem. Each workflow handles a bounded scope, reducing errors by limiting the decisions any single step makes. |
| 20 | |
| 21 | ## Why Use the Backlog Manager? |
| 22 | |
| 23 | * 🏷️ Consistency: Every issue receives labels, priority, and milestone assignment following the same taxonomy, eliminating drift across contributors |
| 24 | * 🔍 Visibility: Discovery workflows surface issues from code changes, team assignments, and cross-repository searches, so nothing falls through gaps |
| 25 | * ⚡ Throughput: Automated triage and sprint planning handle repetitive decisions, freeing your team for engineering work |
| 26 | |
| 27 | > [!TIP] |
| 28 | > For the full rationale and quality comparison, see [Why the Backlog Manager Works](why-backlog-manager.md). |
| 29 | |
| 30 | ## The Five Workflows |
| 31 | |
| 32 | ### 🔍 Discovery |
| 33 | |
| 34 | Discovery finds and categorizes issues from multiple sources. Three discovery paths cover different starting points: user-centric (assigned issues), artifact-driven (local code changes mapped to backlog items), and search-based (criteria-driven queries across repositories). Discovery produces issue analysis files that feed into triage. |
| 35 | |
| 36 | See the [Discovery workflow guide](discovery.md) for paths, artifacts, and examples. |
| 37 | |
| 38 | ### 🏷️ Triage |
| 39 | |
| 40 | Triage assigns labels, assesses priority, and detects duplicates for discovered issues. It applies a 17-label taxonomy organized by type, area, priority, and lifecycle categories. Conventional commit patterns in issue titles inform label suggestions. A four-aspect similarity framework flags potential duplicates before they create noise. |
| 41 | |
| 42 | See the [Triage workflow guide](triage.md) for the label taxonomy and duplicate detection. |
| 43 | |
| 44 | ### 📋 Sprint Planning |
| 45 | |
| 46 | Sprint planning organizes triaged issues into milestones with capacity awareness. A six-step milestone discovery process matches issues to existing or new milestones. The workflow assesses issue volume against team capacity and recommends distribution across sprints. |
| 47 | |
| 48 | See the [Sprint Planning workflow guide](sprint-planning.md) for milestone discovery and capacity planning. |
| 49 | |
| 50 | ### ⚡ Execution |
| 51 | |
| 52 | Execution consumes handoff files produced by earlier workflows and performs the planned operations. It creates, updates, and closes issues according to the plan, tracking each operation with checkbox-based progress and per-operation logging. Failed operations log errors without blocking the rest of the batch. |
| 53 | |
| 54 | See the [Execution workflow guide](execution.md) for handoff consumption and operation logging. |
| 55 | |
| 56 | ### ➕ Quick Add |
| 57 | |
| 58 | Quick Add is a single-issue shortcut for creating one issue without running the full pipeline. Use it when you need to file an issue quickly and apply standard labels and milestone in a single step. |
| 59 | |
| 60 | ## Autonomy Levels |
| 61 | |
| 62 | The backlog manager operates at three autonomy tiers, controlling which operations proceed automatically and which pause for approval. |
| 63 | |
| 64 | | Tier | Create | Labels/Milestone | Close | Comment | |
| 65 | |-------------------|--------|------------------|-------|---------| |
| 66 | | Full | Auto | Auto | Auto | Auto | |
| 67 | | Partial (default) | Gate | Auto | Gate | Auto | |
| 68 | | Manual | Gate | Gate | Gate | Gate | |
| 69 | |
| 70 | Partial autonomy is the default, applying labels and milestones automatically while gating issue creation and closure for review. Adjust the tier based on repository maturity and team trust. |
| 71 | |
| 72 | ## When to Use |
| 73 | |
| 74 | | Use Backlog Manager When... | Use Manual Management When... | |
| 75 | |-------------------------------------------------|-------------------------------------------| |
| 76 | | Managing more than 20 open issues | Working with fewer than 10 issues | |
| 77 | | Multiple contributors need consistent triage | Single maintainer with full context | |
| 78 | | Sprint planning requires milestone organization | No milestone-based planning process | |
| 79 | | Cross-repository issue discovery is needed | All issues originate from a single source | |
| 80 | | Label consistency matters for reporting | Ad-hoc labeling suits the workflow | |
| 81 | |
| 82 | ## Quick Start |
| 83 | |
| 84 | 1. Configure your MCP servers following the [MCP Configuration guide](../../getting-started/mcp-configuration.md) |
| 85 | 2. Open a Copilot Chat session and type: `Discover open issues assigned to me` |
| 86 | 3. Review the discovery output, then type `/clear` and start a triage session |
| 87 | 4. Continue through sprint planning and execution as needed |
| 88 | |
| 89 | > [!IMPORTANT] |
| 90 | > Clear context between workflows by typing `/clear`. Each workflow operates independently and mixing contexts produces unreliable results. |
| 91 | |
| 92 | ## Prerequisites |
| 93 | |
| 94 | The GitHub Backlog Manager requires MCP server configuration for GitHub API access. See [MCP Configuration](../../getting-started/mcp-configuration.md) for setup instructions. The GitHub MCP tools (listed in the agent specification) must be available in your VS Code context. |
| 95 | |
| 96 | ## Next Steps |
| 97 | |
| 98 | * [Discovery](discovery.md) - Find and categorize issues from multiple sources |
| 99 | * [Triage](triage.md) - Assign labels, priorities, and detect duplicates |
| 100 | * [Sprint Planning](sprint-planning.md) - Organize issues into milestones |
| 101 | * [Execution](execution.md) - Execute planned operations from handoff files |
| 102 | * [Using Workflows Together](using-together.md) - End-to-end pipeline walkthrough |
| 103 | * [Why the Backlog Manager Works](why-backlog-manager.md) - Design rationale and quality comparison |
| 104 | |
| 105 | --- |
| 106 | |
| 107 | <!-- markdownlint-disable MD036 --> |
| 108 | *🤖 Crafted with precision by ✨Copilot following brilliant human instruction, |
| 109 | then carefully refined by our team of discerning human reviewers.* |
| 110 | <!-- markdownlint-enable MD036 --> |