issue-fanout

Dispatches parallel Opus agents at GitHub issues with per-issue worktrees, claims, and PRs.

2|Updated Mar 3, 2026
One-click install
npx skills add https://github.com/DanielH2018/server --skill issue-fanout-danielh2018
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: issue-fanout
Source: https://github.com/DanielH2018/server/tree/main/.claude/skills/issue-fanout
Command: npx skills add https://github.com/DanielH2018/server --skill issue-fanout-danielh2018

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Working through a backlog of open GitHub issues one at a time is slow, and naive parallelization causes agents to collide on the same files, double-claim issues, or conflict on shared secrets. This Skill orchestrates a race-free fan-out: triage, claim, spawn, land, and report, with every issue claimed before any agent starts. ## Core Features & Use Cases - Race-free claiming: Claims every issue under the orchestrator's own worktree name before spawning, with stale-claim reaping and deferral handling via findings.py. - Conflict-aware batching: Groups issues so no two agents touch the same Ansible role, at most one batch rotates SOPS secrets, and broad changes run alone. - Placement and lifecycle management: Launches headless Opus agents across hosts based on memory headroom, polls status, reconciles landed or no-report batches, and cleans up worktrees. - Use Case: You have a dozen open findings on your homelab repo. Run the fan-out to triage them into safe batches, dispatch one Opus agent per batch in its own worktree, and collect a table of issue-to-PR results. ## Quick Start Ask the agent to fan out on the open GitHub issues, triage them into batches, and dispatch one Opus agent per batch with its own worktree and PR.

Frequently Asked Questions about issue-fanout

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I work through multiple GitHub issues in parallel with AI agents?▼

Triage the open issues with findings.py, group them so no two agents touch the same Ansible role, claim every issue before spawning, then launch one Opus agent per batch in its own git worktree. Each agent produces its own PR and lands it independently.

How do I prevent parallel agents from conflicting on the same files?▼

Batch issues so no two agents edit the same Ansible role, allow at most one SOPS-secret change per wave since ciphertext conflicts are not hand-resolvable, and run broad changes that add containers_list entries alone in their own wave.

Why must issues be claimed before spawning agents?▼

Claiming under the orchestrator's live worktree name before any agent starts makes the fan-out race-free, since a subagent cannot own a named worktree and a claim under a nonexistent name would read as stale immediately.

What does a no-report status mean for a fan-out batch?▼

A no-report status means the agent's worktree and report file are gone, which happens both when work finished and when it died early. Reconcile against GitHub for a merged PR before re-placing the issue, since the work may already be on master.

When should I not use issue fan-out?▼

Do not fan out on a single issue; claim it and work it directly instead. Also avoid dispatching at deferred issues whose date precondition has not arrived, and never give agents authority to close findings as refuted or accepted.