microsoft/hve-core
Publicmirrored fromhttps://github.com/microsoft/hve-coreAvailable
docs/agents/github-backlog/using-together.md
183lines · modecode
| 1 | --- |
| 2 | title: Using Workflows Together |
| 3 | description: Connect discovery, triage, sprint planning, and execution into a complete backlog management pipeline |
| 4 | sidebar_position: 7 |
| 5 | author: Microsoft |
| 6 | ms.date: 2026-05-20 |
| 7 | ms.topic: tutorial |
| 8 | keywords: |
| 9 | - github backlog manager |
| 10 | - workflow pipeline |
| 11 | - github copilot |
| 12 | - backlog management |
| 13 | estimated_reading_time: 8 |
| 14 | --- |
| 15 | |
| 16 | Each backlog manager workflow handles one phase of issue management. Connecting them creates a pipeline that takes issues from discovery through execution, with structured handoffs ensuring nothing falls through the cracks. |
| 17 | |
| 18 | ## The Pipeline |
| 19 | |
| 20 | ```text |
| 21 | ┌───────────┐ ┌────────┐ ┌─────────────────┐ ┌───────────┐ |
| 22 | │ Discovery │ ──→│ Triage │ ──→│ Sprint Planning │ ──→│ Execution │ |
| 23 | └───────────┘ └────────┘ └─────────────────┘ └───────────┘ |
| 24 | ↑ │ |
| 25 | └──────────────── Iterate ─────────────────────────────┘ |
| 26 | ``` |
| 27 | |
| 28 | The pipeline is linear but not rigid. Skip sprint planning when you only need to apply labels. Return to discovery after execution when new issues surface. Each workflow reads its predecessor's output files, so the pipeline works as long as the handoff artifacts exist. |
| 29 | |
| 30 | ## Clear Context Between Workflows |
| 31 | |
| 32 | Each workflow operates within its own session context. Mixing workflows in a single session produces unreliable results because the agent carries forward assumptions from the previous workflow. |
| 33 | |
| 34 | Between each workflow: |
| 35 | |
| 36 | 1. Type `/clear` to reset the conversation context |
| 37 | 2. Attach or reference the output files from the previous workflow |
| 38 | 3. Start the next workflow with a fresh prompt |
| 39 | |
| 40 | This is the single most important practice for reliable pipeline execution. The `/clear` step takes seconds and prevents hours of debugging misapplied labels or incorrect milestone assignments. |
| 41 | |
| 42 | > [!IMPORTANT] |
| 43 | > The `/clear` step between workflows is not optional. Each workflow loads specific instruction files and planning artifacts. Stale context from a previous workflow interferes with the current workflow's classification logic. |
| 44 | |
| 45 | All GitHub-facing comments (issue replies, label rationale, duplicate explanations) follow the voice and tone rules defined in `community-interaction.instructions.md`. This instruction file loads automatically when the backlog manager agents operate, so you do not need to configure it separately. |
| 46 | |
| 47 | ## Session Persistence |
| 48 | |
| 49 | The GitHub Backlog Manager includes a **Save** button that captures workflow context to a memory file, enabling you to resume after a context reset or across sessions. |
| 50 | |
| 51 | ### Save a Session |
| 52 | |
| 53 | Click **Save** in the GitHub Backlog Manager chat interface at any point during a backlog workflow. The memory agent creates a file at `.copilot-tracking/memory/YYYY-MM-DD/<description>-memory.md` containing: |
| 54 | |
| 55 | * Workflow state and current pipeline stage |
| 56 | * Completed operations and key decisions |
| 57 | * Next steps and pending handoff files |
| 58 | * Repository scope and filter criteria |
| 59 | |
| 60 | ### Resume a Session |
| 61 | |
| 62 | 1. Start a new chat and type `/clear` to ensure a clean context. |
| 63 | 2. Type `/checkpoint continue <description>` to restore the saved session. |
| 64 | 3. The memory agent displays restored workflow state and next steps. |
| 65 | 4. Click **🚀 Continue with Backlog** to return to the GitHub Backlog Manager and continue where you left off. |
| 66 | |
| 67 | > [!TIP] |
| 68 | > Save before each `/clear` between pipeline stages to preserve discovery or triage notes that are not captured in the planning artifacts. |
| 69 | |
| 70 | ## End-to-End Walkthrough |
| 71 | |
| 72 | This walkthrough covers a realistic pipeline run for a repository with accumulated issues that have not been reviewed. |
| 73 | |
| 74 | ### Step 1: Discover Issues |
| 75 | |
| 76 | Start with a scoped discovery pass: |
| 77 | |
| 78 | ```text |
| 79 | Discover all open issues in microsoft/hve-core that are unassigned |
| 80 | and don't have a milestone. Include issues labeled "needs-triage". |
| 81 | ``` |
| 82 | |
| 83 | Discovery produces analysis files in `.copilot-tracking/github-issues/discovery/hve-core/`. Review the issue analysis to confirm the scope is correct before proceeding. |
| 84 | |
| 85 | ### Step 2: Clear and Triage |
| 86 | |
| 87 | ```text |
| 88 | /clear |
| 89 | ``` |
| 90 | |
| 91 | Then start triage: |
| 92 | |
| 93 | ```text |
| 94 | Triage the issues from my latest discovery session for microsoft/hve-core. |
| 95 | Flag duplicates with confidence scores and suggest labels using the |
| 96 | standard taxonomy. |
| 97 | ``` |
| 98 | |
| 99 | Review the triage plan at `.copilot-tracking/github-issues/triage/<YYYY-MM-DD>/triage-plan.md`. Adjust any label suggestions or duplicate flags before continuing. |
| 100 | |
| 101 | ### Step 3: Clear and Plan |
| 102 | |
| 103 | ```text |
| 104 | /clear |
| 105 | ``` |
| 106 | |
| 107 | Then plan the sprint: |
| 108 | |
| 109 | ```text |
| 110 | Plan sprint assignments for microsoft/hve-core using the triage results. |
| 111 | Assign high-priority bugs to the v2.1 milestone and enhancements to v2.2. |
| 112 | ``` |
| 113 | |
| 114 | Review the sprint plan and handoff file. Adjust milestone assignments for any issues where the automatic mapping doesn't fit. |
| 115 | |
| 116 | ### Step 4: Clear and Execute |
| 117 | |
| 118 | ```text |
| 119 | /clear |
| 120 | ``` |
| 121 | |
| 122 | Then execute: |
| 123 | |
| 124 | ```text |
| 125 | Execute the sprint planning handoff for microsoft/hve-core. Apply all |
| 126 | checked operations in the handoff file. |
| 127 | ``` |
| 128 | |
| 129 | Check the execution log for any skipped operations or state conflicts. |
| 130 | |
| 131 | ### Step 5: Iterate |
| 132 | |
| 133 | Review the execution results. If new issues were discovered during the process, or if some operations were skipped due to conflicts, return to discovery or triage for another pass. |
| 134 | |
| 135 | ## Planning File Lifecycle |
| 136 | |
| 137 | Planning files move through three states during the pipeline: |
| 138 | |
| 139 | | State | Location | Created By | Consumed By | |
| 140 | |---------------|-------------------------------------------|-----------------|-------------| |
| 141 | | Analysis | `discovery/<scope>/issue-analysis.md` | Discovery | Triage | |
| 142 | | Triage Plan | `triage/<YYYY-MM-DD>/triage-plan.md` | Triage | Execution | |
| 143 | | Sprint Plan | `sprint/<milestone-kebab>/handoff.md` | Sprint Planning | Execution | |
| 144 | | Execution Log | `<planning-type>/<scope>/handoff-logs.md` | Execution | User review | |
| 145 | |
| 146 | Files are created once and updated in place. The execution workflow marks checkboxes in handoff files as it processes each operation, providing a built-in audit trail. |
| 147 | |
| 148 | ## Iteration Model |
| 149 | |
| 150 | Most backlogs require multiple passes through the pipeline. The iteration model supports this with three patterns: |
| 151 | |
| 152 | * Full cycle: Run all four workflows when starting a new sprint or onboarding a new repository |
| 153 | * Triage-execute: Skip sprint planning when applying label corrections or closing duplicates |
| 154 | * Discovery-only: Run discovery periodically to monitor for new issues without immediate action |
| 155 | |
| 156 | Each pass produces independent output files scoped by date and target, so previous results are preserved for comparison. |
| 157 | |
| 158 | ## Artifact Summary |
| 159 | |
| 160 | | Workflow | Input | Output | Key File | |
| 161 | |-----------------|------------------|---------------------------------------|---------------------| |
| 162 | | Discovery | Repository scope | Issue inventory and recommendations | `issue-analysis.md` | |
| 163 | | Triage | Discovery output | Label suggestions and duplicate flags | `triage-plan.md` | |
| 164 | | Sprint Planning | Triage output | Milestone assignments and sequencing | `handoff.md` | |
| 165 | | Execution | Handoff files | Applied changes and operation log | `handoff-logs.md` | |
| 166 | |
| 167 | ## Quick Reference |
| 168 | |
| 169 | | Task | Workflow | Prompt Example | |
| 170 | |-----------------------------|--------------------|--------------------------------------------------| |
| 171 | | Survey open issues | Discovery | "Discover open issues assigned to me" | |
| 172 | | Assign labels to new issues | Triage | "Triage issues from my latest discovery" | |
| 173 | | Find and close duplicates | Triage + Execution | "Check for duplicates and close confirmed ones" | |
| 174 | | Plan the next sprint | Sprint Planning | "Plan sprint assignments for the v2.1 milestone" | |
| 175 | | Apply all recommendations | Execution | "Execute the triage handoff" | |
| 176 | | Full backlog review | All four workflows | Run each in sequence with `/clear` between them | |
| 177 | |
| 178 | --- |
| 179 | |
| 180 | <!-- markdownlint-disable MD036 --> |
| 181 | *🤖 Crafted with precision by ✨Copilot following brilliant human instruction, |
| 182 | then carefully refined by our team of discerning human reviewers.* |
| 183 | <!-- markdownlint-enable MD036 --> |
| 184 | |