Idea: fanout-phase — multi-conversation dispatch board for phases with 10+ homogeneous atomic units

[zzhuxiaojun-glitch]

The gap I keep hitting

GSD's existing gsd-execute-phase does excellent wave parallelism with subagents inside one conversation. That works beautifully when each task fits in summary-back context (~20-30k tokens to spawn + retrieve).

Where it falls over for me: phases where each atomic task itself needs ~50–100k tokens of context — typically:

• Multi-page PDF extraction with image reading + iteration
• Long content transformation (textbook → structured JSON, with mid-task self-correction)
• Per-item code review where the diff is large
• Per-document translation with quality loops

When I have N=20+ such tasks, neither approach scales:

• Wave (subagent): parent context fills up before all subagents complete; results come back as summaries that lose iteration detail
• Sequential single-conversation: ~10× too slow; one bad task contaminates the next
• 20 GSD phases: explodes ROADMAP.md, breaks dependency tracking, wrong granularity (each "phase" is just one PDF)

What I built outside GSD

Last week I built a "dispatch-board" pattern for a JLPT mock exam project (60k+ questions, 6 textbooks to extract, 3 explanation enhancement tracks). Currently 167 atomic dispatches across 11 categories, in production with multi-session validation.

The pattern boils down to file conventions + a small Python aggregator:

tasks/
├── README.md
├── MASTER_PROGRESS.md          ← regenerated dashboard
├── MASTER_PROGRESS.html
├── build_dashboard.py          ← ~250 LOC, scans manifests + status
├── pitfalls.md                 ← multi-session shared learnings (append-only)
├── status/<task_id>.json       ← one file per dispatch, written on completion
└── dispatches/<category>/{TEMPLATE.md, manifest.json}

The user opens N parallel Claude Code sessions; each says execute dispatch <category>/<id>; each completes its full ~50k token job, writes status/<task_id>.json, regenerates MASTER_PROGRESS.{md,html}, then git pull --rebase + push. Validated within 24h: 7 parallel sessions independently captured 8 new pitfalls without status-file collisions, all merged cleanly.

Sketch of what would land in GSD

Smallest-viable shape (one new command, no new phase type):

/gsd-fanout-phase <phase-slug>

Behavior:

1. Read PLAN.md; if it has ≥10 homogeneous tasks marked something like kind: parallel-atom, generate .planning/<phase>/dispatch-board/{dispatches/, status/, build_dashboard.py} from a manifest derived from PLAN.md.
2. Output: "Dispatch board generated. Open N parallel sessions and say execute dispatch <slug>/<id> in each."
3. Phase verification (existing gsd-verify-work) checks status/*.json count == manifest entries, treats it as wave equivalent.

Anything bigger (new phase type, new state field) is probably scope creep — the pattern is mostly file conventions + a Python aggregator (~250 LOC).

Why I'm not just opening a Feature Request

Per CONTRIBUTING.md: discuss first. Real questions before I write the spec:

1. Is this in scope? GSD's design philosophy is "solo dev w/ AI" — multi-conversation parallelism is a real solo-dev win (Claude Max plan 20× makes it cheap), but it does cross the "one conversation = one project" mental model. Want to make sure that's not a no-go.
2. In-tree vs community skill? Would maintainers prefer this stays out-of-tree (community skill) and just gets a docs link? I have it as a community skill (dispatch-board) already; that route may suit you better given maintenance burden.
3. Naming + integration: /gsd-fanout-phase as a new command, or a flag on /gsd-execute-phase (e.g. --mode=fanout), or a new phase type emitted by /gsd-plan-phase?
4. State integration: should status/<task_id>.json files be reflected back into STATE.md, or stay as a separate sub-system that only the verification step reads?

Happy to write the full Feature Request spec + PR if maintainers indicate interest. Otherwise I'll keep it as a community skill and just submit a docs link.