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