Analyze a GitHub repo's issue/PR/code state, produce a status report, and propose or execute the next wave of work with parallel agents. USE WHEN asked 'where is this repo now?', to summarize issues and decide what's next, to run the next wave, or for ongoing delivery orchestration from issues.
Analyze a GitHub repo's issue/PR/code state, produce a status report, and propose or execute the next wave of work with parallel agents. USE WHEN asked 'where is this repo now?', to summarize issues and decide what's next, to run the next wave, or for ongoing delivery orchestration from issues.
requiredSources
["github"]
alwaysAllow
["Read","Bash"]
cluster
git-pr-ops
version
1.0.0
GitHub Next Wave Orchestrator
Conductor integration. This is the Execute stage of the conductor's github-delivery modality
(see conductor-core §4): swarm-architect plans → this orchestrator dispatches each task to its
human / copilot-swe-agent[bot] lane → ship-battery.mjs gates (fail-closed) → loop-feedback.mjs
closes. resolves each task's capability cluster + lane.
Full Copilot-bootstrap templates live in the source repo
.
resolve-task.mjs --modality github-delivery
.github/
~/.../thoughtseed/github-next-wave-orchestrator/
Use this skill when the user asks for:
“Where is this repo right now?”
“Summarize issues and tell me what to do next”
“Run the next wave”
Ongoing delivery orchestration from GitHub issues
Core Outcome
Produce two things:
Status Report — current reality of the repository (issues, PRs, velocity, risks)
Next Wave Plan — the highest-impact, executable batch of work (parallel where possible)
If user asks to execute, run the approved next wave and report progress.
Mandatory Skill Stack
Before doing work, activate and follow in order:
using-superpowers — meta-skill gating; if unavailable, proceed but note it.
executing-plans — batch and checkpoint discipline; required.
dispatching-parallel-agents — use for independent tasks; if unavailable, execute sequentially and note ordering rationale explicitly.
Priority rule: correctness and safety over speed. If a sub-skill is missing, fall back to its documented behavior inline and call it out in the execution log.
Inputs to Confirm (if missing)
Repository owner/name
Branch strategy (default branch, release branch if any)
Time horizon for status (last 7/14/30 days)
Definition of “next wave” (bugfixes, roadmap, reliability, debt, launch)
If these are not provided, proceed with sensible defaults and state assumptions.
Execution Protocol
Phase 1 — Repo Reality Scan
Gather evidence (do not guess):
Open/closed issues, priority labels, age distribution
Open PRs, merge queue, blocked PRs, stale PRs
Recent commit activity and release tags
CI/check run health on active PRs
Dependency/risk signals from issue text and labels
Always anchor conclusions to observable data.
If the repo has zero open issues and zero open PRs, note this explicitly and skip to Phase 3 — propose seed issues based on the codebase state (missing tests, stale deps, undocumented APIs).
Phase 2 — Status Synthesis
Generate a concise Status Report with:
Repo Pulse: current throughput and momentum
Issue Landscape: grouped by severity, theme, owner, staleness
Delivery Risks: blockers, bottlenecks, missing ownership, CI instability
Readiness Score: Green / Yellow / Red with rationale.
Green: no blocking PRs, CI passing, <3 P0 issues open, active commits in last 7 days.
Yellow: any one of — CI flaky, 1–2 blocking PRs, 3–6 P0 issues, stale >14 days.
Red: CI broken, merge queue blocked, >6 P0 issues, or no commits in >14 days.
Phase 3 — Next Wave Design
Create a prioritized execution wave using this ranking order:
Unblocks other work (dependency chains)
Fixes broken CI or a P0 bug
High impact, reversible (safe to ship fast)
High impact, irreversible (needs review gate)
Low impact — defer unless trivial
Pick the top 3–7 by this ranking; aim for at least 2 that can run in parallel.
Define success criteria and verification per task
Include dependencies and ordering constraints
Keep blast radius minimal
Phase 4 — Parallel Dispatch (when executing)
For independent tasks:
Dispatch parallel agents/subtasks with full context per task
Use one focused prompt per task (objective, constraints, validation)
Collect outputs
Run mandatory spotcheck for consistency/completeness
For dependent tasks:
Execute sequentially with checkpoints.
Phase 5 — Review Checkpoint
After each batch, report:
Completed items
Verification evidence (tests/checks/logs/diffs)
Remaining risks
Recommended next batch
Say: “Ready for feedback.”
Output Contract
Use this structure:
1) Status Report
Scope and assumptions
Repo Pulse
Issue Landscape
Active PR & CI Health
Top Risks / Blockers
Readiness Score
2) Next Wave
For each item:
Priority
Why now
Owner/agent lane
Execution type: Parallel or Sequential
Done criteria
Verification steps
3) Execution Log (if executed)
What ran
What passed/failed
Follow-ups
Guardrails
Never fabricate repository state.
Never close/edit issues or merge PRs without explicit user approval.
If evidence is incomplete, call it out and proceed with confidence levels.
Prefer elegant, minimal-impact solutions over broad refactors.
Do not mark done without verification evidence.
Definition of Done
All three sections of the Output Contract delivered, with verification evidence for any executed work, ending with: "Ready for feedback."
Loading spokes on demand
To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:
~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).
