overnight-multi-issue-implementationlisted

Run an overnight autonomous workflow that takes a cluster of related GitHub issues (typically a P1 review-panel finding set) and ships them to merged PRs by morning. Use when: (1) the user wants 6-15 related issues closed in one autonomous run, (2) the issues split naturally into two PRs (e.g., hardening + features, or refactor + new-functionality), (3) the user is going to sleep and won't be available to merge PR1 between phases, (4) each issue has clear acceptance criteria so each task can be implemented + tested + reviewed independently. Specializes `superpowers:subagent-driven- development` for the "issues -> stacked PRs by morning" problem shape: stacks PR2 on PR1's branch (so PR2 doesn't wait for human PR1-merge mid- night), audits tracker IDs against main before claiming (concurrent sessions steal ids), runs final code-review subagent before proposing merge, and surfaces important findings as PR comments before squashing (so review trail survives). Sister plugin to `overnight-review-client- delivery` (
wan-huiyan/overnight-workflows · ★ 1 · Code & Development · score 71

Install: claude install-skill wan-huiyan/overnight-workflows

# Overnight Multi-Issue Implementation ## Overview An overnight autonomous workflow specialized for the "cluster of GitHub issues → stacked PRs by morning" problem. Builds on `superpowers:subagent-driven- development` with overnight-specific discipline: stacked PRs (so PR2 doesn't wait on a human PR1-merge), pre-flight tracker-id audit (concurrent sessions on main steal your IDs), final PR-level code review (not just per-task), and review-finding preservation as PR comments before squash. Sister to `overnight-review-client-delivery` (polishes existing deliverables) and `overnight-insight-discovery` (generates insights from data). Different problem shape, same overnight-autonomous philosophy. ## When to use All of these conditions: 1. **Input**: 6-15 related GitHub issues, typically a P1 review-panel cluster. 2. **Output**: 2 stacked PRs (occasionally 1 large PR or 3 — see "PR shape"). 3. **Human availability**: user is going to sleep / away for 6-10 hours; not available to merge PR1 between phases. 4. **Issue quality**: each issue has clear acceptance criteria (so per-issue tasks are implementable + testable independently). 5. **Codebase familiarity**: agent has implementation context (CLAUDE.md, existing tests, conventions) — this isn't for greenfield bootstrapping. NOT for: - Synchronous single-PR work → use plain `superpowers:subagent-driven-development` - Polishing an existing deliverable → use `overnight-review-client-delivery` - Generating insights from d