microsoft/hve-core
Publicmirrored fromhttps://github.com/microsoft/hve-coreAvailable
docs/agents/ado-backlog/execution.md
180lines · modecode
| 1 | --- |
| 2 | title: Execution Workflow |
| 3 | description: Apply triage and planning recommendations to Azure DevOps work items through structured handoff consumption |
| 4 | author: Microsoft |
| 5 | ms.date: 2026-02-26 |
| 6 | ms.topic: tutorial |
| 7 | keywords: |
| 8 | - azure devops backlog manager |
| 9 | - work item execution |
| 10 | - handoff |
| 11 | - github copilot |
| 12 | estimated_reading_time: 5 |
| 13 | sidebar_position: 7 |
| 14 | --- |
| 15 | |
| 16 | The Execution workflow consumes handoff files from triage, sprint planning, and PRD planning, applying approved changes to Azure DevOps work items. It tracks progress through checkbox-based handoff logs and produces operation reports for audit and recovery. |
| 17 | |
| 18 | ## When to Use |
| 19 | |
| 20 | * ✅ Triage, sprint planning, or PRD planning handoff files are ready for application |
| 21 | * 🏷️ Applying field changes, iteration assignments, or state transitions in bulk |
| 22 | * 🔗 Creating work item hierarchies with parent-child links |
| 23 | * 📝 Updating work item metadata across multiple items in a single session |
| 24 | |
| 25 | ## What It Does |
| 26 | |
| 27 | 1. Reads handoff files from upstream workflows (triage, sprint planning, PRD planning) |
| 28 | 2. Validates each recommended operation against current work item state |
| 29 | 3. Applies content sanitization to strip internal tracking references before API calls |
| 30 | 4. Applies approved changes (field assignments, state transitions, comments) via ADO MCP tools |
| 31 | 5. Marks each handoff checkbox as complete after successful application |
| 32 | 6. Produces an operation log documenting what changed and what was skipped |
| 33 | |
| 34 | > [!NOTE] |
| 35 | > Execution only processes checked items in the handoff file. Uncheck any recommendation you want to skip before starting the execution workflow. |
| 36 | |
| 37 | ## Content Sanitization |
| 38 | |
| 39 | Before any ADO API call, the execution workflow strips internal tracking references: |
| 40 | |
| 41 | * `.copilot-tracking/` file paths are removed from outbound content |
| 42 | * Planning reference IDs (such as `WI[NNN]` or `WI-SEC-{NNN}`) and template ID placeholders (such as `{{TEMP-N}}`) are stripped from descriptions and comments |
| 43 | * Internal planning metadata never reaches Azure DevOps work item fields |
| 44 | |
| 45 | This sanitization ensures clean, professional work item content regardless of the planning artifacts used during earlier phases. |
| 46 | |
| 47 | ## Content Format Detection |
| 48 | |
| 49 | The execution workflow automatically selects the correct template format for your Azure DevOps environment: |
| 50 | |
| 51 | | Environment | Format | Templates Used | |
| 52 | |-----------------------|----------|----------------------------------------------| |
| 53 | | Azure DevOps Services | Markdown | Markdown variants from interaction templates | |
| 54 | | Azure DevOps Server | HTML | HTML variants from interaction templates | |
| 55 | |
| 56 | Format detection happens automatically based on your MCP server URL. No manual configuration is required. |
| 57 | |
| 58 | ## Handoff Consumption |
| 59 | |
| 60 | The execution workflow uses checkbox-based progress tracking in handoff files: |
| 61 | |
| 62 | ```markdown |
| 63 | ## Pending Operations |
| 64 | |
| 65 | - [x] WI 42 - Assign Area Path: Components/Auth (applied) |
| 66 | - [x] WI 42 - Set Priority: 1 (applied) |
| 67 | - [ ] WI 57 - Change State: New → Active (skipped - unchecked) |
| 68 | - [x] WI 63 - Add Tags: security, api (applied) |
| 69 | ``` |
| 70 | |
| 71 | Each line represents one atomic operation. The workflow processes checked items sequentially, validating current work item state before each change. If a work item has been modified since triage (fields changed, state transitioned), the workflow flags the conflict and skips that operation rather than overwriting recent changes. |
| 72 | |
| 73 | ## Operation Logging |
| 74 | |
| 75 | Every execution session produces a structured log: |
| 76 | |
| 77 | * Operations attempted with timestamps |
| 78 | * Success and failure counts with error details |
| 79 | * Work items skipped due to state conflicts |
| 80 | * Remaining unprocessed items for recovery |
| 81 | |
| 82 | This log supports recovery when execution is interrupted. Re-running execution on the same handoff file picks up where it left off because completed items are already checked. |
| 83 | |
| 84 | ## Output Artifacts |
| 85 | |
| 86 | ```text |
| 87 | .copilot-tracking/workitems/execution/<YYYY-MM-DD>/ |
| 88 | └── handoff-logs.md # Per-operation processing status |
| 89 | ``` |
| 90 | |
| 91 | The consumed handoff file is updated in place as operations complete, marking checkboxes for processed items. The handoff log records per-operation results with processing status, supporting recovery when execution is interrupted. |
| 92 | |
| 93 | ## How to Use |
| 94 | |
| 95 | ### Option 1: Prompt Shortcut |
| 96 | |
| 97 | ```text |
| 98 | Execute the triage handoff for my Azure DevOps project |
| 99 | ``` |
| 100 | |
| 101 | ```text |
| 102 | Apply sprint planning assignments from my latest planning session |
| 103 | ``` |
| 104 | |
| 105 | ### Option 2: Handoff Button |
| 106 | |
| 107 | Click the "Execute" handoff button in the ADO Backlog Manager agent after completing triage or sprint planning. The agent reads the pending operations and begins processing checked items. |
| 108 | |
| 109 | ### Option 3: Direct Agent |
| 110 | |
| 111 | Reference the handoff file when starting an execution conversation: |
| 112 | |
| 113 | ```text |
| 114 | Execute the handoff at .copilot-tracking/workitems/triage/2026-02-26/work-items.md |
| 115 | ``` |
| 116 | |
| 117 | ## Example Prompts |
| 118 | |
| 119 | Execute a triage handoff by file reference: |
| 120 | |
| 121 | ```text |
| 122 | Execute the handoff at |
| 123 | .copilot-tracking/workitems/triage/2026-02-26/work-items.md |
| 124 | Apply all checked operations. Write an operation log so I can verify |
| 125 | what changed. |
| 126 | ``` |
| 127 | |
| 128 | Execute sprint planning assignments with safety filters: |
| 129 | |
| 130 | ```text |
| 131 | Execute the sprint planning handoff. Apply all checked operations and |
| 132 | skip any work items that have been modified in the last 24 hours. Use |
| 133 | partial autonomy so I can approve field changes before they are written. |
| 134 | ``` |
| 135 | |
| 136 | Selective execution of specific operation types: |
| 137 | |
| 138 | ```text |
| 139 | Execute only the Area Path assignments from the triage handoff. Skip |
| 140 | priority changes and duplicate resolution for now. Log any items that |
| 141 | were skipped because of field conflicts. |
| 142 | ``` |
| 143 | |
| 144 | **Output artifacts:** Execution writes an operation log to `.copilot-tracking/workitems/` recording each applied change, skipped items, and conflicts. Review the log for any unexpected skips or field conflict warnings. |
| 145 | |
| 146 | ## Tips |
| 147 | |
| 148 | * ✅ Review handoff files before execution and uncheck operations you want to skip |
| 149 | * ✅ Run execution in a clean session (use `/clear` after triage or planning) |
| 150 | * ✅ Check the operation log after execution to verify all changes applied correctly |
| 151 | * ✅ Re-run execution if interrupted; completed checkboxes prevent duplicate operations |
| 152 | * ❌ Do not execute handoffs without reviewing the recommendations first |
| 153 | * ❌ Do not modify the checkbox format in handoff files (the workflow depends on the `- [ ]` / `- [x]` syntax) |
| 154 | * ❌ Do not run execution while other team members are actively editing the same work items |
| 155 | * ❌ Do not combine triage and planning handoffs in a single execution session |
| 156 | |
| 157 | ## Common Pitfalls |
| 158 | |
| 159 | | Pitfall | Solution | |
| 160 | |--------------------------------------|--------------------------------------------------------------------------| |
| 161 | | Autonomy level mismatches | Set the expected autonomy level before execution (full, partial, manual) | |
| 162 | | Stale handoff data | Re-run discovery and triage if the handoff is more than a few days old | |
| 163 | | Partial execution after interruption | Re-run execution on the same handoff; completed items are skipped | |
| 164 | | Content sanitization gaps | Verify internal references are stripped by checking the operation log | |
| 165 | | Wrong content format | Confirm MCP server URL matches your ADO environment (Services vs Server) | |
| 166 | |
| 167 | ## Next Steps |
| 168 | |
| 169 | 1. Review the execution log for any skipped operations or conflicts |
| 170 | 2. See [Using Workflows Together](using-together.md) for iterating through the full pipeline after execution |
| 171 | |
| 172 | > [!TIP] |
| 173 | > For large handoffs with many operations, consider executing in batches by checking only a subset of items at a time. This makes review easier and reduces the blast radius of any unexpected changes. |
| 174 | |
| 175 | --- |
| 176 | |
| 177 | <!-- markdownlint-disable MD036 --> |
| 178 | *🤖 Crafted with precision by ✨Copilot following brilliant human instruction, |
| 179 | then carefully refined by our team of discerning human reviewers.* |
| 180 | <!-- markdownlint-enable MD036 --> |
| 181 | |