Back to Mastra

Bulk Issue Solver

.cursor/commands/gh-bulk-issues.md

2025-12-184.1 KB
Original Source

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 "/gh-debug-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 #<NUMBER>." 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