fanout
SolidShip a set of related issues as parallel PRs — one isolated worktree and one briefed agent session per unit of work, then merge, verify closure, and tear down. Runner-agnostic: herdr, tmux, or background shells. TRIGGER when: asked to work several issues at once, "ship these issues in parallel", "spawn an agent per issue", "fan out", or clearing a queue before a larger refactor.
Install
Quality Score: 84/100
Skill Content
Details
- Author
- mifunedev
- Repository
- mifunedev/openharness
- Created
- 6 months ago
- Last Updated
- today
- Language
- TypeScript
- License
- Apache-2.0
Similar Skills
Semantically similar based on skill content — not just same category
dispatching-parallel-agents
The parallel fan-out primitive. Routed to by any skill or command that splits work across independent units and dispatches an agent per unit — subagent-driven-development, /sprint, parallel /review. It owns the dispatch/collect/funnel discipline: bound concurrency, isolate units, collect every result, dedupe overlap, and funnel through finding-triage then the read-only verdict-aggregator. Raw agent output is never consumed before the funnel runs; an agent that errors records its unit as incomplete without corrupting the batch.
parallel-pr-fanout
Use when a batch of 3+ independent changes should land as SEPARATE pull requests built by parallel agents — "address all of these", "fix everything on the list", "make as much parallel work as possible", a review or audit producing many unrelated fixes. Goal — reviewable, file-disjoint PRs that merge in any order. NOT for coupled changes (one PR), sequential work (a stack), or generic non-PR parallelism (that is plain agent dispatch).
ship
Run parallel pre-launch review with code-reviewer, security-auditor, and test-engineer, then synthesize a go/no-go decision.