/update-issues - Update GitHub Issues from Reports

Read a triage, investigation, or prioritization report and apply the recommended actions to GitHub. This is the only skill in the issue workflow that modifies GitHub state.

Usage

/update-issues --from-report [path] [--dry-run]

• --from-report — Path to a report JSON file (auto-detects type: triage decisions, investigation decisions, or resolutions). If path omitted, uses the most recent report JSON in .work/triage/reports/.
• --dry-run — Show what would be done without making changes. This is the DEFAULT behavior on first invocation — you must confirm before actions are applied.

Instructions

Stage 0 — Load Report

Read the JSON file and determine report type:

• Has verdicts array → Triage decisions (YYYY-MM-DD-DECISIONS[-batch-N].json)
• Has investigations array → Investigation decisions (YYYY-MM-DD-INVESTIGATION-DECISIONS.json)
• Has resolutions array → Resolution decisions (YYYY-MM-DD-RESOLUTIONS.json)

Detect by JSON content, not filename — note *-DECISIONS.json also matches investigation files, so "most recent" filename lookups must check the arrays to pick the intended type.

Stage 1 — Translate Recommendations to Actions

For each issue in the report, determine the GitHub actions to take:

From triage decisions:

From investigation decisions:

From resolution decisions:

Stage 2 — Pre-flight State Check

Critical: Before applying ANY action, verify current issue state:

gh issue view <number> --repo gitkraken/vscode-gitlens --json state,labels,milestone

For each issue, check:

• Already closed? → Skip close actions, warn user
• Labels already applied? → Skip redundant label additions
• Milestone already set? → Skip if same milestone, warn if different
• Report age → If the report is older than 24 hours, warn that issue state may have changed

Stage 3 — Present Dry Run

Before executing any actions, present a summary table:

## Actions to Apply

| Issue | Action        | Details                             | Status                       |
| ----- | ------------- | ----------------------------------- | ---------------------------- |
| #1234 | Close         | Reason: not planned, Comment: "..." | Ready                        |
| #1234 | Add label     | `duplicate`                         | Ready                        |
| #2345 | Add label     | `needs-more-info`                   | Ready                        |
| #2345 | Comment       | "Could you provide..."              | Ready                        |
| #3456 | Set milestone | Backlog                             | Ready                        |
| #4567 | Close         | Reason: completed                   | ⚠️ Already closed — skipping |

### Summary

- Actions ready: N
- Skipped (already applied): N
- Warnings: N

Ask for confirmation before proceeding. The user may choose to:

• Apply all ready actions
• Apply selectively (specify issue numbers)
• Cancel

Stage 4 — Execute Actions

Execute approved actions using gh CLI:

# Add label
gh issue edit <number> --repo gitkraken/vscode-gitlens --add-label "<label>"

# Remove label
gh issue edit <number> --repo gitkraken/vscode-gitlens --remove-label "<label>"

# Set milestone
gh issue edit <number> --repo gitkraken/vscode-gitlens --milestone "<milestone>"

# Post comment
gh issue comment <number> --repo gitkraken/vscode-gitlens --body "<message>"

# Close with reason and comment
gh issue close <number> --repo gitkraken/vscode-gitlens --reason "not planned" --comment "<message>"

# Close as completed
gh issue close <number> --repo gitkraken/vscode-gitlens --reason "completed" --comment "<message>"

Execution order per issue: Labels first, then milestone, then comment, then close (if applicable). This ensures the issue has correct metadata before closing.

Error handling: If a gh command fails, log the error and continue with remaining actions. Report all failures at the end.

Stage 5 — Audit Log

Write an audit log to .work/triage/reports/YYYY-MM-DD-ACTIONS.md:

# Actions Applied — YYYY-MM-DD

Source report: <path to source JSON>
Report type: triage | investigation | resolution
Applied at: <ISO timestamp>
Applied by: <git user>

## Actions Taken

| Issue | Action                        | Result                                  |
| ----- | ----------------------------- | --------------------------------------- |
| #1234 | Closed (not planned)          | ✓ Success                               |
| #1234 | Added label `duplicate`       | ✓ Success                               |
| #2345 | Added label `needs-more-info` | ✓ Success                               |
| #2345 | Posted comment                | ✓ Success                               |
| #3456 | Set milestone: Backlog        | ✗ Failed: milestone "Backlog" not found |

## Summary

- Successful: N
- Failed: N
- Skipped: N

Safety Rules

1. Dry-run first — ALWAYS show the action plan and get confirmation before executing
2. Pre-flight checks — ALWAYS verify current issue state before acting
3. Close confirmation — Closing issues requires explicit user approval for EACH issue
4. No label creation — Only use existing labels. If a recommended label doesn't exist, warn and skip
5. No force operations — Never use --force or bypass safety checks
6. Audit everything — Every action taken must be logged

Chaining

This skill consumes output from the other issue workflow skills:

/triage recent → /update-issues                                      (apply triage verdicts)
/triage recent → /investigate --from-report → /update-issues         (apply investigation results)
/triage recent → /investigate --from-report → /prioritize --from-report → /update-issues  (full pipeline)