microsoft/hve-core
Publicmirrored fromhttps://github.com/microsoft/hve-coreAvailable
.github/instructions/github/github-backlog-planning.instructions.md
852lines · modecode
| 1 | --- |
| 2 | description: 'Reference specification for GitHub backlog management tooling - planning files, search protocols, similarity assessment, and state persistence' |
| 3 | applyTo: '**/.copilot-tracking/github-issues/**' |
| 4 | --- |
| 5 | |
| 6 | # GitHub Backlog Planning File Instructions |
| 7 | |
| 8 | ## Purpose and Scope |
| 9 | |
| 10 | Templates, field conventions, search protocols, and state persistence for GitHub backlog planning files. Workflow files must consume this specification by including a cross-reference at the top of their content. |
| 11 | |
| 12 | Cross-reference pattern for consuming files: |
| 13 | |
| 14 | ```markdown |
| 15 | Follow all instructions from #file:./github-backlog-planning.instructions.md while executing this workflow. |
| 16 | ``` |
| 17 | |
| 18 | Inline reference pattern when citing specific sections: |
| 19 | |
| 20 | ```markdown |
| 21 | per templates in #file:./github-backlog-planning.instructions.md |
| 22 | using the matrix from #file:./github-backlog-planning.instructions.md |
| 23 | ``` |
| 24 | |
| 25 | ## GitHub MCP Tool Catalog |
| 26 | |
| 27 | Issue operations reference these MCP GitHub tools. |
| 28 | |
| 29 | ### Discovery and Retrieval |
| 30 | |
| 31 | * `mcp_github_get_me`: Get authenticated user details. Agents should call this before operations requiring current user context. Key params: none. |
| 32 | * `mcp_github_list_issues`: List issues with filtering. Does not accept milestone or assignee filters; agents must use `mcp_github_search_issues` for those. Key params: `owner`, `repo`, `state`, `labels`, `since`, `direction`, `orderBy`, `perPage`, `after`. |
| 33 | * `mcp_github_search_issues`: Search issues with GitHub search syntax. Key params: `query` (required), `owner`, `repo`, `sort`, `order`, `perPage`, `page`. |
| 34 | * `mcp_github_issue_read`: Read issue details with multiple retrieval methods. Key params: `method` (required, one of: `get`, `get_comments`, `get_sub_issues`, `get_labels`), `owner`, `repo`, `issue_number`. |
| 35 | * `mcp_github_list_issue_types`: List supported issue types for an organization. Agents must call this before using the `type` param on `mcp_github_issue_write`. Key params: `owner`. |
| 36 | * `mcp_github_get_label`: Get label details for a repository. Key params: `owner`, `repo`, `name`. |
| 37 | |
| 38 | ### Creation and Updates |
| 39 | |
| 40 | * `mcp_github_issue_write`: Create or update issues. Key params: `method` (required, one of: `create`, `update`), `owner`, `repo`, `title`, `body`, `labels`, `assignees`, `milestone`, `state`, `state_reason`, `type`, `duplicate_of`, `issue_number` (required for update). |
| 41 | * `mcp_github_add_issue_comment`: Add a comment to an issue or pull request. For community-facing comments, follow templates in the Community Communication section. Key params: `owner`, `repo`, `issue_number`, `body`. |
| 42 | * `mcp_github_assign_copilot_to_issue`: Assign Copilot coding agent to an issue. Key params: `owner`, `repo`, `issue_number`, `base_ref`, `custom_instructions`. |
| 43 | |
| 44 | ### Relationships |
| 45 | |
| 46 | * `mcp_github_sub_issue_write`: Manage sub-issue relationships. Key params: `method` (required, one of: `add`, `remove`, `reprioritize`), `owner`, `repo`, `issue_number`, `sub_issue_id`, `after_id`, `before_id`. |
| 47 | |
| 48 | ### Project Management |
| 49 | |
| 50 | * `mcp_github_search_pull_requests`: Search pull requests with GitHub search syntax. Key params: `query` (required), `owner`, `repo`, `sort`, `order`, `perPage`, `page`. |
| 51 | * `mcp_github_list_pull_requests`: List pull requests with filtering. Key params: `owner`, `repo`, `state`, `head`, `base`, `sort`, `direction`, `perPage`, `page`. |
| 52 | * `mcp_github_update_pull_request`: Update pull request metadata (title, body, state, base branch, reviewers, draft status). Does not support milestone, label, or assignee changes. Key params: `owner`, `repo`, `pullNumber`, `title`, `body`, `state`, `base`, `draft`, `reviewers`, `maintainer_can_modify`. |
| 53 | |
| 54 | ### Pull Request Field Operations |
| 55 | |
| 56 | GitHub treats pull requests as a superset of issues sharing the same number space. The Issues API can read and write fields on pull requests that the Pull Requests API does not expose, including milestones, labels, and assignees. |
| 57 | |
| 58 | To set a milestone, labels, or assignees on a pull request, call `mcp_github_issue_write` with `method: 'update'` and pass the PR number as `issue_number`. The `mcp_github_update_pull_request` tool cannot set these fields. |
| 59 | |
| 60 | Common PR field operations via the Issues API: |
| 61 | |
| 62 | | Operation | Tool | Method | Key Fields | |
| 63 | |-------------------|--------------------------------|----------|--------------------------------------------| |
| 64 | | Set PR Milestone | `mcp_github_issue_write` | `update` | owner, repo, issue_number (PR#), milestone | |
| 65 | | Set PR Labels | `mcp_github_issue_write` | `update` | owner, repo, issue_number (PR#), labels | |
| 66 | | Set PR Assignees | `mcp_github_issue_write` | `update` | owner, repo, issue_number (PR#), assignees | |
| 67 | | Add Comment to PR | `mcp_github_add_issue_comment` | N/A | owner, repo, issue_number (PR#), body | |
| 68 | |
| 69 | > [!IMPORTANT] |
| 70 | > When setting milestones or labels on pull requests, always use `mcp_github_issue_write` with the PR number as `issue_number`. The `mcp_github_update_pull_request` tool does not accept milestone, label, or assignee parameters. |
| 71 | |
| 72 | ### Community Communication |
| 73 | |
| 74 | When an operation produces a comment visible to external contributors, the comment body follows scenario templates from `community-interaction.instructions.md`. This applies to closure messages, information requests, acknowledgments, and redirects. |
| 75 | |
| 76 | | Operation | Scenario | Template Guidance | |
| 77 | |-----------------|------------------------------------------------------|--------------------------------------| |
| 78 | | Close duplicate | Scenario 7: Closing a Duplicate Issue | Duplicate closure with original link | |
| 79 | | Close completed | Scenario 8: Closing a Completed Issue | Summary of resolution with thanks | |
| 80 | | Close won't-fix | Scenario 9: Closing a Won't-Fix Issue | Rationale with appreciation | |
| 81 | | Close stale | Scenario 10: Closing a Stale Issue | Neutral with reopen path | |
| 82 | | Request info | Scenario 14: Requesting More Information on an Issue | Specific questions with timeline | |
| 83 | |
| 84 | Apply the comment-before-closure pattern: call `mcp_github_add_issue_comment` with the appropriate scenario template before any state-changing call such as `mcp_github_issue_write` with closure. This ordering ensures contributors see the explanation before the issue closes. |
| 85 | |
| 86 | Internal-only operations (label changes, milestone assignment, sub-issue linking) that produce no visible comment do not require community interaction templates. |
| 87 | |
| 88 | ## Planning File Definitions and Directory Conventions |
| 89 | |
| 90 | Root planning workspace structure: |
| 91 | |
| 92 | ```text |
| 93 | .copilot-tracking/ |
| 94 | github-issues/ |
| 95 | <planning-type>/ |
| 96 | <scope-name>/ |
| 97 | issue-analysis.md |
| 98 | issues-plan.md |
| 99 | planning-log.md |
| 100 | handoff.md |
| 101 | handoff-logs.md |
| 102 | ``` |
| 103 | |
| 104 | Valid `<planning-type>` values: |
| 105 | |
| 106 | * `discovery`: Issue discovery from artifacts, PRDs, or user requests |
| 107 | * `triage`: Issue triage, label assignment, and duplicate detection |
| 108 | * `sprint`: Sprint planning and milestone organization |
| 109 | * `backlog`: Backlog refinement and prioritization |
| 110 | * `execution`: Issue creation, update, and closure from finalized plans |
| 111 | |
| 112 | Normalization rules for `<scope-name>`: |
| 113 | |
| 114 | * Use lower-case, hyphenated form without extension (for example, `docs/Customer Onboarding PRD.md` becomes `docs--customer-onboarding-prd`). |
| 115 | * Replace spaces and punctuation with hyphens. |
| 116 | * Choose the primary artifact when multiple artifacts and documents are provided. |
| 117 | * For triage scopes, use the date as the scope name (for example, `2026-02-05`). |
| 118 | * For sprint scopes, use the milestone name (for example, `v2-2-0`). |
| 119 | |
| 120 | ## Planning File Requirements |
| 121 | |
| 122 | Planning markdown files must start with: |
| 123 | |
| 124 | ```markdown |
| 125 | <!-- markdownlint-disable-file --> |
| 126 | <!-- markdown-table-prettify-ignore-start --> |
| 127 | ``` |
| 128 | |
| 129 | Planning markdown files must end with (before the final newline): |
| 130 | |
| 131 | ```markdown |
| 132 | <!-- markdown-table-prettify-ignore-end --> |
| 133 | ``` |
| 134 | |
| 135 | ## Planning File Templates |
| 136 | |
| 137 | ### issue-analysis.md |
| 138 | |
| 139 | Agents must create issue-analysis.md when beginning issue discovery from PRDs, user requests, or codebase artifacts. This file captures the human-readable analysis of planned issue operations before finalizing in issues-plan.md. |
| 140 | |
| 141 | Agents should populate sections by extracting requirements from referenced artifacts, searching GitHub for related issues, and incorporating user feedback. Agents should update the file iteratively as discovery progresses. |
| 142 | |
| 143 | Found Issue Field Values records the current state retrieved from GitHub for existing issues. Suggested Issue Field Values records all fields as they should appear after the planned operation. When creating a new issue, Found Issue Field Values should be omitted. |
| 144 | |
| 145 | #### Template |
| 146 | |
| 147 | ````markdown |
| 148 | # [Planning Type] Issue Analysis - [Summarized Title] |
| 149 | |
| 150 | * **Artifact(s)**: [e.g., relative/path/to/artifact-a.md, relative/path/to/artifact-b.md] |
| 151 | * [(Optional) Inline Artifacts (e.g., User provided the following: [markdown block follows])] |
| 152 | * **Repository**: [owner/repo] |
| 153 | * **Milestone**: [(Optional) Milestone name] |
| 154 | |
| 155 | ## Planned Issues |
| 156 | |
| 157 | ### IS[Reference Number (e.g., 001)] - [one of, Create|Update|Link|Close|No Change] - [Summarized Issue Title] |
| 158 | |
| 159 | * **Working Title**: [Single line value (e.g., feat(agents): add batch triage support)] |
| 160 | * **Working Type**: [(Optional) Issue type if org supports issue types] |
| 161 | * **Key Search Terms**: [Keyword groups (e.g., "batch triage", "label automation", "needs-triage")] |
| 162 | * **Working Description**: |
| 163 | ```markdown |
| 164 | [Evolving description content constructed from artifacts and discovery] |
| 165 | ``` |
| 166 | * **Working Labels**: [Comma-separated labels (e.g., feature, agents)] |
| 167 | * **Working Milestone**: [(Optional) Milestone name (e.g., v2.2.0)] |
| 168 | * **Found Issue Field Values**: |
| 169 | * [Field (e.g., state)]: [Value (e.g., open)] |
| 170 | * [Field (e.g., labels)]: [Value (e.g., bug, needs-triage)] |
| 171 | * **Suggested Issue Field Values**: |
| 172 | * [Field (e.g., labels)]: [Value (e.g., feature, agents)] |
| 173 | * [Field (e.g., milestone)]: [Value (e.g., v2.2.0)] |
| 174 | |
| 175 | #### IS[Reference Number] - Related and Discovered Information |
| 176 | |
| 177 | * [(Optional) zero or more Requirements blocks (e.g., Related Requirements from relative/path/to/artifact-a.md)] |
| 178 | * [(Optional) one or more requirement line items (e.g., REQ-001: details of requirement)] |
| 179 | * [one or more Key Details blocks (e.g., Related Key Details from relative/path/to/artifact-b.md)] |
| 180 | * [one or more key detail line items (e.g., `Section 2.3` references dependency on data ingestion workflow)] |
| 181 | * [(Optional) zero or more Related Codebase blocks (e.g., Related Codebase Items Mentioned from User)] |
| 182 | * [(Optional) one or more related codebase line items (e.g., src/components/example.ts: update with related functionality)] |
| 183 | ```` |
| 184 | |
| 185 | ### issues-plan.md |
| 186 | |
| 187 | issues-plan.md is the source of truth for planned issue operations. Agents must capture the current `state` for every referenced issue, highlighting `closed` items. When a closed issue satisfies the requirement without updates, agents should keep the action as `No Change` and note the relationship. |
| 188 | |
| 189 | #### Template |
| 190 | |
| 191 | ````markdown |
| 192 | # Issues Plan |
| 193 | |
| 194 | * **Repository**: [owner/repo] |
| 195 | * **Milestone**: [(Optional) Milestone name] |
| 196 | |
| 197 | ## IS[Reference Number (e.g., 002)] - [Action (one of, Create|Update|Link|Close|No Change)] - [Summarized Title] |
| 198 | |
| 199 | [1-5 Sentence Explanation of Change (e.g., Adding issue for batch triage support called out in Section 2.3 of the referenced document)] |
| 200 | |
| 201 | [IS[Reference Number] - Similarity: [#issue_number=Category (e.g., #42=Similar, #38=Match, #55=Distinct)]] |
| 202 | |
| 203 | * IS[Reference Number] - issue_number: [#number or {{TEMP-N}}] |
| 204 | * IS[Reference Number] - title: [Issue title] |
| 205 | * IS[Reference Number] - state: [open|closed] |
| 206 | * IS[Reference Number] - labels: [comma-separated labels] |
| 207 | * IS[Reference Number] - milestone: [milestone name or none] |
| 208 | * IS[Reference Number] - assignees: [comma-separated usernames or none] |
| 209 | |
| 210 | ### IS[Reference Number] - body |
| 211 | |
| 212 | ```markdown |
| 213 | [Issue body content] |
| 214 | ``` |
| 215 | |
| 216 | ### IS[Reference Number] - Relationships |
| 217 | |
| 218 | * IS[Reference Number] - [Relationship Type (e.g., sub-issue-of, parent-of, linked-pr)] - [Target (e.g., #42, {{TEMP-1}})]: [Single line reason] |
| 219 | ```` |
| 220 | |
| 221 | #### Example |
| 222 | |
| 223 | ````markdown |
| 224 | # Issues Plan |
| 225 | |
| 226 | * **Repository**: microsoft/hve-core |
| 227 | * **Milestone**: v2.2.0 |
| 228 | |
| 229 | ## IS002 - Update - Add batch label operations to triage workflow |
| 230 | |
| 231 | Updating existing issue to include batch label operations from Section 2.3. |
| 232 | |
| 233 | IS002 - Similarity: #38=Match, #55=Similar (titles align on triage workflow; #55 has broader scope) |
| 234 | |
| 235 | * IS002 - issue_number: #38 |
| 236 | * IS002 - title: feat(agents): add batch triage support |
| 237 | * IS002 - state: open |
| 238 | * IS002 - labels: feature, agents |
| 239 | * IS002 - milestone: v2.2.0 |
| 240 | * IS002 - assignees: WilliamBerryiii |
| 241 | |
| 242 | ### IS002 - body |
| 243 | |
| 244 | ```markdown |
| 245 | ## Summary |
| 246 | |
| 247 | Add batch label operations to the triage workflow agent. |
| 248 | |
| 249 | ## Acceptance Criteria |
| 250 | |
| 251 | * Batch apply labels to multiple issues in a single operation. |
| 252 | * Support undo of batch label changes. |
| 253 | ``` |
| 254 | |
| 255 | ### IS002 - Relationships |
| 256 | |
| 257 | * IS002 - sub-issue-of - #30: Triage workflow epic |
| 258 | ```` |
| 259 | |
| 260 | ### planning-log.md |
| 261 | |
| 262 | planning-log.md is a living document with sections that are routinely added, updated, extended, and removed in-place. |
| 263 | |
| 264 | Phase tracking applies when the consuming workflow file defines phases (see the workflow file's Required Phases section for phase definitions): |
| 265 | |
| 266 | * Agents must track all new, in-progress, and completed steps for each phase. |
| 267 | * Agents must update the Status section with in-progress review of completed and proposed steps. |
| 268 | * Agents must update Previous Phase when moving to any other phase (phases can repeat based on discovery needs). |
| 269 | * Agents must update Current Phase and Previous Phase when transitioning phases. |
| 270 | |
| 271 | #### Template |
| 272 | |
| 273 | ````markdown |
| 274 | # [Planning Type] - Issue Planning Log |
| 275 | |
| 276 | * **Repository**: [owner/repo] |
| 277 | * **Milestone**: [(Optional) Milestone name] |
| 278 | * **Previous Phase**: [(Optional) (e.g., Phase-1, Phase-2, N/A, Just Started)] |
| 279 | * **Current Phase**: [(e.g., Phase-1, Phase-2, N/A, Just Started)] |
| 280 | |
| 281 | ## Status |
| 282 | |
| 283 | [e.g., 3/10 issues searched, 1/5 docs reviewed, 2/8 issues planned] |
| 284 | |
| 285 | **Summary**: [e.g., Searching for existing issues based on keywords from PRD] |
| 286 | |
| 287 | ## Discovered Artifacts and Related Files |
| 288 | |
| 289 | * AT[Reference Number (e.g., 001)] [relative/path/to/file] - [one of, Not Started|In-Progress|Complete] - [Processing|Related|N/A] |
| 290 | |
| 291 | ## Discovered GitHub Issues |
| 292 | |
| 293 | * GH-[Issue Number (e.g., 42)] - [one of, Not Started|In-Progress|Complete] - [Processing|Related|N/A] |
| 294 | |
| 295 | ## Issue Progress |
| 296 | |
| 297 | ### **IS[Reference Number]** - [Label summary (e.g., feature, agents)] - [one of, In-Progress|Complete] |
| 298 | |
| 299 | * IS[Reference Number] - Issue Section (see issue-analysis.md) |
| 300 | * Working Search Keywords: [Working Keywords (e.g., "batch triage OR label automation")] |
| 301 | * Related GitHub Issues - Similarity: [#number=Category (Rationale) (e.g., #42=Similar (overlapping scope), #38=Match (same user goal))] |
| 302 | * Suggested Action: [one of, Create|Update|Link|Close|No Change] |
| 303 | |
| 304 | [Collected and Discovered Information] |
| 305 | |
| 306 | [Possible Issue Field Values] |
| 307 | |
| 308 | ## Doc Analysis - issue-analysis.md |
| 309 | |
| 310 | ### [relative/path/to/referenced/doc.ext] |
| 311 | |
| 312 | * IS[Reference Number] - Issue Section (see issue-analysis.md): [Summary of what was done] |
| 313 | |
| 314 | ## GitHub Issues |
| 315 | |
| 316 | ### GH-[Issue Number] |
| 317 | |
| 318 | [All content from mcp_github_issue_read method get] |
| 319 | ```` |
| 320 | |
| 321 | #### Field Value Example |
| 322 | |
| 323 | ````markdown |
| 324 | * Working `title`: feat(agents): add batch triage support |
| 325 | * Working `body`: |
| 326 | ```markdown |
| 327 | ## Summary |
| 328 | Add batch label operations to the triage workflow agent. |
| 329 | ``` |
| 330 | * Working `labels`: feature, agents |
| 331 | * Working `milestone`: v2.2.0 |
| 332 | ```` |
| 333 | |
| 334 | ### handoff.md |
| 335 | |
| 336 | Handoff file requirements: |
| 337 | |
| 338 | * Agents must include a reference to each issue defined in issues-plan.md. |
| 339 | * Agents must order entries with Create actions first, Update actions second, Link actions third, Close actions fourth, Comment actions fifth, and No Change entries last. |
| 340 | * Agents must include a markdown checkbox next to each issue with a summary. |
| 341 | * Agents must include project-relative paths to all planning files. |
| 342 | * Agents must update the Summary section whenever the Issues section changes. |
| 343 | |
| 344 | Checkbox state semantics for execution consumption: |
| 345 | |
| 346 | * `- [ ]` (unchecked): Pending operation. The execution stage must process this entry. |
| 347 | * `- [x]` (checked): Completed operation. The execution stage must skip this entry during resumed execution. |
| 348 | |
| 349 | This convention enables resumable execution. When an execution run is interrupted and restarted, the execution stage reads checkbox states to determine which operations remain pending. |
| 350 | |
| 351 | #### Template |
| 352 | |
| 353 | ```markdown |
| 354 | # GitHub Issue Operations Handoff |
| 355 | |
| 356 | ## Planning Files |
| 357 | |
| 358 | * .copilot-tracking/github-issues/<planning-type>/<scope-name>/issue-analysis.md |
| 359 | * .copilot-tracking/github-issues/<planning-type>/<scope-name>/issues-plan.md |
| 360 | * .copilot-tracking/github-issues/<planning-type>/<scope-name>/planning-log.md |
| 361 | * .copilot-tracking/github-issues/<planning-type>/<scope-name>/handoff.md |
| 362 | |
| 363 | ## Summary |
| 364 | |
| 365 | | Action | Count | |
| 366 | |-----------|---------------------| |
| 367 | | Create | {{create_count}} | |
| 368 | | Update | {{update_count}} | |
| 369 | | Link | {{link_count}} | |
| 370 | | Close | {{close_count}} | |
| 371 | | Comment | {{comment_count}} | |
| 372 | | No Change | {{no_change_count}} | |
| 373 | |
| 374 | ## Issues |
| 375 | |
| 376 | ### Create |
| 377 | |
| 378 | - [ ] {{title}} |
| 379 | - Labels: {{labels}}, Milestone: {{milestone}}, Assignee: {{assignee}} |
| 380 | - Body: {{summary}} |
| 381 | - Parent: #{{parent_issue_number}} (sub-issue link) |
| 382 | - Similarity: {{similarity_category}} to #{{existing_issue}}, {{rationale}} |
| 383 | |
| 384 | ### Update |
| 385 | |
| 386 | - [ ] #{{issue_number}}: {{title}} |
| 387 | - Action: {{update_action}} |
| 388 | - Changes: {{field_changes}} |
| 389 | - Rationale: {{reason}} |
| 390 | |
| 391 | ### Link (Sub-Issues) |
| 392 | |
| 393 | - [ ] Link #{{child}} as sub-issue of #{{parent}} |
| 394 | |
| 395 | ### Close |
| 396 | |
| 397 | - [ ] Close #{{issue_number}} |
| 398 | - Reason: {{state_reason}} (completed|not_planned|duplicate) |
| 399 | - Duplicate of: #{{duplicate_of}} (if applicable) |
| 400 | |
| 401 | ### Comment |
| 402 | |
| 403 | - [ ] Comment on #{{issue_number}} |
| 404 | - Body: {{comment_body}} |
| 405 | - Rationale: {{reason}} |
| 406 | |
| 407 | ### No Change |
| 408 | |
| 409 | - [ ] (No Change) #{{issue_number}}: {{title}} |
| 410 | - {{rationale}} |
| 411 | ``` |
| 412 | |
| 413 | ### handoff-logs.md |
| 414 | |
| 415 | handoff-logs.md records per-issue processing results during execution. The execution workflow must create this file and append entries as each operation completes. |
| 416 | |
| 417 | #### Template |
| 418 | |
| 419 | ```markdown |
| 420 | # GitHub Issue Operations Log |
| 421 | |
| 422 | ## Execution Summary |
| 423 | |
| 424 | | Metric | Value | |
| 425 | |-----------|---------------| |
| 426 | | Started | {{timestamp}} | |
| 427 | | Completed | {{timestamp}} | |
| 428 | | Succeeded | {{count}} | |
| 429 | | Failed | {{count}} | |
| 430 | | Skipped | {{count}} | |
| 431 | |
| 432 | ## Operations |
| 433 | |
| 434 | ### {{action}} - IS[Reference Number] - {{title}} |
| 435 | |
| 436 | * **Status**: [one of, Success|Failed|Skipped] |
| 437 | * **Issue Number**: #{{issue_number}} (or {{TEMP-N}} → #{{actual_number}}) |
| 438 | * **Action**: {{action}} |
| 439 | * **Details**: {{details}} |
| 440 | * **Error**: [(Optional) error message if failed] |
| 441 | * **Timestamp**: {{timestamp}} |
| 442 | ``` |
| 443 | |
| 444 | ## Search Protocol |
| 445 | |
| 446 | Goal: Deterministic, resumable discovery of existing GitHub issues. |
| 447 | |
| 448 | ### Step 1: Build Keyword Groups |
| 449 | |
| 450 | Agents must build an ordered list where each group contains 1-4 specific terms (multi-word phrases allowed) joined by spaces or OR-equivalent constructs. |
| 451 | |
| 452 | Example keyword groups for a batch triage feature: |
| 453 | |
| 454 | * Group 1: `"batch triage" OR "bulk triage"` |
| 455 | * Group 2: `"label automation" OR "auto-label"` |
| 456 | * Group 3: `"needs-triage" OR "untriaged"` |
| 457 | |
| 458 | ### Step 2: Compose GitHub Search Syntax |
| 459 | |
| 460 | Agents must format the `query` parameter for `mcp_github_search_issues`: |
| 461 | |
| 462 | ```text |
| 463 | # Issues by keyword |
| 464 | repo:owner/repo is:issue "search term" |
| 465 | |
| 466 | # Issues by milestone |
| 467 | repo:owner/repo is:issue milestone:"v2.2.0" is:open |
| 468 | |
| 469 | # Issues by label combination |
| 470 | repo:owner/repo is:issue label:needs-triage label:enhancement |
| 471 | |
| 472 | # Issues with no milestone |
| 473 | repo:owner/repo is:issue no:milestone is:open |
| 474 | |
| 475 | # Issues by assignee |
| 476 | repo:owner/repo is:issue assignee:username is:open |
| 477 | |
| 478 | # Cross-label search for triage |
| 479 | repo:owner/repo is:issue label:needs-triage -label:bug -label:enhancement |
| 480 | |
| 481 | # Text search within issue bodies |
| 482 | repo:owner/repo is:issue "acceptance criteria" in:body is:open |
| 483 | ``` |
| 484 | |
| 485 | ### Step 3: Execute Search and Paginate |
| 486 | |
| 487 | Agents must execute `mcp_github_search_issues` with the constructed query and paginate results using `perPage` (max 100) and `page` parameters. |
| 488 | |
| 489 | Agents must filter results to identify candidates for similarity assessment: |
| 490 | |
| 491 | * Search results must contain terms matching the planned issue's core concepts. |
| 492 | * Issue state must align with the query intent (open for active work, any for comprehensive search). |
| 493 | * Issue must not already be tracked in the planning log. |
| 494 | |
| 495 | ### Step 4: Hydrate Results |
| 496 | |
| 497 | For each candidate, agents must fetch full details using `mcp_github_issue_read` with method `get` and update planning-log.md under the Discovered GitHub Issues section. |
| 498 | |
| 499 | ### Step 5: Assess Similarity |
| 500 | |
| 501 | Agents must perform similarity assessment for each candidate (see the Similarity Assessment Framework section). |
| 502 | |
| 503 | ## Similarity Assessment Framework |
| 504 | |
| 505 | Analyze the relationship between a planned issue and each discovered issue through aspect-by-aspect comparison. |
| 506 | |
| 507 | ### Comparison Aspects |
| 508 | |
| 509 | 1. Compare titles to identify the core intent of each. Determine whether both describe the same goal or outcome. |
| 510 | 2. Compare body content to determine whether both address the same problem or user need. Note scope differences. |
| 511 | 3. Calculate label overlap between existing and proposed labels. High overlap is a strong signal of similarity. |
| 512 | 4. Evaluate whether both issues target the same milestone or release scope. |
| 513 | |
| 514 | When a field is absent from the discovered issue: |
| 515 | |
| 516 | * Missing body: Agents should use title and labels to infer scope and must apply the Uncertain category when insufficient information remains. |
| 517 | * Missing labels: Agents should compare against title and body content only. Labels carry less weight in the assessment. |
| 518 | * Different issue types: Evaluate whether the planned issue should become a sub-issue of the discovered issue. |
| 519 | |
| 520 | ### Similarity Categories |
| 521 | |
| 522 | | Category | Meaning | Action | |
| 523 | |-----------|------------------------------------------------------|----------------------------------| |
| 524 | | Match | Same issue; creating both would duplicate effort | Update existing issue | |
| 525 | | Similar | Related enough that consolidation may be appropriate | Review with user before deciding | |
| 526 | | Distinct | Different issues with minimal overlap | Create new issue | |
| 527 | | Uncertain | Insufficient information or conflicting signals | Request user guidance | |
| 528 | |
| 529 | ### Assessment Template |
| 530 | |
| 531 | For each comparison, record the assessment using this format: |
| 532 | |
| 533 | ```markdown |
| 534 | ### Issue Similarity Assessment |
| 535 | |
| 536 | | Aspect | Existing #{{number}} | Proposed Issue | Match Level | |
| 537 | |------------------|------------------------|------------------------|-----------------------------| |
| 538 | | Title | {{existing_title}} | {{proposed_title}} | {{High/Medium/Low/None}} | |
| 539 | | Body/Description | {{existing_summary}} | {{proposed_summary}} | {{High/Medium/Low/None}} | |
| 540 | | Labels | {{existing_labels}} | {{proposed_labels}} | {{overlap_count}}/{{total}} | |
| 541 | | Milestone | {{existing_milestone}} | {{proposed_milestone}} | {{Same/Different/None}} | |
| 542 | |
| 543 | **Category:** {{Match/Similar/Distinct/Uncertain}} |
| 544 | **Recommended Action:** {{Update existing/Create new/Needs review/Skip}} |
| 545 | **Rationale:** {{explanation}} |
| 546 | ``` |
| 547 | |
| 548 | ### Recording Similarity Assessments |
| 549 | |
| 550 | Record each assessment in planning-log.md under a Discovered GitHub Issues section with: |
| 551 | |
| 552 | * Issue number and title of the discovered issue |
| 553 | * Category assigned (Match, Similar, Distinct, or Uncertain) |
| 554 | * Brief rationale explaining the classification |
| 555 | * Recommended action based on the category |
| 556 | |
| 557 | Format: `GH-{number}: {Category} - {rationale}` |
| 558 | |
| 559 | Example: |
| 560 | |
| 561 | ```markdown |
| 562 | ## Discovered GitHub Issues |
| 563 | |
| 564 | * GH-42: Similar - Batch triage feature overlaps with label automation goals; scope is broader (full triage vs label-only) |
| 565 | * GH-55: Match - Same user goal for automated milestone assignment; existing issue covers planned scope |
| 566 | * GH-71: Distinct - Infrastructure CI pipeline is unrelated to triage workflow |
| 567 | ``` |
| 568 | |
| 569 | ## Human Review Triggers |
| 570 | |
| 571 | Agents must request user guidance when: |
| 572 | |
| 573 | * Either issue lacks a title or body |
| 574 | * Labels diverge significantly but titles align |
| 575 | * Cross-milestone items are discovered (planned issue targets one milestone, discovered issue targets another) |
| 576 | * Security-labeled issues are found (issues carrying `security` or `vulnerability` labels) |
| 577 | * Milestone-changing operations are proposed (moving an issue from one milestone to another) |
| 578 | * The relationship is genuinely ambiguous after analysis |
| 579 | * Similarity assessment yields Uncertain for more than two candidates against the same planned issue |
| 580 | * A planned Close action targets an issue with open sub-issues |
| 581 | |
| 582 | ## Label Taxonomy Reference |
| 583 | |
| 584 | The repository uses 17 labels organized by purpose. Labels influence milestone assignment through the milestone discovery protocol. |
| 585 | |
| 586 | | Label | Description | Target Role | |
| 587 | |--------------------|-------------------------------------------------------|--------------| |
| 588 | | `bug` | Something is not working; targets stable for fixes | stable | |
| 589 | | `feature` | New capability or functionality | pre-release | |
| 590 | | `enhancement` | Improvement to existing functionality | any | |
| 591 | | `documentation` | Improvements or additions to documentation | any | |
| 592 | | `maintenance` | Chores, refactoring, dependency updates | stable | |
| 593 | | `security` | Security vulnerability or hardening; may be expedited | stable | |
| 594 | | `breaking-change` | Incompatible API or behavior change; pre-release only | pre-release | |
| 595 | | `needs-triage` | Requires label and milestone assignment | unclassified | |
| 596 | | `duplicate` | This issue already exists; closed immediately | unclassified | |
| 597 | | `wontfix` | This will not be worked on; closed | unclassified | |
| 598 | | `good-first-issue` | Good for newcomers | any | |
| 599 | | `help-wanted` | Extra attention is needed | any | |
| 600 | | `question` | Further information is requested; informational only | unclassified | |
| 601 | | `agents` | Related to agent files | any | |
| 602 | | `prompts` | Related to prompt files | any | |
| 603 | | `instructions` | Related to instructions files | any | |
| 604 | | `infrastructure` | CI/CD, workflows, build tooling | stable | |
| 605 | |
| 606 | ### Label-to-Title Pattern Mapping |
| 607 | |
| 608 | When issue titles follow conventional commit format, agents should map patterns to labels: |
| 609 | |
| 610 | | Issue Title Pattern | Suggested Labels | |
| 611 | |-------------------------|-----------------------------| |
| 612 | | `feat(agents):` | feature, agents | |
| 613 | | `fix(scripts):` | bug | |
| 614 | | `chore(ci):` | maintenance, infrastructure | |
| 615 | | `refactor(workflows):` | maintenance | |
| 616 | | `docs(templates):` | documentation | |
| 617 | | No conventional pattern | needs-triage (retain) | |
| 618 | |
| 619 | ## Milestone Discovery Protocol |
| 620 | |
| 621 | Discover the repository's milestone strategy at runtime by analyzing open milestones. This protocol replaces static versioning assumptions with dynamic classification. |
| 622 | |
| 623 | ### Discovery Steps |
| 624 | |
| 625 | 1. Discover open milestones by sampling recent open issues. Call `mcp_github_search_issues` with `repo:{owner}/{repo} is:issue is:open` sorted by `updated` descending, retrieving up to 100 results. Extract the `milestone` object from each result and aggregate unique milestones by title. Collect available fields (title, description, due_on, state, open_issues, closed_issues) from the milestone objects. Sort discovered milestones by due date ascending (nearest first). This approach may not surface milestones with zero open issues; when comprehensive coverage is required, optionally read the repo-specific override file `.github/milestone-strategy.yml` if it exists. When the file is not present, rely solely on the discovered milestones. |
| 626 | 2. Detect the dominant naming pattern from milestone titles using the rules in Naming Pattern Detection. |
| 627 | 3. Classify each milestone into an abstract role (`stable`, `pre-release`, `current`, `next`, `backlog`, `any`, `unclassified`) using the signal weighting in Role Classification. The `any` role means the label does not constrain milestone selection. |
| 628 | 4. Build the assignment map linking issue characteristics to target roles using the Assignment Map. |
| 629 | 5. Record the detected naming pattern, per-milestone role classification, generated assignment map, and confidence level (high, medium, low) in planning-log.md. |
| 630 | 6. When confidence is low, optionally check for the repo-specific override file `.github/milestone-strategy.yml` in the repository. If the file exists, apply the declared strategy. If the file does not exist, treat its absence as expected, present the discovered milestones to the user and request classification. When no user input is available, assign `unclassified` and flag for human review. |
| 631 | |
| 632 | ### Naming Pattern Detection |
| 633 | |
| 634 | Evaluate milestone titles to identify the dominant naming pattern. A pattern is dominant when it matches more than 50% of open milestones. |
| 635 | |
| 636 | * SemVer: Titles match a major.minor.patch version pattern, optionally prefixed with `v` and optionally suffixed with a pre-release identifier (`-alpha`, `-beta`, `-rc`, `-preview`). |
| 637 | * CalVer: Titles match a year-period pattern such as `2025-Q1` or `2025-03`. |
| 638 | * Sprint: Titles match a sprint identifier such as `Sprint 12` or `sprint-12`. |
| 639 | * Feature: Titles contain descriptive names without version or date patterns. |
| 640 | * Mixed or unknown: No single pattern covers more than 50% of open milestones. Set confidence to low and proceed to the fallback in step 6. |
| 641 | |
| 642 | ### Role Classification |
| 643 | |
| 644 | Classify each milestone into two orthogonal abstract roles using these signals in precedence order: one stability role and one proximity role. |
| 645 | |
| 646 | 1. Explicit pre-release suffix in the title (`-beta`, `-rc`, `-preview`, `-alpha`): assign `pre-release` stability role. Highest signal. |
| 647 | 2. Description keywords: `stable`, `release`, `production`, `GA`, `LTS` suggest `stable` stability role. `pre-release`, `preview`, `beta`, `RC`, `experimental`, `development`, `canary`, `nightly` suggest `pre-release` stability role. Strong signal. |
| 648 | 3. Version number parity (SemVer only): even minor version suggests `stable`, odd minor version suggests `pre-release`. Weak signal, used when stronger stability signals are absent. |
| 649 | 4. Due date proximity (tiebreaker for proximity only): use date ordering only to choose between `current`, `next`, and `backlog` proximity roles. The nearest future due date with open issues is `current`, the second-nearest is `next`, and remaining milestones (including those without due dates) are `backlog`. Do not use due dates to distinguish `stable` versus `pre-release`; that distinction comes only from signals 1–3. |
| 650 | |
| 651 | For CalVer, sprint, and feature naming patterns, apply the same date-based rule for proximity roles: nearest due date is `current`, second-nearest is `next`, and milestones without due dates or with distant due dates are `backlog`. |
| 652 | |
| 653 | ### Assignment Map |
| 654 | |
| 655 | Map issue characteristics to target milestone roles after completing the discovery steps. Each entry specifies a stability target and a proximity target independently. |
| 656 | |
| 657 | | Issue Characteristic | Stability Target | Proximity Target | |
| 658 | |-----------------------------|------------------|------------------| |
| 659 | | Bug fix (production) | stable | current | |
| 660 | | Security vulnerability | stable | current | |
| 661 | | Maintenance and refactoring | stable | current | |
| 662 | | Documentation improvement | stable | current | |
| 663 | | New feature | pre-release | next | |
| 664 | | Breaking change | pre-release | next | |
| 665 | | Experimental capability | pre-release | next | |
| 666 | | Infrastructure improvement | stable | current | |
| 667 | | Low-risk enhancement | stable | current | |
| 668 | | High-risk enhancement | pre-release | next | |
| 669 | |
| 670 | Resolve milestone selection deterministically using these targets: |
| 671 | |
| 672 | * First, prefer milestones that match both the stability target and the proximity target. Among these, choose the nearest by due date. |
| 673 | * If no milestone matches both targets, relax stability and prefer any milestone with the target proximity. Among these, choose the nearest by due date. |
| 674 | * If neither the combined target nor the proximity target can be satisfied (for example, in very sparse backlogs), choose the nearest suitable milestone by due date regardless of stability or proximity and document the rationale in the planning notes. |
| 675 | |
| 676 | Security vulnerabilities follow the same resolution logic but are escalated in priority: they skip lower-priority work in the target milestone and ship in the earliest available release. |
| 677 | |
| 678 | When uncertain about milestone assignment, or when no milestone clearly matches these rules, default to the nearest pre-release or next milestone and flag for human review. |
| 679 | ## Issue Field Matrix |
| 680 | |
| 681 | Track field usage explicitly so downstream automation can rely on consistent data. The matrix defines required and optional fields per operation type. These field requirements apply to both issues and pull requests. When targeting a pull request, pass the PR number as `issue_number` (see the Pull Request Field Operations section in the MCP Tool Catalog). |
| 682 | |
| 683 | | Field | Create | Update | Link | Close | Comment | |
| 684 | |--------------|----------|----------|----------|----------|----------| |
| 685 | | title | REQUIRED | Optional | N/A | N/A | N/A | |
| 686 | | body | REQUIRED | Optional | N/A | N/A | REQUIRED | |
| 687 | | labels | REQUIRED | Optional | N/A | N/A | N/A | |
| 688 | | assignees | Optional | Optional | N/A | N/A | N/A | |
| 689 | | milestone | Optional | Optional | N/A | N/A | N/A | |
| 690 | | issue_number | N/A | REQUIRED | REQUIRED | REQUIRED | REQUIRED | |
| 691 | | state | N/A | Optional | N/A | REQUIRED | N/A | |
| 692 | | state_reason | N/A | N/A | N/A | REQUIRED | N/A | |
| 693 | | sub_issue_id | N/A | N/A | REQUIRED | N/A | N/A | |
| 694 | | duplicate_of | N/A | N/A | N/A | Optional | N/A | |
| 695 | | type | Optional | Optional | N/A | N/A | N/A | |
| 696 | |
| 697 | Rules: |
| 698 | |
| 699 | * Create operations must provide title, body, and at least one label. |
| 700 | * Update operations must provide issue_number and at least one field to change. |
| 701 | * Link operations must provide both issue_number (parent) and sub_issue_id (child). |
| 702 | * Close operations must provide issue_number, state set to `closed`, and a state_reason (one of: `completed`, `not_planned`, `duplicate`). |
| 703 | * When closing as `duplicate`, the `duplicate_of` field should reference the original issue number. |
| 704 | * Comment operations must provide issue_number and body (passed to `mcp_github_add_issue_comment`). |
| 705 | * Call `mcp_github_list_issue_types` before using the `type` field to confirm the organization supports issue types. |
| 706 | |
| 707 | ## Content Sanitization Guards |
| 708 | |
| 709 | Before composing any content destined for a GitHub API call (issue titles, bodies, comments, labels, milestone descriptions, and other text fields), scan for the patterns below and apply the corresponding resolution. Planning files (*issue-analysis.md*, *planning-log.md*, *issues-plan.md*, *handoff.md*, *handoff-logs.md*) may contain these references locally; however, any content copied from them into GitHub-bound fields must be sanitized using these guards before the API call. |
| 710 | |
| 711 | Under Full Autonomy, log the replacement and proceed automatically. Under Partial or Manual autonomy, present the inlined content for user confirmation before the API call. |
| 712 | |
| 713 | ### Local-Only Path Guard |
| 714 | |
| 715 | * **Detect**: Paths matching `.copilot-tracking/`. |
| 716 | * **Resolve**: Read the referenced file, extract relevant details (findings, data points, conclusions), and inline them into the content. Replace the path with a descriptive label such as "Internal research" or "Local analysis" followed by the extracted details. |
| 717 | |
| 718 | ### Planning Reference ID Guard |
| 719 | |
| 720 | * **Detect**: Identifiers matching any of these patterns: |
| 721 | * `IS` followed by digits and optional letter suffixes (for example, `IS001`, `IS002a`, `IS014`) — GitHub planning IDs |
| 722 | * `WI-` followed by a prefix and digits (for example, `WI-SEC-001`, `WI-RAI-001`, `WI-SSSC-001`) — namespaced planner IDs from domain planners |
| 723 | * **Resolve**: |
| 724 | * When the actual GitHub issue number is known (from the `issue_number` field in *issues-plan.md* or *handoff.md*, or from the temporary ID to `#N` mappings in *handoff-logs.md*), replace the planning reference ID with `#<issue_number>`. |
| 725 | * When the actual issue number is not yet known, replace the planning reference ID with a descriptive phrase summarizing the referenced work. |
| 726 | * When the reference is a self-reference, remove it or replace it with "this issue". |
| 727 | |
| 728 | ### Template ID Guard |
| 729 | |
| 730 | Detect template ID placeholders in outbound content. Patterns to match: |
| 731 | |
| 732 | * `{{TEMP-N}}` — un-namespaced template IDs |
| 733 | * `{{SEC-TEMP-N}}`, `{{RAI-TEMP-N}}`, `{{SSSC-TEMP-N}}` — namespaced template IDs from domain planners |
| 734 | |
| 735 | When found: |
| 736 | |
| 737 | 1. If the template ID maps to a known GitHub issue number, replace with `#<issue_number>`. |
| 738 | 2. If the template ID has no known mapping, replace with a descriptive phrase. |
| 739 | |
| 740 | Never send planning reference IDs or template ID placeholders to GitHub APIs. |
| 741 | |
| 742 | ## Three-Tier Autonomy Model |
| 743 | |
| 744 | The autonomy model controls confirmation gates during issue operations. The consuming workflow file must specify the active tier. When no tier is specified, agents should default to Partial Autonomy. |
| 745 | |
| 746 | ### Full Autonomy |
| 747 | |
| 748 | No confirmation gates. Agents must execute all operations autonomously. |
| 749 | |
| 750 | * Agents must create issues without user confirmation. |
| 751 | * Agents must update issues without user confirmation. |
| 752 | * Agents must establish sub-issue links without user confirmation. |
| 753 | * Agents must close issues without user confirmation. |
| 754 | * Suitable for well-defined, low-risk batch operations with high-confidence similarity assessments. |
| 755 | |
| 756 | ### Partial Autonomy |
| 757 | |
| 758 | Gate on create and close operations. Auto-execute updates and links. |
| 759 | |
| 760 | * Create operations: Agents must present the planned issue for user review before executing. |
| 761 | * Close operations: Agents must present the close rationale for user review before executing. |
| 762 | * Update operations: Agents must execute without confirmation. |
| 763 | * Link operations: Agents must execute without confirmation. |
| 764 | * Suitable for most TPM workflows where creation and deletion carry higher risk. |
| 765 | |
| 766 | ### Manual |
| 767 | |
| 768 | Gate on all operations. Agents must present each for confirmation. |
| 769 | |
| 770 | * Create operations: Agents must present for user review. |
| 771 | * Update operations: Agents must present for user review. |
| 772 | * Link operations: Agents must present for user review. |
| 773 | * Close operations: Agents must present for user review. |
| 774 | * Suitable for sensitive backlogs, unfamiliar repositories, or first-time pipeline execution. |
| 775 | |
| 776 | ## Temporary ID Mapping |
| 777 | |
| 778 | Handoff files use temporary ID placeholders for planned issues that do not yet exist. The execution stage maintains a mapping table as issues are created, resolving references in subsequent operations. |
| 779 | |
| 780 | ### Placeholder Formats |
| 781 | |
| 782 | The GitHub Backlog Manager's own planning uses un-namespaced placeholders: |
| 783 | |
| 784 | * `{{TEMP-1}}`, `{{TEMP-2}}`, `{{TEMP-3}}`, incrementing sequentially. |
| 785 | |
| 786 | Domain planners use namespaced placeholders that follow the same lifecycle: |
| 787 | |
| 788 | * `{{SEC-TEMP-N}}` — Security Planner (e.g., `{{SEC-TEMP-1}}`, `{{SEC-TEMP-2}}`) |
| 789 | * `{{RAI-TEMP-N}}` — RAI Planner (e.g., `{{RAI-TEMP-1}}`, `{{RAI-TEMP-2}}`) |
| 790 | * `{{SSSC-TEMP-N}}` — SSSC Planner (e.g., `{{SSSC-TEMP-1}}`, `{{SSSC-TEMP-2}}`) |
| 791 | |
| 792 | All placeholder formats share the same resolution lifecycle. |
| 793 | |
| 794 | ### Resolution |
| 795 | |
| 796 | During execution, resolve each placeholder to the actual issue number returned by `mcp_github_issue_write`: |
| 797 | |
| 798 | ```text |
| 799 | {{TEMP-1}} → #42 (created) |
| 800 | {{SEC-TEMP-1}} → #43 (created) |
| 801 | {{RAI-TEMP-1}} → #44 (created) |
| 802 | {{SSSC-TEMP-1}} → #45 (created) |
| 803 | ``` |
| 804 | |
| 805 | Resolution rules: |
| 806 | |
| 807 | * Agents must create parent issues before child issues so that parent issue numbers are available for sub-issue linking. |
| 808 | * When a temporary ID reference appears in a sub-issue link operation, agents must resolve it from the mapping table before calling `mcp_github_sub_issue_write`. |
| 809 | * Agents must record the mapping in handoff-logs.md as each issue is created. |
| 810 | * If a temporary ID reference cannot be resolved (creation failed), agents must skip dependent operations and log the failure. |
| 811 | |
| 812 | ## State Persistence Protocol |
| 813 | |
| 814 | Agents must update planning-log.md as information is discovered to ensure continuity when context is summarized. |
| 815 | |
| 816 | ### Pre-Summarization Capture |
| 817 | |
| 818 | Before summarization occurs, agents must capture in planning-log.md: |
| 819 | |
| 820 | * Full paths to all working files with a summary of each file's purpose |
| 821 | * Any uncaptured information that belongs in planning files |
| 822 | * Issue numbers already reviewed |
| 823 | * Issue numbers pending review |
| 824 | * Current phase and remaining steps |
| 825 | * Outstanding search criteria |
| 826 | |
| 827 | ### Post-Summarization Recovery |
| 828 | |
| 829 | VS Code Copilot periodically compresses conversation history into a `<summary>` block when the context window approaches capacity. When the recovered context contains a `<summary>` block with only one tool call, agents must recover state before continuing: |
| 830 | |
| 831 | 1. List the working folder with `list_dir` under `.copilot-tracking/github-issues/<planning-type>/<scope-name>/`. |
| 832 | 2. Read planning-log.md to rebuild context. |
| 833 | 3. Notify the user that context is being rebuilt and confirm the approach before proceeding. |
| 834 | |
| 835 | Recovery notification format: |
| 836 | |
| 837 | ```markdown |
| 838 | ## Resuming After Context Summarization |
| 839 | |
| 840 | Context history was summarized. Rebuilding from planning files: |
| 841 | |
| 842 | **Analyzing**: [planning-log.md summary] |
| 843 | |
| 844 | Next steps: |
| 845 | * [Planned actions] |
| 846 | |
| 847 | Proceed with this approach? |
| 848 | ``` |
| 849 | |
| 850 | --- |
| 851 | |
| 852 | Brought to you by microsoft/hve-core |
| 853 | |