Auto Run: GitHub Issues as task source with parallel worktree execution

[pedramamini]

Summary

Extend Auto Run to pull GitHub issues (by label or manual selection), convert each into an auto-run task, execute them in parallel worktrees, and automatically open PRs for completed work.

Goal: "Give Maestro a labeled backlog and a parallelism limit, and let it continuously produce PRs."

Core Workflow

1. Source Selection

• New mode in Auto Run: GitHub-fueled alongside existing docs-based mode
• User can:
  • Select specific issues manually, or
  • Specify a label (e.g., runmaestro, autofix) and pull all matching issues

2. Queue & Organize

• Selected issues appear as a reorderable queue inside Auto Run
• Drag-to-reorder for priority
• Support encoding blocking/dependencies in issue descriptions — agent figures out ordering if needed

3. Parallel Execution

• User specifies parallelism limit (e.g., 6 concurrent)
• Per issue, Maestro:
  • Spins up a worktree per issue/feature
  • Runs each as an independent agent/auto-run
  • Continuously cycles through the queue, maintaining N parallel runs as agents finish

4. PR Creation & Feedback

• For each completed issue:
  • Branch/worktree is created automatically
  • Changes implemented by agent
  • PR opened automatically linking back to the issue
• Leverage existing GitHub CLI wrappers and worktree infrastructure

Relation to Existing Features

Feature	Today	With This
Auto Run docs	Attach local docs/playbooks, Maestro executes	Add second tab where GitHub issues drive auto-run
Worktrees	Used for isolated agent execution	Systematically spun up per-issue, managed as a pool
Symphony / token donation	N/A	Long-term: labeled issues (e.g., RunMyStro.AI) appear in shared UI; other users can donate CPU + tokens to run them

Pain Points Solved

• Eliminates manual translation of GitHub issues → auto-run docs
• Eliminates manually spinning up an agent per issue
• Moves from "one issue, one manual agent" to "labeled backlog in, PRs out"

Open Questions

• UI placement: new tab in Auto Run panel vs. separate view?
• How to handle issue dependencies / ordering constraints?
• PR template / naming conventions?
• How to surface agent progress per-issue back to the queue UI?
• Token budget / cost guardrails per issue?

[pedramamini]

UX-wise, I'm thinking about having two tabs at the top of the autorun modal:

1. Play Books
2. GitHub
   The existing functionality won't change, but under the new one, we'll have the ability to set the parallelism, select and reorder features. etc.

[PatrickRuddiman]

one of the things I've been thinking about is spec authoring, sort of inspired by speckit but much slimer and targeted to your actual project and all done in one step with a single sentence.

to give a simple example say a github issue is just:

set the default parallelism limit to the smaller of count of cpu or free ram in mb / 500

I think of that issue as 1x detail, and to get really reliable set of tasks to work on its best to have 10x (I'd consider this issue we're talking about as a 10x detail issue, as it doesn't have - [ ] tasks to execute). 100x the detail would be an issue that already includes the [ ] tasks to execute. so it may not hurt ("hurt"... it will cost tokens and that could "hurt') to add a step after fetching the github issue that takes the 1x issue to 100x by exploring the code base adding the detail and tasks for autorun to work since you can't guarantee issues will be really detailed. Engineers are often lazy

Adding a skill or custom system prompted "agent" to fire off a spec planner to do this using the users chosen cli agent will also solve your dependency and ordering issue by looking over the code and handling the order itself.

maybe it will write the spec back to github or just keep its enhancements locally, but thats more of an etiquette issue