Issue Bulk Process

Orchestrate bulk triage and reproduction of multiple SkiaSharp issues by delegating to issue-triage and issue-repro skills via sub-agents.

Input Parsing

Parse the user's message to determine the issue list:

1. Explicit issue references — numbers preceded by #, or numbers in a space/comma-separated list that the user clearly intends as issue numbers (e.g., #3400 #3428, issues 3400, 3428, 3429, triage 123 456 789). Issue numbers may be 2–5 digits.
2. "newest N issues" — if the user says "newest", "latest", "recent", or "last N issues", extract the count N and fetch from GitHub (see Phase 1).
3. Ambiguous numbers — if a number could be an issue number OR a count/quantity (e.g., "process 10 issues starting from 3400"), ask the user to clarify before proceeding. Use the ask_user tool.

Phase 1 — Resolve Repository and Issue List

1. Detect current repository

gh repo view --json owner,name -q '"\(.owner.login)/\(.name)"'

Store the {owner} and {repo} for use in all subsequent phases.

2. Resolve issue list

Use the gh CLI for all issue lookups. It handles pagination automatically via the -L (limit) flag — no manual page iteration needed.

If explicit numbers given: Use them directly — they refer to the current repository.

If "newest N issues" or similar:

gh issue list --state open -L {N} --json number,title -q '.[] | "\(.number)\t\(.title)"'

If search query (e.g., "all blazor issues", "issues about WASM", "label:area/foo"):

gh issue list -S "{search terms}" --state open -L 500 --json number,title -q '.[] | "\(.number)\t\(.title)"'

For label-based queries, use --label instead of -S:

gh issue list --label "area/SkiaSharp.Views" --state open -L 500 --json number,title -q '.[] | "\(.number)\t\(.title)"'

Note: -L 500 is a generous upper bound. gh fetches exactly as many pages as needed and stops when results are exhausted, so over-specifying the limit is fine.

Extract issue numbers from the output. Present the list to the user and confirm before proceeding.

3. Skip already-processed issues

Before launching triage/repro agents, check for existing result files:

# Check for existing triage results
ls .data-cache/repos/{owner}-{repo}/ai-triage/{number}.json 2>/dev/null

# Check for existing repro results
ls .data-cache/repos/{owner}-{repo}/ai-repro/{number}.json 2>/dev/null

• Default behavior: Skip issues that already have a triage JSON file. Skip reproduction for issues that already have a repro JSON file. Report skipped issues in the summary with a ⏩ icon.
• Force re-processing: If the user explicitly says "force", "re-triage", "re-process", "redo", or "again", process all issues regardless of existing results.
• Present skip info: Before proceeding, show the user how many will be skipped vs processed:
  Copy

  Found 33 issues. 15 already triaged, 12 already reproduced.
  Will triage: 18 | Will reproduce: 21
  

Phase 2 — Triage (parallel)

Triage is read-only — safe to parallelize.

Launch one general-purpose background agent per issue. Each agent's prompt is exactly:

triage issue {number}

This triggers the issue-triage skill in each agent.

Steps:

1. Launch all agents with mode: "background" via the task tool. Collect all returned agent_id values.
2. Call read_agent for each agent_id with wait: true, timeout: 300. You can call multiple read_agent in parallel.
3. If any agent is still running after 300s, call read_agent again with another 300s timeout (600s total max).
4. From each agent's response, extract the Type, Severity, and suggested Action from the triage summary. Look for patterns like Type: type/bug (0.95), Severity: high, Action: needs-investigation in the response text.
5. If an agent's response does not mention issue-triage or ai-triage, it failed to invoke the skill — report it.

Batch size limit: Launch at most 12 agents at once. If more issues, wait for the current batch to complete before launching the next.

Phase 3 — Reproduce (serial)

Reproduction may build projects, create files, open simulators — must run in series.

Launch one general-purpose sync agent per issue, sequentially. Each agent's prompt is exactly:

reproduce issue #{number}

This triggers the issue-repro skill in each agent.

Steps:

1. For each issue in order, launch a task agent with mode: "sync". The call blocks until the agent completes.
2. From the agent's response, extract the Conclusion (one of: reproduced, not-reproduced, needs-platform, needs-hardware, inconclusive, partial). Look for Conclusion: in the response text.
3. Continue to the next issue regardless of the previous result.

Phase 4 — Summary

Present a consolidated summary table using data extracted from the agent responses in Phases 2 and 3:

## Bulk Process Results

| # | Issue | Type | Severity | Triage Action | Repro Conclusion |
|---|-------|------|----------|---------------|------------------|
| 1 | #3400 | Bug | medium | needs-investigation | ⏭️ needs-platform |
| 2 | #3472 | Bug | medium | needs-investigation | ❌ reproduced |
...

### Stats
- Triaged: {N}
- Reproduced: {reproduced}
- Not reproduced: {not_reproduced}
- Blocked (needs-platform/hardware): {blocked}
- Inconclusive: {inconclusive}

Conclusion icons: ❌ reproduced · ✅ not-reproduced · ⏭️ needs-platform/hardware · ❓ inconclusive · ⏱️ timeout · ⏩ skipped (already processed)

Error Handling