gh-bulk-issues

name	gh-bulk-issues
description	Orchestrate parallel Mastra Code headless instances to debug and fix multiple GitHub issues simultaneously
goal	true

Bulk Issue Solver

Orchestrate parallel mc (mastracode) headless instances to debug and fix multiple GitHub issues simultaneously. You act as the supervisor — spawning workers, monitoring progress, reviewing output, and creating PRs.

Inputs

$ARGUMENTS should be a space-separated list of GitHub issue numbers, e.g. 1234 5678 9012.

If no arguments are provided, use the GH CLI and the user's contribution history to recommend issues:

RUN gh issue list --state open --limit 50 --json number,title,labels,assignees RUN git log --author="$(git config user.name)" --pretty=format:'' --name-only --since="6 months ago" | sed 's|/[^/]*$||' | sort | uniq -c | sort -rn | head -20

Summarize the user's contribution areas and match them to open issues. Ask the user which issues to work on before proceeding.

Setup

For each issue number in the list:

1. Create a git worktree with a dedicated branch:

   git worktree add ../$(basename $PWD)-issue-<NUMBER> -b fix/issue-<NUMBER>
   

2. Install and build in the worktree. Run 2 worktrees at a time to manage CPU:

   cd ../$(basename $PWD)-issue-<NUMBER> && pnpm i && pnpm build
   

3. Spawn an mc headless instance in each worktree with a generous timeout (30 minutes):

   cd ../$(basename $PWD)-issue-<NUMBER> && pnpx tsx <path-to-mastracode>/src/main.ts --timeout 1800 --prompt "Activate the understand-issue skill for issue <NUMBER>"
   

   Run all instances as background processes with a matching timeout on execute_command. Track each PID.

Monitoring

Create a reports/ directory in the main project root. For each issue, maintain a reports/issue-<NUMBER>.md file with:

• Issue number, title, and link
• Current status (Analyzing / Implementing / Tests passing / PR open / Done)
• Summary of the approach and changes
• PR URL once created
• Any blockers or notes

Check all processes every 3 minutes. For each check:

1. Read the tail output of every running PID
2. Update the corresponding report file
3. Report a brief status table to the user

When an mc instance finishes or times out

1. Check git diff --stat in the worktree to see what changed
2. Check for new changesets and ISSUE_SUMMARY files
3. If the instance timed out but made progress, restart it with a --prompt that says "Continue working on issue #." and summarizes where it left off based on the diff and last output
4. If the instance completed its work (code + tests + changeset):
   • Review the diff — does the fix make sense?
   • Report the changes to the user for review
   • When approved, commit, push, and create a PR using /gh-new-pr conventions:
     • Conventional commit title: fix: ... or feat(pkg): ...
     • Concise PR description with code examples
     • Reference Closes #<NUMBER>
   • Update the report file with the PR URL

PR Review Comments

After PRs are created, spawn mc instances with /gh-pr-comments <PR_NUMBER> to handle CodeRabbit and reviewer feedback. If an instance times out, restart it with context about which comments still need addressing.

CI Checks

After pushing a PR (and after each subsequent push from comment fixes), check CI status:

gh pr checks <PR_NUMBER>

If any checks are failing, spawn an mc instance in the worktree with /gh-fix-ci to diagnose and fix the failures. If it times out, restart it with context about which checks failed and what was already attempted.

Key Rules

• 2 builds at a time to manage CPU during pnpm build
• All mc instances can run in parallel — they're IO-bound, not CPU-bound
• One worktree per issue, always — every task related to an issue (debugging, PR comments, CI fixes) must run in that issue's worktree. Never create a second worktree for the same issue. The worktree accumulates context (commits, diffs, build artifacts) that each mc instance benefits from.
• Always restart timed-out processes with a continuation prompt that includes context from the diff and last output
• Never leave a process unmonitored — check every 3 minutes
• Update report files continuously so the user always has a written record
• Review all mc output before creating PRs — subagent work is untrusted