.opencode/command/gh-bulk-issues.md
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.
$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.
For each issue number in the list:
Create a git worktree with a dedicated branch:
git worktree add ../$(basename $PWD)-issue-<NUMBER> -b fix/issue-<NUMBER>
Install and build in the worktree. Run 2 worktrees at a time to manage CPU:
cd ../$(basename $PWD)-issue-<NUMBER> && pnpm i && pnpm build
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 "/gh-debug-issue <NUMBER>"
Run all instances as background processes with a matching timeout on execute_command. Track each PID.
Create a reports/ directory in the main project root. For each issue, maintain a reports/issue-<NUMBER>.md file with:
Check all processes every 3 minutes. For each check:
mc instance finishes or times outgit diff --stat in the worktree to see what changed--prompt that says "Continue working on issue #<NUMBER>." and summarizes where it left off based on the diff and last output/gh-new-pr conventions:
fix: ... or feat(pkg): ...Closes #<NUMBER>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.
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.
pnpm buildmc instances can run in parallel — they're IO-bound, not CPU-boundmc instance benefits from.mc output before creating PRs — subagent work is untrusted