Rebase One PR

Start only through /tk-pr-rebase, $tk-pr-rebase, the host skill picker, or an exact PR handoff from an active tk-pr-sweep. Do not auto-apply to a generic branch rebase, simple conflict marker edit, or review response.

Own the exact base/head rebase, conflict resolution, verification, and bounded force-with-lease for one PR. Do not perform merge, close, tag, release, or unrelated feedback implementation. When standalone rebase/publication approval is needed, prefer the host's native structured question surface (Claude Code: AskUserQuestion; Codex: request_user_input; Hermes: clarify). If unavailable, present the same approval packet in plain chat; do not ask again for an exact route already approved by the parent.

Fresh identity and workspace

Local rebase must run in a newly established dedicated isolated workspace for the exact PR operation. "Newly established" is semantic: when the host has already placed this invocation in a fresh externally managed workspace dedicated to the exact PR/head, that boundary may be reused after provenance is proven; do not create a nested manual worktree merely to satisfy wording.

Before creating anything, inspect repository root, branch/HEAD, GIT_DIR, GIT_COMMON, and git rev-parse --show-superproject-working-tree or equivalent. GIT_DIR != GIT_COMMON is a linked-worktree signal only after excluding a submodule, and a linked worktree is not automatically owned by this PR.