wave

Answer one question: what is the largest set of backlog issues I can start right now without them stepping on each other?

/wave ranks nothing itself, launches nothing itself, and writes no code. It selects, caps, and offers.

NON-NEGOTIABLE — /wave never auto-launches. Every issue in the wave reaches exactly one of three visible outcomes: offered as a chip (or a printed prompt block in fallback mode); recommended for inline execution via /subagent in a live PM thread (Step 7.0); or explicitly reported as queued inline / deferred when the ceiling is full (Step 6). Never a fourth — no issue is silently dropped. The user's action (a chip click, or running /subagent) is the only launch path. /wave never spawns Agent-tool subagents and never invokes /subagent itself, and does not treat its own selection as go-ahead. Selecting an issue for the wave is the recommendation; it is not permission. See "Execution boundary" at the end of this file.

---

Step 0: Resolve shared tooling

/wave is symlinked into every repo, but its helper scripts and reference docs are not — most repos carry no .claude/ directory. Resolve them; never invoke a bare .claude/scripts/… path. Full contract and the classified dependency inventory: .claude/reference/portable-skill-resolution.md (issue #1189).

resolve_script() {
  local name="$1" candidate
  for candidate in \
    "$HOME/.claude/skills-worktree/.claude/scripts/$name" \
    "$HOME/.claude/scripts/$name" \
    ".claude/scripts/$name"; do
    if [[ -x "$candidate" ]]; then echo "$candidate"; return 0; fi
  done
  return 1
}
ISSUE_CLAIM=$(resolve_script issue-claim.sh || true)
PM_CONFIG_GET=$(resolve_script pm-config-get.sh || true)
ACTIVE_WORK_CAP_SH=$(resolve_script active-work-cap.sh || true)

Read chip-launching.md the same way — $HOME/.claude/skills-worktree/.claude/reference/chip-launching.md first, then $HOME/.claude/reference/, then .claude/reference/ — and cr-rate-limits.md likewise.

When something does not resolve, say so in one line; never skip the contract silently.

• chip-launching.md unreadable → required. Print ERROR: chip-launching.md not found (checked all three paths) — PM-context inline gate unavailable, and stop before offering any chip. A /wave that cannot read its own routing gate is exactly the run that fans out one thread per issue (#1189); refusing is the safe failure.
• ISSUE_CLAIM empty → optional. Print DEGRADED: issue-claim.sh not found (checked all three paths) — claim filter skipped, in-flight detection is PR-only and continue with Step 2's other filters.
• PM_CONFIG_GET empty → optional. Print DEGRADED: pm-config-get.sh not found (checked all three paths) — repo Wave override unavailable and use CEILING as computed. An absent .claude/pm-config.md in a repo that has the script is a normal state, not a degradation — say nothing.
• ACTIVE_WORK_CAP_SH empty → optional, but say so. Print DEGRADED: active-work-cap.sh not found (checked all three paths) — repo-wide cap unenforced, sizing on the per-thread ceiling only and drop FREE from the SLOTS formula. /wave still has EFFECTIVE - IN_FLIGHT, so the wave stays bounded; what is lost is only the cross-thread term, and a run that silently dropped it would look identical to one where the repo genuinely had headroom. A non-zero exit from the script is different from a missing script: it means a count source could not be read, so treat it as FREE = 0 and defer, rather than sizing as if nothing were in flight (active-work-cap.md "Resolution order and failure behavior").

The pipeline ceiling itself needs no fallback: .claude/rules/subagent-orchestration.md auto-loads at user scope in every project, so the number is already in context wherever /wave runs.

---