bip-spawn-resume

name	bip-spawn-resume
description	Cold-start into a worktree/clone from a fresh conversation — read the PR, issue, and any status files, figure out where things stand, then STOP and ask the user what to do next. Use for a fresh conversation dropped into a bip-spawn or bip-epic-spawn worktree/clone that already has history (a PR, an in-progress phase, or a stalled worker).

/bip-spawn-resume

For a fresh conversation dropped into a worktree/clone that was spawned (via /bip-spawn or /bip-epic-spawn) and already has history — a PR out, review feedback waiting, an EPIC worker mid-phase, or something stalled. This skill's job is entirely orientation: gather context, report it, and stop. It does not decide what happens next — the most common case is a vetted PR the user wants to modify (directly, or via PR review comments), but treat that as a prior, not a restriction. Let the actual state (and the user) drive what happens after Step 2.

This is not a crash-recovery tool — see /bip-epic-recover for processes killed by a host reboot (claude --resume-based). This skill is for the ordinary case of a new conversation that needs to re-orient inside a slot that already has state.

Usage

/bip-spawn-resume

Always run from inside the slot's worktree/clone, on its branch — gh pr view with no args resolves the PR (if any) from the current branch.

Workflow

Step 1: Gather context

git branch --show-current
git log --oneline -10
gh pr view --json number,url,state,isDraft,statusCheckRollup,reviews,comments 2>/dev/null

If .epic-status.json exists (this is an EPIC slot), read it and .epic-worklog.md too — phase, summary, blockers, stop_reason, lead_guidance, awaiting. If the PR body (or the worklog) references an issue, gh issue view N --comments as well.

Step 2: Branch on what you find, then report and STOP

Don't act past this point without direction. Assemble a recap and present it, branching on state:

• No PR yet, EPIC phase in progress (exploring, coding, testing, awaiting-results) — summarize the phase, the last worklog entry, and any blockers/awaiting fields. Don't resume the ralph-loop or continue coding on your own.
• needs-human — lead the recap with blockers and lead_guidance; this phase means a person's judgment was already requested.
• quality-gate — report gate iteration count and what's outstanding.
• PR open — report CI status, unresolved review threads, and a diff of what changed since the last commit/worklog entry (new comments or reviews since then). Summarize new feedback content, don't just count it.
• PR merged / phase completed — say so plainly; there may be nothing left, or the user may want a follow-up.
• Nothing recognizable (no status file, no PR, just a branch) — say so; report the branch/log state and let the user frame the task.

End the recap with a direct question — what would you like to do? Do not guess at a next action (fix a comment, keep coding, open a PR, restart the loop) and do not restart any ralph-loop or autonomous machinery on your own initiative.

After the user responds

The user may hand you a specific instruction, point you at a PR comment or review thread, or just start talking through what they want changed. Whatever direction they give supersedes any default — there's no fixed Step 3+. A few things carry over regardless of what they ask for:

• Same branch, same PR — don't open a new branch or a second PR unless told to.
• Apply the DEFERRAL RULE from /bip-epic-spawn if scope creep comes up (fold small related fixes in; only defer clearly out-of-scope work).
• Before pushing changes back out, re-run /bip-pr-check and /bip-pr-review, same REVIEW TRIAGE as /bip-epic-spawn.
• Replying to or resolving someone else's review thread is a visible GitHub action — draft it and confirm before posting/resolving, per the standing GitHub Action Sequencing rule.
• If this is an EPIC slot and the change is small and bounded, update .epic-status.json/.epic-worklog.md directly rather than restarting the ralph-loop. Only fall back to /bip-epic-spawn's RECOVERING CONTEXT + ralph-loop protocol if the user actually wants ongoing autonomous iteration, not just this one fix.

Notes

• Distinct from /bip-epic-tuckin (orchestrator-side, persists EPIC dashboards across many slots) and /bip-epic-recover (rebuilds processes killed by a host reboot). This skill is for a plain new conversation re-orienting inside one slot.
• Works for both EPIC slots (.epic-status.json present) and plain /bip-spawn sessions (no status file — just a branch and maybe a PR).