claude-code-config: Skill for Claude Code

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)
CANDIDATE_OWNERSHIP=$(resolve_script candidate-ownership.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.
• CANDIDATE_OWNERSHIP empty → optional. Print DEGRADED: candidate-ownership.sh not found (checked all three paths) — ownership sweep skipped; a candidate paused in another thread may be re-offered here and fall back to claim-gate-only behavior in Step 2 item 4. Never block a wave on this — the sweep exists to stop duplicate work, and a sweep that cannot run must not also stop the work it was meant to protect. /wave launches nothing either way, so the cost of the fallback is a re-offer the user can decline, not a duplicate implementation.
• 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; CEILING falls back to its default of 4, since the repo's PIPELINE_CEILING is read through the same script. A non-zero exit from --ceiling on a script that did resolve (a usage error — a bad config value warns and prints the default instead) is handled like an unreadable census: defer the wave rather than sizing it on an empty CEILING. /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").