microsoft/hve-core
Publicmirrored fromhttps://github.com/microsoft/hve-coreAvailable
.github/prompts/github/github-execute-backlog.prompt.md
77lines · modecode
| 1 | --- |
| 2 | description: 'Execute a GitHub backlog plan by creating, updating, linking, closing, and commenting on issues from a handoff file' |
| 3 | agent: GitHub Backlog Manager |
| 4 | argument-hint: "handoff=... [autonomy={full|partial|manual}] [dryRun={true|false}]" |
| 5 | --- |
| 6 | |
| 7 | # Execute GitHub Backlog Plan |
| 8 | |
| 9 | Process a handoff plan file to execute planned issue operations against the GitHub API. The workflow initializes (or resumes) execution state, processes operations in hierarchy order, and produces a completion report with issue numbers. |
| 10 | |
| 11 | Follow all instructions from #file:../../instructions/github/github-backlog-update.instructions.md while executing this workflow. |
| 12 | Follow all instructions from #file:../../instructions/github/github-backlog-planning.instructions.md for shared conventions. |
| 13 | |
| 14 | ## Inputs |
| 15 | |
| 16 | * `${input:handoff}`: (Required) Path to the handoff plan file (handoff.md or triage-plan.md). |
| 17 | * `${input:autonomy:partial}`: (Optional, defaults to partial) Autonomy tier controlling confirmation gates. Values: `full`, `partial`, `manual`. |
| 18 | * `${input:dryRun:false}`: (Optional, defaults to false) When true, simulate all operations without modifying state. |
| 19 | |
| 20 | ## Required Steps |
| 21 | |
| 22 | The workflow proceeds through three steps: initialize or resume execution state, process operations in fixed hierarchy order, then finalize and present a completion report. |
| 23 | |
| 24 | ### Step 1: Initialize or Resume |
| 25 | |
| 26 | Establish execution context and determine whether this is a new run or a resumption. |
| 27 | |
| 28 | 1. Call `mcp_github_get_me` to verify repository access and determine the authenticated user. |
| 29 | 2. Read the handoff plan from `${input:handoff}`. When the file is not found, ask the user for the correct path before continuing. |
| 30 | 3. Resolve the repository owner and name from the handoff file header or the active workspace context. |
| 31 | 4. Call `mcp_github_list_issue_types` with the owner parameter to determine whether the repository supports issue types and confirm valid type values before processing. |
| 32 | 5. Check whether handoff-logs.md already exists next to `${input:handoff}`: |
| 33 | * When it exists, rebuild the `{{TEMP-N}}` mapping from completed Create entries and resume from the first unchecked operation per the Initialize or Resume instructions in the update instructions. |
| 34 | * When it does not exist, create handoff-logs.md using the template from the planning specification and populate it from the handoff file. |
| 35 | 6. Validate the handoff per the validation checks in the update instructions. Skip `{{TEMP-N}}` placeholders during numeric reference validation since those issues do not exist yet. Abort on critical failures (missing repository, authentication error); warn and continue on non-critical failures (invalid label, unknown milestone). |
| 36 | 7. Present an execution summary to the user for confirmation before proceeding. |
| 37 | |
| 38 | ### Step 2: Process Operations |
| 39 | |
| 40 | Execute operations in the fixed order defined by the update instructions: Create (parents first, then children), Update, Link, Close, Comment. |
| 41 | |
| 42 | 1. Process each operation category in sequence, following the Supported Operations table and checkpoint protocol in the update instructions. |
| 43 | 2. After each Create, resolve the corresponding `{{TEMP-N}}` placeholder to the actual issue number and record the mapping in handoff-logs.md. |
| 44 | 3. Apply confirmation gates per the Three-Tier Autonomy Model in the planning specification based on `${input:autonomy}`. When the user declines a gated operation, mark it as `Skipped` in handoff-logs.md and continue. |
| 45 | 4. When `${input:dryRun}` is true, simulate operations per the Dry Run Mode section of the update instructions without executing state-modifying calls. |
| 46 | 5. Update checkboxes in the handoff file and append entries to handoff-logs.md after each operation per the checkpoint protocol. On failure, log the error and continue processing remaining operations. |
| 47 | |
| 48 | ### Step 3: Finalize and Report |
| 49 | |
| 50 | Verify results and present a completion report. |
| 51 | |
| 52 | 1. Re-read handoff-logs.md and compare against the original handoff plan. |
| 53 | 2. Process any missed operations that were blocked by dependency failures and have since been unblocked. Limit this retry pass to one additional iteration per the finalization instructions. |
| 54 | 3. Cross-check that all `{{TEMP-N}}` placeholders resolved to actual issue numbers. |
| 55 | 4. Generate a completion summary with counts for issues created, updated, linked, closed, failed, and skipped. Present the summary with issue numbers. |
| 56 | 5. When failures occurred, list each failed operation with its error message and suggest corrective actions. |
| 57 | |
| 58 | ## Success Criteria |
| 59 | |
| 60 | * All planned operations from the handoff file are executed or logged with a final status in handoff-logs.md. |
| 61 | * All `{{TEMP-N}}` placeholders are resolved to actual issue numbers or logged as failed. |
| 62 | * handoff-logs.md next to `${input:handoff}` contains an entry for every operation. |
| 63 | * A completion report with issue numbers has been presented to the user. |
| 64 | |
| 65 | ## Error Handling |
| 66 | |
| 67 | * Handoff file not found: ask the user for the correct path rather than failing silently. |
| 68 | * Authentication or permission error (401/403): abort processing and notify the user. |
| 69 | * Rate limit (429): pause and retry with exponential backoff per the error handling in the update instructions. |
| 70 | * Invalid issue references: skip the operation, log a warning in handoff-logs.md, and continue per the error handling in the update instructions. |
| 71 | * Missing parent for sub-issue link: defer the link operation and revisit during the Step 3 retry pass per the dependency resolution in the update instructions. |
| 72 | * API or transient failures: log the error, continue with remaining operations, and report all failures in the final summary per the error handling in the update instructions. |
| 73 | * Context summarization: when conversation history is compressed, recover state from handoff-logs.md per the State Persistence Protocol in the planning specification before continuing. |
| 74 | |
| 75 | --- |
| 76 | |
| 77 | Proceed with executing the backlog plan from `${input:handoff}` following the Required Steps. |
| 78 | |